Aperture: How Do I View and Edit A Large Version of a Book or Light Table Image?
2006-12-31
You are missing the F key. Pressing F will display the selected thumbnail (one or many) full screen. There images can be adjusted via the HUD.
There is a second way that involves less clicking if you have a number of images to view and/or edit. The grid browser includes this icon when working on a book or light table:
Click it to select and it will replace the book or light table viewer with the standard image viewer. Work on your images and click it again to get the book or light table back.
The lock icon to the right will lock the viewer to this browser. This is useful if you have multiple browsers open and want to look through them while keeping the book or light table on the screen.
This Full Screen article shows how useful the full screen mode is. This Laying Out A Book article has an example of creating a new image version and editing it while in book view. And Working With Multiple Browsers shows all the ways that multiple browsers can be usefully employed.
|
Site Focus: The Daily WTF
2006-12-30
The Daily WTF has a tag line that expresses exactly what it posts on a daily basis: Curious Perversions in Information Technology. Stories include inept management, peculiar programming techniques (Code Snippet of the Day), disastrous database techniques, labyrinthine designs, bizarre and ineffective security techniques, and incredibly misguided product developments . It is heavily tilted towards database, visual basic, enterprise application type of programming, but any member of an IT team will appreciate the material.
From iPhoto to Aperture
2006-12-30
Bakari Chavanu has written an article for MyMac.com about the differences between iPhoto (6) and Aperture (1.5):
Now that I'm working as a wedding and event photographer, I'm shooting hundreds of pictures on each job and am having to meet the challenge of uploading, managing, and outputting photos for my clients. The process hasn't been easy. I've been looking at management systems like Adobe's Bridge and Lightroom programs, and even iView Media Pro, but with the latest update of Apple's Aperture, I think I may have found solutions to my larger and more complex digital photo management and processing problems. And believe me, when you're processing hundreds of photos for a waiting client, digital management is a problem that is not easily solved with iPhoto or even Adobe Bridge.
He has recently moved to Aperture and so is still learning its features. The site also has reviews of several books on and related to digital photography: The Digital Photography Book, Digital Photography: the Missing Manual, and Create Your Own Photo Blog.
Now that I'm working as a wedding and event photographer, I'm shooting hundreds of pictures on each job and am having to meet the challenge of uploading, managing, and outputting photos for my clients. The process hasn't been easy. I've been looking at management systems like Adobe's Bridge and Lightroom programs, and even iView Media Pro, but with the latest update of Apple's Aperture, I think I may have found solutions to my larger and more complex digital photo management and processing problems. And believe me, when you're processing hundreds of photos for a waiting client, digital management is a problem that is not easily solved with iPhoto or even Adobe Bridge.
He has recently moved to Aperture and so is still learning its features. The site also has reviews of several books on and related to digital photography: The Digital Photography Book, Digital Photography: the Missing Manual, and Create Your Own Photo Blog.
Aperture: How Do I Remove Built-in Smart Albums?
2006-12-28
Yes it is possible. But no, I don't know how to do it, or more importantly if you should do it.
What I do know is that these built-in smart albums are in every library and are built in to the Aperture application itself. If you remove them from a library, Aperture will put them back.
You can see them in Aperture by opening the application with a control-click and selecting Show Package Contents. Open the Resources folder and look for the FactoryLibraryQueries folder. I don't know the consequences of removing or editing them, so beware of making any modifications.
Aperture: An Idea For a History Browser
2006-12-27
If I am viewing an image in Aperture, how do I know how I got that image?
Aperture has no "reveal master" function, so although I can see the master just by pressing M, I cannot go directly to that master in its project. By looking at the filename in the inspector I can find all the images associated with it and paste that name into a filter and find them that way, but that is long-winded and incomplete.
What I really want is a history view added to the current two browser views (thumbnail and list). A history browser would look something like this:
The thumbnails for the current project or album are displayed vertically down the center of the browser, arranged in whatever order is currently selected. Horizontal lines could separate the image rows, but I am not sure that would add anything.
To the left of each thumbnail is a chain of ancestors. To the right is a tree of descendants. The tree extends vertically to show multiple descendants. Arrows point left to right to show descendency.
Metadata by default shows what each is, where it is, and when it was created. And there is a badge to show the masters. Masters created from other masters show the original master as an ancestor.
By clicking on a thumbnail you see the image in the viewer. There is a way of refocussing the history browser on a selected image so that its enclosing project or album is shown in the vertical strip.
Aperture has no "reveal master" function, so although I can see the master just by pressing M, I cannot go directly to that master in its project. By looking at the filename in the inspector I can find all the images associated with it and paste that name into a filter and find them that way, but that is long-winded and incomplete.
What I really want is a history view added to the current two browser views (thumbnail and list). A history browser would look something like this:
The thumbnails for the current project or album are displayed vertically down the center of the browser, arranged in whatever order is currently selected. Horizontal lines could separate the image rows, but I am not sure that would add anything.
To the left of each thumbnail is a chain of ancestors. To the right is a tree of descendants. The tree extends vertically to show multiple descendants. Arrows point left to right to show descendency.
Metadata by default shows what each is, where it is, and when it was created. And there is a badge to show the masters. Masters created from other masters show the original master as an ancestor.
By clicking on a thumbnail you see the image in the viewer. There is a way of refocussing the history browser on a selected image so that its enclosing project or album is shown in the vertical strip.
Scott's Challenge
2006-12-26
On his blog Scott Stevenson has challenged Mac and Cocoa bloggers to post a recording of themselves playing a guitar or other instrument. Since I don't really play anything, I have to cheat and use Garageband. Here is an orchestral thing I created that includes strings, a grand piano, and a sax: download MP3 or AAC approx 2MB, 2:20.
It does what it was intended to do: create a mood and not be too repetitive. Real musicians could do much better.
It does what it was intended to do: create a mood and not be too repetitive. Real musicians could do much better.
Building a Game Engine with Cocoa
2006-12-26
Matthew Russell has written a good introductory article to Cocoa for O'Reilly's Mac Dev Center that shows how to build a simple game board with pieces that can be moved with mouse clicks. It's good because it shows a simple and comprehensible graphics application without unnecessary complexity and with clear explanation. There is a link to the project code at the end of the article. Other Cocoa articles at O'Reilly can be found on their Cocoa Programming page.
Aperture: Joe Schorr Speaks Again
2006-12-22
O'Reilly Digital Media has posted a third interview with Joe Schorr, Apple's product manager for Aperture.
Griffin Card Reader for the ExpressCard Slot on Macbook Pros
2006-12-22
I see that Griffin Technology is now selling a card reader for the ExpressCard/34 slot found on the MacBook Pros. It works at USB 2.0 speed, so it almost certainly is plain USB 2.0 card reader chip packaged in the ExpressCard/34 format.
ExpressCard is actually supplied with two busses by the computer: USB 2.0 at 480 Mbps and a 1x PCI Express link. PCI Express (that's PCIe, not PCI-X which is PCI-Extended, a parallel bus) runs at a data rate of 2.5Gbps in both directions at once. Even a 1x PCIe link is potentially very fast: about 300MBytes/second for bulk data transfer. Overkill for current Flash cards, but given a few years will be about right. Read all about ExpressCard here.
Apple Modeling The User Interface Using 3D
2006-12-22
Looking at this patent filing by Apple it appears that for Leopard 3D modeling will be used to generate interface elements. With all the talk of problems with huge bit maps and resolution-independence you would think there was a major crisis looming. I think otherwise. If you want an icon with a 3D look in Leopard, just give the OS a 3D model and a scene with lighting and it will build it for you when it is needed.
The problem with scaling 2D vector icons is that the vector data does not encode intent, just look. Fonts have the same problem: simply scaled vector fonts look awful because the scaling is applied without any knowledge of typography, visual cues, or alignment. Adobe and others solved this by adding hints to the vector data. For 3D icons, the shape encodes intent much better than for 2D, but hinting is almost certainly required for consistent quality. So I am predicting that Leopard will define a hinted 3D icon specification and provide tools that will give icon designers a clean resolution-independent environment.
Site Stats
2006-12-21
This site just passed 200,000 page views since I started counting at the beginning of July 2006. I am currently measuring about 40,000 page views a month, so readership is increasing. There are some graphs on the About This Blog page that may be interesting.
Aperture: Can I IPTC Tag And Sort Like I Can In iView ?
2006-12-21
Three questions in all. Quick answers: Yes, Aperture can tag with all the IPTC data that iView has. No, it is not possible to sort by person or location like iView, but some sorting is possible. Yes, I can point you in the right direction. See the articles on this site that cover metadata and filtering workflow.
IPTC Tagging
The IPTC tags can most easily be seen in the filter dialog. Select IPTC from the plus pop-up on the filter dialog:
and then click on the IPTC pop-up that appears:
You can also control which IPTC fields appear in the various metadata sets by editing the metadata sets in the Inspector panel. Open the metadata panel with I and pick one of the metadata sets. Then select IPTC at the bottom to get an opportunity to add or remove them from the set:
The batch change dialog (command shift B) also allows the selection of All IPTC in order to make bulk changes to image metadata:
Sorting Features
The sorting features of Aperture are not as comprehensive as iView, and that is a problem. Sometimes it is very convenient to sort all images by person, or city, or some other random metadata.In the grid view, Aperture allows sorting on only eight pieces of data:
This is a very restricting set. The keywords sort order is not useful because it sorts on the entire comma-separated string of all the keywords applied to an image. So two images each tagged with Bob and Annie will sort differently if they are tagged with other keywords as well. There is no way to tell Aperture to sort on People and have People > Bob and People > Annie be compared to create the sort order.
In the list view, selected by clicking the icon to the left of the sort pop-up:
there are many more options. Any column can be used to sort by clicking on the header (except the tags -- that does not work). Here I sort on aperture:
But I can only sort on one column. So I cannot keep the sort by aperture and also sort by shutter speed.
The list view can be modified too. From the inspector, select the List - Expanded metadata set:
and then add or remove entries. Ensure that the expanded list is used by pressing Command J and checking the view options:
There is set 2 for the list view columns selected as List - Expanded. By adding fields to the list view it is possible to sort on any of the IPTC or EXIF field. If you have only one person in the frame and have used an IPTC field to identify that person, then yes, you can sort by person.
Also note that if you select one of the columns in list view and then change back to grid view, that selection stays:
At least for a little while. If you select away from it, it disappears from the pop-up.
Urlocker On Disruption
2006-12-19
Michael Urlocker's On Disruption site focusses on how disruptive forces in media are affecting the landscape and changing the established rules. He comments on Sony, the iPod, entrepreneurship, telecom, TV, newspapers, Google, innovation, movie downloads, and more. The articles have very interesting links and are worth following.
iView to Aperture Workflow -- Part 1: Preparation
2006-12-18
I have been busy moving all my old photos that were cataloged with iView into Aperture. It has taken a while to work through all the issues and get the workflow straight, but the result is exactly what I wanted: all the images with their metadata transferred. To transfer the metadata I used Annoture, Adam Tow's utility. Special thanks go to Adam for modifying his utility to work around some of the problems I found with my old image files.
Since there is a lot of detail to this process I am presenting what I found as three separate articles covering the three distinct steps needed: preparation, importing, and clean up. This article covers preparation. There are three things that need preparation: the images, the iView catalog, and Aperture.
Next I make sure that all the images and folders are not write-protected. Write-protected images and folders will cause problems later when I want to remove them. By selecting the top-level folder and hitting command-I I can check the permissions:
That needs fixing. I click the pop-up, change it to Read and Write and then click the disclosure triangle to see the details:
Clicking on Apply to enclosed items will propagate the changes down to all the folders and files.
Importing files that have no extension into Aperture can cause problems, so the next exercise is to make sure every file has one. To do that I go through each folder in turn in list view, sorting by type, and dragging anything that either has no extension or a JPG extension to a folder on the desktop. Then I run this Automator action on that folder:
This adds .jpg to anything that does not already have it. Then I drag the renamed images back to the folder they came from. This breaks the link between iView and the renamed images, but that is OK. Annoture can be set up to deal with that.
Then I look for files with names containing forward slash (/) characters. These will cause problems with metadata transfer later on, so I rename them in iView (so that iView knows the new name -- Annoture will not help me here).
Finally I remove all foreign files from the folders I am going to import images from: sounds files, movies, text files, anything that might confuse or upset the process.
The basic philosophy is to change all the metadata types that could have multiple entries for one image into multiple keywords and then move that metadata into Aperture.
First I make a back up my iView catalog. I can now fritz with the metadata as much as I like before moving it over to Aperture.
Then I add a new keyword iviewimport, select all the images in my iView catalog, and apply that keyword to them. This step will let me be assured that metadata for all images has been transferred. If any image in Aperture that came from my old images does not have the iviewimport keyword, then Annoture did not move the metadata for some reason (it could be missing from my iView catalog for instance).
In iVew I have all my people listed under the People category. In Aperture I use keywords. So the next step is to create a keyword for each person in iView. The keywords I create are all lower-case: bob, not Bob. I do this so that the new keywords will not get confused with the existing keywords in Aperture. I will convert all the bob keywords to Bob keywords later. To apply the new keywords, I select that person in the People list, select all of the images that include that person, and drag them to the new keyword.
Then I rename all my iView keywords so that they start with a lower-case letter. The reason for this is that I have several keywords in Aperture that are the same except for their hierarchy. I have Content > Water and also Blog > Water. Another more realistic example would be Color > Orange and Fruit > Orange. When the metadata is transferred from iView to Aperture, Aperture makes a random choice between the available keywords if there is more than one match. So anything tagged with Water in iView will end up either as Content > Water or Blog > Water and have to be sorted out manually. But if I change all the Water keywords to water in iView this will not occur and everything will get the naked water keyword.
Lastly I convert all my labels to keywords. Because hitting number keys is so convenient, I, like a lot of people, have used the labels for rating images instead of the Rating category. But since ratings don't transfer in Annoture I need to convert these to keywords and then deal with them in Aperture. It's the same system as for people. This time the keywords I create are onestar, twostars etc., all lower-case again.
Next I create new projects. I will work on one chunk of images at a time by creating projects in Aperture and filling each with images from my old folder hierarchy. A project will typically be a year or a month of images, depending on how many photos I was taking at the time. For some images, such as scans of old photos, I will have a different structure. I put all of those new, empty, projects into a hierarchy of blue folders with one at the top called iView.
I don't want my existing Aperture keywords to be modified, so I make sure the keyword HUD is locked. That is done by clicking the small lock on the keyword HUD (shift H).
This ensures that the keywords that come in with the imports are put into the Import Keywords part of the keyword HUD.
That's all the preparation done. Next is importing.
Since there is a lot of detail to this process I am presenting what I found as three separate articles covering the three distinct steps needed: preparation, importing, and clean up. This article covers preparation. There are three things that need preparation: the images, the iView catalog, and Aperture.
Prepare Images and Folders
The first step in preparation is to back up my old images. I use spare space on a Firewire drive for this. Backing everything up leaves me an escape route in case I run into a bug or problem I cannot fix, or simply mess everything up by making an error.Next I make sure that all the images and folders are not write-protected. Write-protected images and folders will cause problems later when I want to remove them. By selecting the top-level folder and hitting command-I I can check the permissions:
That needs fixing. I click the pop-up, change it to Read and Write and then click the disclosure triangle to see the details:
Clicking on Apply to enclosed items will propagate the changes down to all the folders and files.
Importing files that have no extension into Aperture can cause problems, so the next exercise is to make sure every file has one. To do that I go through each folder in turn in list view, sorting by type, and dragging anything that either has no extension or a JPG extension to a folder on the desktop. Then I run this Automator action on that folder:
This adds .jpg to anything that does not already have it. Then I drag the renamed images back to the folder they came from. This breaks the link between iView and the renamed images, but that is OK. Annoture can be set up to deal with that.
Then I look for files with names containing forward slash (/) characters. These will cause problems with metadata transfer later on, so I rename them in iView (so that iView knows the new name -- Annoture will not help me here).
Finally I remove all foreign files from the folders I am going to import images from: sounds files, movies, text files, anything that might confuse or upset the process.
Prepare the iView Catalog
I will be using Annoture to move metadata from iView to Aperture. It works well, but it is not magic. There are some things it cannot do, and some things that it can do will make for extra work in Aperture that I can reduce by doing some of the work in iView.The basic philosophy is to change all the metadata types that could have multiple entries for one image into multiple keywords and then move that metadata into Aperture.
First I make a back up my iView catalog. I can now fritz with the metadata as much as I like before moving it over to Aperture.
Then I add a new keyword iviewimport, select all the images in my iView catalog, and apply that keyword to them. This step will let me be assured that metadata for all images has been transferred. If any image in Aperture that came from my old images does not have the iviewimport keyword, then Annoture did not move the metadata for some reason (it could be missing from my iView catalog for instance).
In iVew I have all my people listed under the People category. In Aperture I use keywords. So the next step is to create a keyword for each person in iView. The keywords I create are all lower-case: bob, not Bob. I do this so that the new keywords will not get confused with the existing keywords in Aperture. I will convert all the bob keywords to Bob keywords later. To apply the new keywords, I select that person in the People list, select all of the images that include that person, and drag them to the new keyword.
Then I rename all my iView keywords so that they start with a lower-case letter. The reason for this is that I have several keywords in Aperture that are the same except for their hierarchy. I have Content > Water and also Blog > Water. Another more realistic example would be Color > Orange and Fruit > Orange. When the metadata is transferred from iView to Aperture, Aperture makes a random choice between the available keywords if there is more than one match. So anything tagged with Water in iView will end up either as Content > Water or Blog > Water and have to be sorted out manually. But if I change all the Water keywords to water in iView this will not occur and everything will get the naked water keyword.
Lastly I convert all my labels to keywords. Because hitting number keys is so convenient, I, like a lot of people, have used the labels for rating images instead of the Rating category. But since ratings don't transfer in Annoture I need to convert these to keywords and then deal with them in Aperture. It's the same system as for people. This time the keywords I create are onestar, twostars etc., all lower-case again.
Prepare my Aperture Library
First I make a back up of my Aperture library. A simple copy will work.Next I create new projects. I will work on one chunk of images at a time by creating projects in Aperture and filling each with images from my old folder hierarchy. A project will typically be a year or a month of images, depending on how many photos I was taking at the time. For some images, such as scans of old photos, I will have a different structure. I put all of those new, empty, projects into a hierarchy of blue folders with one at the top called iView.
I don't want my existing Aperture keywords to be modified, so I make sure the keyword HUD is locked. That is done by clicking the small lock on the keyword HUD (shift H).
This ensures that the keywords that come in with the imports are put into the Import Keywords part of the keyword HUD.
That's all the preparation done. Next is importing.
Two More Aperture Podcasts from O'Reilly
2006-12-17
O'Reilly Digital Media has two more podcasts up now. Bill Frakes talks about workflow (24m) (recorded on location and has level problems) in one, and Sal Soghoian talks about automation (14m) in the other.
ApertureCast
2006-12-16
ApertureCast is a podcast created by Ken Huth. If you want to subscribe via the iTunes Music Store, search for "ApertureCast" or use this direct link. His podcasts are in-depth, about thirty minutes to an hour long, and are posted about once a month. There are eight in the set so far. It's a good way to find out what people are saying about and asking about Aperture, pick up tips and answers, and learn about the application, all while you are commuting.
Aperture 1.5: Recover From Broken References to Edited Files
2006-12-16
If referenced masters are edited outside of Aperture without performing Open In External Editor and then the reference is broken, it may not be possible for Aperture to reconnect to the master, even by using the Referenced File Manager.
The reason for this is that to ensure the master being reconnected is the same image as the original, Aperture checks the file size. If editing changes the file size then the Reconnect button on the Referenced File manager will not be enabled.
Of course doing anything to masters behind Aperture's back like this is Bad News and is asking for trouble. To modify an image, whether referenced or managed, always use Open In External Editor, edit the image, save it (it goes into the library as a managed master), and then relocate the new master out of the library.
There are two ways out of this situation. The easy way is to delete the image with the broken reference (don't delete the referenced master!) and then reimport the master. This also loses all the adjustments and metadata, so may not be a suitable solution. The hard way, which I describe below, patches Aperture's library so that the file size information is correct and Aperture will reconnect the broken reference. This method does keep all the metadata and adjustments intact.
To allow Aperture to reconnect the master you have to correct the file size information that is in Aperture's database. To do that you have to get the correct file size, find and edit the image's apfile buried in the library, and then rebuild the database.
The inspector pane (I) shows the file name and the location of the master if it has been set up to do this:
Quit Aperture and navigate to your Aperture library in the Finder. Open the library using control-click Show Package Contents and navigate down into the library, through the blue folder hierarchy, and to the project folder:
Control click the project and Show Package Contents, then navigate to the image folder inside the project via the import group folder.
There it is: Pine tree chopping24.JPG.apfile
Press Return and note the number displayed before the date. That is the correct file size in bytes:
In this case the number is 2128603. The Finder will show a larger file size because it includes space used by the resource fork:
Close and save the apfile.
Repeat this for each of the images you need to recover and then close the library and project packages.
Once done, the images that had their sizes fixed should be reconnectable.
The reason for this is that to ensure the master being reconnected is the same image as the original, Aperture checks the file size. If editing changes the file size then the Reconnect button on the Referenced File manager will not be enabled.
Of course doing anything to masters behind Aperture's back like this is Bad News and is asking for trouble. To modify an image, whether referenced or managed, always use Open In External Editor, edit the image, save it (it goes into the library as a managed master), and then relocate the new master out of the library.
There are two ways out of this situation. The easy way is to delete the image with the broken reference (don't delete the referenced master!) and then reimport the master. This also loses all the adjustments and metadata, so may not be a suitable solution. The hard way, which I describe below, patches Aperture's library so that the file size information is correct and Aperture will reconnect the broken reference. This method does keep all the metadata and adjustments intact.
To allow Aperture to reconnect the master you have to correct the file size information that is in Aperture's database. To do that you have to get the correct file size, find and edit the image's apfile buried in the library, and then rebuild the database.
Find The Image apfile
Each master has an apfile, an XML file that describes the master. To find the apfile, inspect the image in Aperture and note its project, its location in the blue folder hierarchy, its import group, and its master file name. My example image is in the Tree Cutting project:The inspector pane (I) shows the file name and the location of the master if it has been set up to do this:
Quit Aperture and navigate to your Aperture library in the Finder. Open the library using control-click Show Package Contents and navigate down into the library, through the blue folder hierarchy, and to the project folder:
Control click the project and Show Package Contents, then navigate to the image folder inside the project via the import group folder.
There it is: Pine tree chopping24.JPG.apfile
Find the correct file size for the image master
Open the Terminal application and type "ls -l " (that is lower case L, lowercase S, space, hyphen, lowercase L, space). Locate the image file in the finder and drag the image file icon onto the terminal window and let go:Press Return and note the number displayed before the date. That is the correct file size in bytes:
In this case the number is 2128603. The Finder will show a larger file size because it includes space used by the resource fork:
Correct the file size in the apfile
Open the apfile using a text editor or XML editor (drag and drop the file onto the application icon of a text editor like TextWrangler in the dock). Locate the item fileSize and replace the size with the size you determined using the terminal above.Close and save the apfile.
Repeat this for each of the images you need to recover and then close the library and project packages.
Rebuild the Aperture database
Locate the Aperture application icon and option-command double-click. Choose to rebuild the database and wait for it to complete.Once done, the images that had their sizes fixed should be reconnectable.
Getting Real
2006-12-15
Getting Real is a book of advice about creating web-based applications. It also has a lot of good information for anyone creating any kind of product or any kind of business. It's the creation of 37signals, makers of several web-based utilities and applications including BaseCamp, Campfire, and Backpack.
It is available free as HTML, as a PDF for $19, or as a dead tree edition for $29.
Here is an example essay from the HTML version of the book:
Hire good writers
If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
Which is why blogging is so valuable to the blogger: it's great practice for the brain.
It is available free as HTML, as a PDF for $19, or as a dead tree edition for $29.
Here is an example essay from the HTML version of the book:
Hire good writers
If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn't matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more.
That's because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else's shoes. They know what to omit. They think clearly. And those are the qualities you need.
Which is why blogging is so valuable to the blogger: it's great practice for the brain.
Meg Pickard Is Having Some Issues
2006-12-15
She's moved from a PC to a Mac and is finding the experience of locating the perfect photo application infuriating. iPhoto is too simple, and the other alternatives all have problems. Her experience is probably typical of many. It's not that she is ignorant of the technology; as a self-confessed geek, she has many gadgets and builds her own web pages.
My reading is that she is being mislead by her assumption of difficulty and doubt of simplicity from many years with PCs. It must be hard because it is a PC, and if it is simple, it can't be a rich enough tool for my needs.
My reading is that she is being mislead by her assumption of difficulty and doubt of simplicity from many years with PCs. It must be hard because it is a PC, and if it is simple, it can't be a rich enough tool for my needs.
Aperture 1.5: The Hazards of Referenced Masters -- Archives on DVDs
2006-12-14
The introduction of referenced masters in Aperture 1.5 came to many people with a feeling of relief. I can keep my masters where I want them to be! I can burn masters to DVD for archiving! I can use all those Firewire drives to store my images! In other words, I can keep on working the way I used to work: manually organizing storage and applying a cataloging application to that storage so that it is possible to find things.
As people who have been emailing me are finding out, there are hazards to using referenced masters. Aperture is not a cataloging application like iView: it's a librarian and a workflow tool. And using it like it is a cataloging application is going to result in problems.
The difference between a library and a catalog is important. A catalog is part of a library and simply works as an index, telling you where things are. A library actually holds the things that are referenced by the catalog. In the case of Aperture there are two options for the library: either store the images in the same place as the catalog as managed masters and have Aperture do the work, or store the masters externally in other places as referenced masters and you do the work. What work? There's nothing to do. Right?
Let's say you have been shooting for years and have diligently been burning everything to DVDs and cataloging them with Aperture. The day comes when you want to upload all the five star images in your collection to pBase. You create a smart album for the whole library and make it select the five star images. All the thumbnails appear and you select them and go to export them. But:
Well that is because the disk with the images on is not in the drive. But which disk to use? Control-click on an image and try to open in the Finder helps a little:
But that is only the information about one image and I have hundreds spread across many DVDs. The Referenced File Manager is more of a help:
It at least shows me the volume names of the images I have selected, so I know which disks to put in.
But wait. To export all of my hundreds of five-star images in one go I must mount all of the DVDs that contain those images at the same time! So if I have five DVDs that contain the images, I need five DVD players all plugged into my computer at the same time. The same is true of Firewire disks. Unless I can mount all of them at once, I cannot export a selection of images that spans them.
There are two possible solutions. The first is to make the images managed just for the export and then relocate them again when done. That is easier said than done when the media is read-only. The second is to split the export up into chunks so that each chunk only uses one DVD. An equally large pain because I have to do that manually: there is no filter that lets me chop up the images into groups by storage volume.
I have described one of the hazards of referenced masters. You do have work to do, you may just not realize it yet.
As people who have been emailing me are finding out, there are hazards to using referenced masters. Aperture is not a cataloging application like iView: it's a librarian and a workflow tool. And using it like it is a cataloging application is going to result in problems.
The difference between a library and a catalog is important. A catalog is part of a library and simply works as an index, telling you where things are. A library actually holds the things that are referenced by the catalog. In the case of Aperture there are two options for the library: either store the images in the same place as the catalog as managed masters and have Aperture do the work, or store the masters externally in other places as referenced masters and you do the work. What work? There's nothing to do. Right?
Let's say you have been shooting for years and have diligently been burning everything to DVDs and cataloging them with Aperture. The day comes when you want to upload all the five star images in your collection to pBase. You create a smart album for the whole library and make it select the five star images. All the thumbnails appear and you select them and go to export them. But:
Well that is because the disk with the images on is not in the drive. But which disk to use? Control-click on an image and try to open in the Finder helps a little:
But that is only the information about one image and I have hundreds spread across many DVDs. The Referenced File Manager is more of a help:
It at least shows me the volume names of the images I have selected, so I know which disks to put in.
But wait. To export all of my hundreds of five-star images in one go I must mount all of the DVDs that contain those images at the same time! So if I have five DVDs that contain the images, I need five DVD players all plugged into my computer at the same time. The same is true of Firewire disks. Unless I can mount all of them at once, I cannot export a selection of images that spans them.
There are two possible solutions. The first is to make the images managed just for the export and then relocate them again when done. That is easier said than done when the media is read-only. The second is to split the export up into chunks so that each chunk only uses one DVD. An equally large pain because I have to do that manually: there is no filter that lets me chop up the images into groups by storage volume.
I have described one of the hazards of referenced masters. You do have work to do, you may just not realize it yet.
Aperture Plug-In: ApertureToGallery
2006-12-13
Apertureplugins.com has posted an Aperture plug-in that allows a direct export to Gallery. Gallery is open-source web-based photo gallery software.
Aperture 1.5.2 Late Breaking News
2006-12-13
In Aperture, go to the Help menu and select late Breaking News. This will download a PDF file into a Safari page. There are some comments about 1.5.2:
• Starting Aperture with the shift key held down prevents preview generation
• Watermarks now have a Scale option that allows either 1.5 behavior (don't scale, same physical size), or 1.5.1 behavior (do scale, same number of pixels).
There is also a Knowledge Base article that describes how watermark scaling works. You can use this URL to access all of the Knowledge Base articles on Aperture with one click.
• Starting Aperture with the shift key held down prevents preview generation
• Watermarks now have a Scale option that allows either 1.5 behavior (don't scale, same physical size), or 1.5.1 behavior (do scale, same number of pixels).
There is also a Knowledge Base article that describes how watermark scaling works. You can use this URL to access all of the Knowledge Base articles on Aperture with one click.
Aperture: Fix The Reject Key After Upgrading
2006-12-13
If you previously had numeric zero set to be the Reject key, then after upgrading Aperture the fix will have to be reapplied.
Aperture: Undoing Imports
2006-12-13
Several times I have imported images into the library when I intended to leave them where they were and reference them. The import pane has a Store Files popup:
but it is easy to forget to set this before every import and there is no option to make a default. I suspect that at least in Aperture 1.5.1 this control is unpredictable.
If I imported the images and still have the originals where they were, then this is easy to fix. I just click on the project I imported into and filter by import session:
By filtering down to just the erroneously imported images I can select and delete them. Since my originals are still on the hard drive I just redo the import, this time making the correct selections.
If I imported the images but have already deleted them, then the only copies live in the library and I have to get them out. By finding the images with a filter as above I can relocate the masters out of the library and back to where I want them. Selecting the images and using File > Relocate Masters allows me to select the relocation location by folder format and file name:
The only hitch is that if I imported a hierarchy using Files > Import > Folders Into A Project, I may not be able to use the file folder presets on the relocate dialog to create the same folder hierarchy that they originally came from. The good news is that the Aperture library tracks these file movements and so once the relocation is complete there is nothing else to do: no need to reimport anything.
A way to avoid this problem entirely with referenced masters is to always import into the Aperture library and then always relocate later. I recommend that workflow because it means that all of the referenced masters are in locations created by Aperture and so can be put back there should the need arise.
but it is easy to forget to set this before every import and there is no option to make a default. I suspect that at least in Aperture 1.5.1 this control is unpredictable.
If I imported the images and still have the originals where they were, then this is easy to fix. I just click on the project I imported into and filter by import session:
By filtering down to just the erroneously imported images I can select and delete them. Since my originals are still on the hard drive I just redo the import, this time making the correct selections.
If I imported the images but have already deleted them, then the only copies live in the library and I have to get them out. By finding the images with a filter as above I can relocate the masters out of the library and back to where I want them. Selecting the images and using File > Relocate Masters allows me to select the relocation location by folder format and file name:
The only hitch is that if I imported a hierarchy using Files > Import > Folders Into A Project, I may not be able to use the file folder presets on the relocate dialog to create the same folder hierarchy that they originally came from. The good news is that the Aperture library tracks these file movements and so once the relocation is complete there is nothing else to do: no need to reimport anything.
A way to avoid this problem entirely with referenced masters is to always import into the Aperture library and then always relocate later. I recommend that workflow because it means that all of the referenced masters are in locations created by Aperture and so can be put back there should the need arise.
Circular Tables That Grow
2006-12-12
dbfletcher furniture design has some interesting circular tables. Through a rotation by 30 degrees, they expand to seat more people while remaining circular. Watch the videos for a demonstration. No mention of price. I think if you have to ask, you can't afford one.
Aperture 1.5.2 Available
2006-12-12
A 131MByte update for Aperture was released today. It makes the following changes:
• Contact sheet printing
• Smart Albums
• Watermarks
• Lift and stamp
• Image export
• Versions created using an external editor
A download link is available on Apple's download page.
I downloaded and updated my copy. The teeny watermarks problem I was suffering from has been fixed. Speed seems about the same. No database or library rebuilds needed this time.
• Contact sheet printing
• Smart Albums
• Watermarks
• Lift and stamp
• Image export
• Versions created using an external editor
A download link is available on Apple's download page.
I downloaded and updated my copy. The teeny watermarks problem I was suffering from has been fixed. Speed seems about the same. No database or library rebuilds needed this time.
Roughly Drafted
2006-12-11
The creation of Daniel Eran, Roughly Drafted Magazine, is a rapidly-moving account of his analysis of Apple's product strategy. It's an excellent site for understanding what is happening right now and in the future with Mac OS X, iTV, the iPod, the iPhone, Microsoft, Vista, and all the other usually hype-ridden facets of the media/computer/mobile/DRM puzzle.
Aperture: Move The Adjustment Control Output Points
2006-12-11
The levels adjustment control has a nice row of draggable knobs along the bottom and Aperture users are familiar with these. What is not so obvious is that the four points across the top that just look like markers are draggable too. It's an odd interface design that gives otherwise identical controls a different appearance.
Here is the levels adjustment control with the quarter points shown (click the button below the cog to switch between one and three control points):
And after moving the output (top) points, still leaving the source (bottom) points alone:
Unfortunately there is no numerical display or input on the output points, and that reinforces the idea that these points are fixed. How do I communicate the values that I have chosen to someone else?
There is more than simple dragging. Option-dragging will keep the lines at the same angle and move both end points. That is how I got this:
Command-clicking an end point will straighten the line keeping the clicked point stationary, like this:
And this gives a way of figuring out the numerical value of the output points. Command click on one of them to straighten the line, then read off the value from the box at the bottom. Use command Z to undo that, and then repeat with the other two points.
To set the output points given a set of values, type the values into the boxes at the bottom, straighten the lines by command-clicking on the bottom (source) points, then adjust the source points to their correct values.
Here is the levels adjustment control with the quarter points shown (click the button below the cog to switch between one and three control points):
And after moving the output (top) points, still leaving the source (bottom) points alone:
Unfortunately there is no numerical display or input on the output points, and that reinforces the idea that these points are fixed. How do I communicate the values that I have chosen to someone else?
There is more than simple dragging. Option-dragging will keep the lines at the same angle and move both end points. That is how I got this:
Command-clicking an end point will straighten the line keeping the clicked point stationary, like this:
And this gives a way of figuring out the numerical value of the output points. Command click on one of them to straighten the line, then read off the value from the box at the bottom. Use command Z to undo that, and then repeat with the other two points.
To set the output points given a set of values, type the values into the boxes at the bottom, straighten the lines by command-clicking on the bottom (source) points, then adjust the source points to their correct values.
Aperweb
2006-12-09
Readers of French may be interested in Aperweb, a web site dedicated to Aperture that has been put together by Benoît Aragou and Jean-Jacques Cortes. It has many screen shots and function descriptions, and other information about using Aperture. The site has almost thirty pages of description that show and describe the Aperture interface.
Aperture: Can I Set Up A Folder Naming Preset That Includes The Whole Folder Hierarchy?
2006-12-08
You didn't do anything wrong -- that's all there is. While the folder naming preset features of Aperture are flexible, they are also limited.
Folder naming presets are used by Aperture to create folder hierarchies for exported or relocated files. To access the folder naming presets go to File > Export > Export Versions and pick Edit... from the Subfolder Format popup:
Here is what you have to work with:
The buttons can be dragged up to the format line, and the format line can be edited and have words added. Each time a forward slash / is added another folder level will be created. The limitation with the scheme as currently implemented (Aperture 1.5.1) is that Folder Name refers to only the highest level blue folder that the image is located in.
So in this example hierarchy exporting an image from the Crops smart album will result in a Folder Name that is called Blog. Not Coyote, not Tree Cutting:
Using the Folder folder file setting defined above, a version called freddy.jpg will get saved as Blog/Blog/freddy.jpg. Not so helpful. If you want to use multiple levels then you have to use different criteria, such as Year/Folder/Project Name.
But don't forget that you can enter you own names too, so it is possible to create hierarchies like Clients/Atlanta/Year/Folder Name/Project Name where Clients and Atlanta are your own names. This could be saved under the a preset called Atlanta Clients by Year and Project.
Picture Story: A Sunset Opportunity
2006-12-07
This picture story concerns a sunset. It's a rather unusual sunset in that instead of beaches and strolling couples it features rush-hour traffic. In fact if it were not for the rush-hour traffic it would never have been taken at all. It's a story about taking advantage of a unique opportunity.
Aperture: Smart Albums
2006-12-06
[This is an updated version of an article written originally for Aperture 1.1]
I use the smart album feature of Aperture to create the galleries on this site. Here is the top of my projects list:
The Library item includes predefined (and fixed) smart albums. It has star ratings that only includes one and five stars, so I added three more covering two, three, and four stars or better. Clicking on the little magnifying glass next to 3 stars or better brings up this settings window:
Note the heading. It says (Library). That means that its scope is the entire library. It will find all images with a rating greater or equal than three stars whether or not they are in a stack across all projects in the library. Although I have it at the top level of the library, I could drag that smart album anywhere and it would work the same way. A duplicate would do the same.
I have my gallery smart albums organized into a blue folder. They can live anywhere, but this was a nice central place to put them. I have put spaces before some of the names I have used, because Aperture arranges things strictly alphabetically. One space will sit at the top of a list. Two spaces will sit above that, etc.
Everything I want to show in the gallery I keyword with Bagelturf Gallery. I have a keyword set called Actions that I use to select which images I want to appear in which gallery and which I want as (metaphorically mixed) wallpaper on my desktop. The Macros smart album picks out images I have tagged as Macro for their type. Rejects just looks for ratings of X.
To export to a gallery I select the gallery smart album, sort by image date, select the images I have recently added, and export either the masters or the versions to a local folder. Then I fire up Photosite Timesaviour and regenerate the gallery folder locally. That done and checked, I start Transmit and use its synchronizing feature to make the .Mac version of the gallery look like the local one. By exporting only the new images and syncing I save a great deal of uploading.
Why not use the Aperture gallery feature? It is just not flexible enough. In particular I cannot have a three-level gallery where the third level is the original. Also there is no Home button to let me go back to the main gallery index page I have set up.
When I export images destined for the Canon S3 gallery, I export masters and use a preset export called Gallery:
This helps me remember how I did the export last time. Clicking on the Export Preset pop up list and selecting Edit... allows me to choose the export file format:
In this case I have a custom export that just uses the version name. In that way, any image that goes to the gallery can have a meaningful name and I can use that name in the thumbnail page. The Subfolder Format pop-up works the same way, allowing me to structure the exported files if I wish.
The other use for smart albums is in collecting images automatically with a scope that is smaller than the entire library. The smart albums I have shown so far were created with the Library selected, and they reference the whole library. Nice, but slow, and often not what is wanted.
I have a blue folder that contains all my projects for 2006 called, unsurprisingly, 2006. If I select that it shows me the contents of all the projects inside it. If I create a new Smart Album with that Blue Folder selected then I get this:
Its scope is all the projects inside the 2006 blue folder. I can now set up all the options I need and close it and it will always reference just those projects that are in the 2006 blue folder. If I add more projects it will find those too. And it will be faster than a library-wide smart album. And this works at any level in the blue folders and at the project level.
Here is one for my June 2006 project that lives inside the 2006 blue folder:
The joy does not extend to brown folders, however. If you select anything inside a project and create a new smart album, then the smart album is created where you selected, but its scope is always the enclosing project. Still, this is not too shabby.
The moral therefore is to use small projects for speed, and large blue folder hierarchies to support browsing and smart albums.
I use the smart album feature of Aperture to create the galleries on this site. Here is the top of my projects list:
The Library item includes predefined (and fixed) smart albums. It has star ratings that only includes one and five stars, so I added three more covering two, three, and four stars or better. Clicking on the little magnifying glass next to 3 stars or better brings up this settings window:
Note the heading. It says (Library). That means that its scope is the entire library. It will find all images with a rating greater or equal than three stars whether or not they are in a stack across all projects in the library. Although I have it at the top level of the library, I could drag that smart album anywhere and it would work the same way. A duplicate would do the same.
I have my gallery smart albums organized into a blue folder. They can live anywhere, but this was a nice central place to put them. I have put spaces before some of the names I have used, because Aperture arranges things strictly alphabetically. One space will sit at the top of a list. Two spaces will sit above that, etc.
Everything I want to show in the gallery I keyword with Bagelturf Gallery. I have a keyword set called Actions that I use to select which images I want to appear in which gallery and which I want as (metaphorically mixed) wallpaper on my desktop. The Macros smart album picks out images I have tagged as Macro for their type. Rejects just looks for ratings of X.
To export to a gallery I select the gallery smart album, sort by image date, select the images I have recently added, and export either the masters or the versions to a local folder. Then I fire up Photosite Timesaviour and regenerate the gallery folder locally. That done and checked, I start Transmit and use its synchronizing feature to make the .Mac version of the gallery look like the local one. By exporting only the new images and syncing I save a great deal of uploading.
Why not use the Aperture gallery feature? It is just not flexible enough. In particular I cannot have a three-level gallery where the third level is the original. Also there is no Home button to let me go back to the main gallery index page I have set up.
When I export images destined for the Canon S3 gallery, I export masters and use a preset export called Gallery:
This helps me remember how I did the export last time. Clicking on the Export Preset pop up list and selecting Edit... allows me to choose the export file format:
In this case I have a custom export that just uses the version name. In that way, any image that goes to the gallery can have a meaningful name and I can use that name in the thumbnail page. The Subfolder Format pop-up works the same way, allowing me to structure the exported files if I wish.
The other use for smart albums is in collecting images automatically with a scope that is smaller than the entire library. The smart albums I have shown so far were created with the Library selected, and they reference the whole library. Nice, but slow, and often not what is wanted.
I have a blue folder that contains all my projects for 2006 called, unsurprisingly, 2006. If I select that it shows me the contents of all the projects inside it. If I create a new Smart Album with that Blue Folder selected then I get this:
Its scope is all the projects inside the 2006 blue folder. I can now set up all the options I need and close it and it will always reference just those projects that are in the 2006 blue folder. If I add more projects it will find those too. And it will be faster than a library-wide smart album. And this works at any level in the blue folders and at the project level.
Here is one for my June 2006 project that lives inside the 2006 blue folder:
The joy does not extend to brown folders, however. If you select anything inside a project and create a new smart album, then the smart album is created where you selected, but its scope is always the enclosing project. Still, this is not too shabby.
The moral therefore is to use small projects for speed, and large blue folder hierarchies to support browsing and smart albums.
How Apple Will Get You To Try The iPhone
2006-12-06
With all this talk of iPhones coming in January, it is interesting to speculate what Apple's overall strategy is. How will they get anyone to try it? What happens when someone decides to go Apple?
My wild guess is that from some point on (determined by the technology) every iPod will come with a phone built in. In just a few years there will be tens of millions of iPhones in circulation just waiting for their owner's contracts to expire.
And it will be very easy to try it out: just get an iTunes account and sync the iPod. Now you have a working phone and billing is automatic. Use the trail period of free calls to see how it works.
Apple Aquires Proximity
2006-12-05
Announced late today was the news that Apple has acquired Proximity and all their products.
What is interesting here is that Proximity makes workgroup and enterprise media asset management solutions. They do what? These are tools that allow multiple people performing different functions to access centrally-stored media such as clips, images, footage, and audio. It's aimed at newsrooms, production studios, anyone who needs content on tap.
This is good news for Apple because they will be able to integrate this into Final Cut workflow and Aperture workflow. It is all part of Apple's strategy of becoming the digital hub of many traditionally analog or manual activities.
Aperture: Multiple Browsers For Fun and Profit
2006-12-05
One of those little-appreciated features of Aperture is that is is possible to display two thumbnail browsers at the same time. What is more, an unlimited number of browsers can be finger-tip ready in tabs for each of those browsers.
Here is a typical display with one browser. The project it shows is highlighted in the file pane on the left:
To get the second browser, I option-click on a different project or album:
With a viewer present, shift W and option W can be used to change the arrangement of the viewer and the grid views, but I don't have one in this example.
To add more browsers in tabs, I select the browser and command click on more projects or albums or smart galleries or anything else I like. I have added two more to the right-hand browser:
And I can rearrange these by dragging tabs from one browser to the other:
Fun! But where is the profit? Here are some of the things I can do with this. You can probably think of many more.
With a viewer displayed, I select an image in one browser and press Return. That sets the Compare item. Now I select images from the other browser to compare then side-by-side:
As well as comparing them I can also adjust one of them. I might have a certain "look" of one image that I want to get in another. If they are in separate projects I can display them by using Compare and adjust one while using the other as a reference.
By putting the projects or albums that contain the images for the web gallery on tabs (top right), I can use the other browser to hold the web album images (bottom right). I just drag the images from the tabbed browsers into the web gallery browser:
As I click on the tabs I lose the web gallery viewer as it displays the selected image in the other projects. If I want to prevent that (and I usually do) I lock the viewer to the web gallery browser by clicking on the lock:
This same technique also works for light tables:
This is a pretty obvious thing to be able to do, but it can be very useful. I might have a certain number of images that is needed for a specific purpose, or some reason for a specific order of some images. By being able to view both projects at the same time I can move images back and forth until I get what I want.
I set up the workspace with an album on one side and several projects on the other. For each project, I pick out the images I want and drag them to the album. This lets me view the album while I am building it:
This is handy if I am working on a small screen. I can open all the projects I will need in tabs and then close the project pane with W. And I can rearrange the tabs of a browser by dragging.
If I want to take a project and distribute its contents across several albums, I can do that easily with multiple browsers. I click on the project and create several empty albums inside that project, then put all of those albums in tabs on one browser alongside the project in the other browser. Now I can go through my project one image at a time and add the image to the appropriate album as I see fit:
All this works for smart albums too. I can set up two smart albums and view them together. Here is one smart album on the left that shows three star images only, and one on the right that shows two stars or less. As I change the ratings the images "move" from one browser to the other:
Smart albums can be used for many other purposes, so by appropriately setting up the albums I can mark images with a keyword using the keyword button shortcuts (option number) and watch them move from one browser to the other as they are processed in some way.
Sometimes the order of the images is important. Since albums have an order that is independent of other albums and the projects that they draw their images from, displaying albums side-by-side can be used to see the same images in different orders at the same time. Here are the same images viewed by date on the left and by version name on the right:
The same works for filtering. I can have two different filtered views of the same images side-by-side. And don't forget the list view:
The list view provides a very quick way of finding some information that is not so obvious from the other metadata views.
Here is a typical display with one browser. The project it shows is highlighted in the file pane on the left:
To get the second browser, I option-click on a different project or album:
With a viewer present, shift W and option W can be used to change the arrangement of the viewer and the grid views, but I don't have one in this example.
To add more browsers in tabs, I select the browser and command click on more projects or albums or smart galleries or anything else I like. I have added two more to the right-hand browser:
And I can rearrange these by dragging tabs from one browser to the other:
Fun! But where is the profit? Here are some of the things I can do with this. You can probably think of many more.
Compare Images in one album with those in another
With a viewer displayed, I select an image in one browser and press Return. That sets the Compare item. Now I select images from the other browser to compare then side-by-side:
As well as comparing them I can also adjust one of them. I might have a certain "look" of one image that I want to get in another. If they are in separate projects I can display them by using Compare and adjust one while using the other as a reference.
View a web gallery while browsing other projects
By putting the projects or albums that contain the images for the web gallery on tabs (top right), I can use the other browser to hold the web album images (bottom right). I just drag the images from the tabbed browsers into the web gallery browser:
As I click on the tabs I lose the web gallery viewer as it displays the selected image in the other projects. If I want to prevent that (and I usually do) I lock the viewer to the web gallery browser by clicking on the lock:
This same technique also works for light tables:
Move images from one project to another while looking at the contents of both
This is a pretty obvious thing to be able to do, but it can be very useful. I might have a certain number of images that is needed for a specific purpose, or some reason for a specific order of some images. By being able to view both projects at the same time I can move images back and forth until I get what I want.
Create an album from several projects by dragging between browsers
I set up the workspace with an album on one side and several projects on the other. For each project, I pick out the images I want and drag them to the album. This lets me view the album while I am building it:
Switch between projects without bringing up the project pane
This is handy if I am working on a small screen. I can open all the projects I will need in tabs and then close the project pane with W. And I can rearrange the tabs of a browser by dragging.
See a complete project alongside multiple albums from that project
If I want to take a project and distribute its contents across several albums, I can do that easily with multiple browsers. I click on the project and create several empty albums inside that project, then put all of those albums in tabs on one browser alongside the project in the other browser. Now I can go through my project one image at a time and add the image to the appropriate album as I see fit:
See only the two-star or less images alongside the three-star images of a project
All this works for smart albums too. I can set up two smart albums and view them together. Here is one smart album on the left that shows three star images only, and one on the right that shows two stars or less. As I change the ratings the images "move" from one browser to the other:
Smart albums can be used for many other purposes, so by appropriately setting up the albums I can mark images with a keyword using the keyword button shortcuts (option number) and watch them move from one browser to the other as they are processed in some way.
Display the same browser data sorted two ways using an album
Sometimes the order of the images is important. Since albums have an order that is independent of other albums and the projects that they draw their images from, displaying albums side-by-side can be used to see the same images in different orders at the same time. Here are the same images viewed by date on the left and by version name on the right:
The same works for filtering. I can have two different filtered views of the same images side-by-side. And don't forget the list view:
The list view provides a very quick way of finding some information that is not so obvious from the other metadata views.
Aperture: Fix For A Book Printing Problem
2006-12-04
Submitted by Jim DeWitt to Macintouch:
I struggled all weekend to upload an Aperture photo book to Apple Print Products. I was not successful. The following tip from Apple Print Product Customer Service solved the problem, so I thought I'd pass it along:
1. Quit Aperture.
2. From the Finder menu, choose Go > Utilities to access your Utilities folder (or press Shift-Command-U).
3. In your Utilities folder, launch the Keychain Access application.
4. Find the iNetServicesi entry in your Keychain Access window.
5. Select the iNetServicesi entry and press the delete key.
6. Relaunch Aperture and attempt to place your order again.
7. You should be prompted to enter your account information if you deleted the keychain entry successfully.
8. After entering your account information, you should be able to complete your order.
Customer Service's message suggests this is a known problem and that Apple is working on a real fix, instead of this workaround. In the meantime, maybe this tip can spare somebody else a weekend of headaches. And credit to Apple for a prompt response to my complaint.
I struggled all weekend to upload an Aperture photo book to Apple Print Products. I was not successful. The following tip from Apple Print Product Customer Service solved the problem, so I thought I'd pass it along:
1. Quit Aperture.
2. From the Finder menu, choose Go > Utilities to access your Utilities folder (or press Shift-Command-U).
3. In your Utilities folder, launch the Keychain Access application.
4. Find the iNetServicesi entry in your Keychain Access window.
5. Select the iNetServicesi entry and press the delete key.
6. Relaunch Aperture and attempt to place your order again.
7. You should be prompted to enter your account information if you deleted the keychain entry successfully.
8. After entering your account information, you should be able to complete your order.
Customer Service's message suggests this is a known problem and that Apple is working on a real fix, instead of this workaround. In the meantime, maybe this tip can spare somebody else a weekend of headaches. And credit to Apple for a prompt response to my complaint.
Scarecity Does Not Equal Value
2006-12-04
This could be a fine example of a pig and a stick of lipstick. Ars Technica has reported that 100 pink Zunes have been secretly inserted into the distribution system, so that a small number of lucky purchasers will experience that feeling of being lucky and special, to have received a rare thing among the multitudes of ordinary ones.
But of course putting pink lipstick on this pig will not have that effect. Unlike the golden tickets created by Willy Wonka, these special wrappers carry no prize. And whereas prize-giving wrappers on candy do sell more candy (or why else would they still be doing it?) because ordinary people can expand their candy budget easily, the same ploy is not going to work with high-cost MP3 players. Worse, this is going to have the reverse effect, with a hundred people returning their pink players because they got the wrong one. The value of the pink player to them will be less than a regular brown player.
I actually saw a Zune the other day in a store. I had to wait in line for ten minutes to get a chance to play with it! Just kidding. It was being completely ignored. It was at the end of an aisle, clamped in place on a stand so it was impossible to do anything with it except stab at the buttons and see the display. The clamp meant that not only could I not steal it, I also could not rotate it to read the display. Yes, the Zune, or at least this Zune at this moment, was displaying everything landscape fashion on a device mounted portrait fashion and so I had to twist my head around to read the display. Click click, oh another MP3 player. Impossible to hold it or see how it feels because of the clamp. At the stand there were none available to buy. So if I had decided that I wanted to be welcome to the social, I would have had to go looking for the thing.
At Costco the opposite problem existed. There were piles of empty packages for Zunes and iPods, the idea being that you grab a package, take it to the checkout and they give you a real product to take home. So I could buy one easily, but not evaluate it at all, even by risking a crick in my neck. This kind of packaging works for thee iPod because everyone knows what it is and can easily evaluate it elsewhere. Costco is for bargain-hunters who know what they want and are looking for the lowest price. But for the Zune, it's hopeless. While I was there I saw one person looking at the display. He was carefully reading everything printed on the packaging: clearly he did not have enough information to make a purchasing decision and the result was inevitable.
Aperture: How Do I Reset The Numbering Of Images Imported Into A New Project?
2006-12-03
You can do this by using a counter on import and resetting its value each time you create a new project. Aperture does not have counters that are tied to the projects, so this is the only way to achieve what you are trying to do.
On the import pane is an area where the name can be modified as it is imported:
At the bottom of the pop-up for the Version Name is an option to edit the presets. That brings up a dialog that allows you to construct the presets out of various elements:
Among the choices are three different counters that can be added to file names when images are imported: a sequence number, an index number, or a counter.
A sequence number is expressed as index of total like "5 of 86". It starts at one and increases for each image imported. Each import resets the sequence number.
An index number starts at 1 and increases for each image imported. Each import resets the index number.
A counter initially starts at 1 and does not get reset by each import. So each image gets a different number irrespective of how or when it was imported.
As can be seen above, the dialog gives the opportunity to set the starting value of the counter to any number, so this is how it can be reset for a new project. It also allows going back to an old project and adding more images: set the counter starting value to one greater than the highest-numbered image in that project. It would be nice if Aperture offered a project-based counter, but so far it does not.
Digital Camera RAW Updates
2006-12-02
Solve The Right Problem, Win A Prize
2006-12-01
In order to solve a problem, you have to solve the right problem. Obvious really, but not so easy to do in practice, because the root cause is not always waving a red flag.
There has been some interesting discussion online about the design of the Windows shutdown dialog -- or lack of it -- and that had led to more discussion about why Microsoft can't seem to fix things like this and get other things like the Zune anywhere near right. Much blame has been laid on the processes and systems Microsoft has in place to control the gargantuan thing that is Windows, and this comment came to its defense:
The people who designed the source control system for Windows were *not* idiots. They were trying to solve the following problem:
- thousands of developers,
- promiscuous dependency taking between parts of Windows without much analysis of the consequences
--> with a single codebase, if each developer broke the build once every two years there would never be a Longhorn build (or some such statistic - I forget the actual number)
And there you have it. Microsoft is trying to solve a problem that it should never have had in the first place: thousands of developers (ten thousand actually, costing $2B a year). Why? Promiscuous dependency? Why?
Let's look at what this does in real life. From this Slashdot discussion: Why Vista Took So Long
I'd also like to sketch out how actual coding -- what there is of it -- works on the Windows team.
In small programming projects, there's a central repository of code. Builds are produced, generally daily, from this central repository. Programmers add their changes to this central repository as they go, so the daily build is a pretty good snapshot of the current state of the product.
In Windows, this model breaks down simply because there are far too many developers to access one central repository -- among other problems, the infrastructure just won't support it. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.
So in addition to the above problems with decision-making, each team had no idea what the other team was actually doing until it had been done for weeks.
The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option.
Now contrast this to what happens Apple:
I used to work at Apple, in the OS and frameworks groups.
There is a master "train" for a release; projects that don't change are "forwarded" to that train, meaning no source changes are required. When a project needs to be submitted for a change for the new release, a new "view" is created for its specific changes. Every few days, a build is produced, sometimes using previously compiled bits from the old "train", sometimes its a full world build (which can take several days) but otherwise building all the latest submissions.
Then there's a fairly labor intensive "integration" phase where the built bits are all put on a box and booted. If a "quicklook" QA process shows that the build is hoarked, the integrator goes and pesters the submitters of the latest project that was submitted and gets them to fix it. (Some percentage of the time, the new code has exposed a bug elsewhere, regardless, the project that is the proximal cause of the failure is rolled back to the previous revision, it anticipation that all the projects that need to rev be submitted at once.)
The whole thing is set up through symlinks via NFS, so if you want to see the latest version of any piece of code in the system (modulus those projects that are "locked down" for security issues) you can just get your release name, append the build number, and you've got the source code, symbol'd binaries and build log *for any release* at your fingertips.
When a new build comes out, you just do a clean install. It takes about two hours on the internal network, so typically you pull the disk image and slam it to a firewire drive, (usually, you can bum a disk with the image already grabbed from a teammate) and do a full install in 15 minutes. I can't imagine having to spend a day (as some other posted mentioned) setting up a machine...
Most projects have 3 or 4 contributors. In many cases, and entire framework is the responsibility of a single person (and he or she may actually own several small frameworks.) Lots of small projects produce cleaner interfaces that lead to fewer dependencies. (Of course there are dependencies, and circular ones, but these are kept to a minimum.) Projects are encouraged to use public API from other projects, rather than SPI or other project internals. If there's something useful enough for some other project to use, its first made into SPI for internal consumption, with the goal that developers will eventually be able to use it through a public API.
Most groups don't have dedicated QA by the way - the engineers are responsible for their code, and everyone is generally just very smart about what they're doing.
As to this start menu problem: the entire UI team is about 5 individuals, plus Steve Jobs and Scott Forstall - and they're likely to say "Thats fucking stupid, just do this" and boom(tm), the decision has been made the product ships, and life goes on.
It looks to me like Apple has solved Microsoft's problem by simply not having the problem: many fewer developers, many fewer dependencies. And of course Apple has its not-so-secret weapon: Objective C. What this means is that Apple has the capability to scale much further than where they are now without getting crippled by complexity and bloat. And because they are actually in control of their products (rather than by large customers or record companies), they can maintain this situation as they scale.
As I write, Apple is a $78.3B company and Microsoft a $288B company. I reckon that Microsoft has topped out, so Apple has to grow to less than four times its current size (3.6 times) to have a market capitalization greater than Microsoft. At 20% per year growth, that's only seven years. And during that time, they will eat a huge piece of the PC business away from the current players.
I'll make a wild prediction here: AAPL will be at 160 by the end of 2007. Ninety dollars a share seemed impossible less than a year ago, and yet the price today is 91.66, so it's not that crazy an idea. Why so high if only 20% growth? Because by the end of 2007 Apple will no longer be viewed as a niche player. Once their full potential is appreciated, there will be a huge rush to get on board the stock. Not a bad prize to win.
There has been some interesting discussion online about the design of the Windows shutdown dialog -- or lack of it -- and that had led to more discussion about why Microsoft can't seem to fix things like this and get other things like the Zune anywhere near right. Much blame has been laid on the processes and systems Microsoft has in place to control the gargantuan thing that is Windows, and this comment came to its defense:
The people who designed the source control system for Windows were *not* idiots. They were trying to solve the following problem:
- thousands of developers,
- promiscuous dependency taking between parts of Windows without much analysis of the consequences
--> with a single codebase, if each developer broke the build once every two years there would never be a Longhorn build (or some such statistic - I forget the actual number)
And there you have it. Microsoft is trying to solve a problem that it should never have had in the first place: thousands of developers (ten thousand actually, costing $2B a year). Why? Promiscuous dependency? Why?
Let's look at what this does in real life. From this Slashdot discussion: Why Vista Took So Long
I'd also like to sketch out how actual coding -- what there is of it -- works on the Windows team.
In small programming projects, there's a central repository of code. Builds are produced, generally daily, from this central repository. Programmers add their changes to this central repository as they go, so the daily build is a pretty good snapshot of the current state of the product.
In Windows, this model breaks down simply because there are far too many developers to access one central repository -- among other problems, the infrastructure just won't support it. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.
So in addition to the above problems with decision-making, each team had no idea what the other team was actually doing until it had been done for weeks.
The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option.
Now contrast this to what happens Apple:
I used to work at Apple, in the OS and frameworks groups.
There is a master "train" for a release; projects that don't change are "forwarded" to that train, meaning no source changes are required. When a project needs to be submitted for a change for the new release, a new "view" is created for its specific changes. Every few days, a build is produced, sometimes using previously compiled bits from the old "train", sometimes its a full world build (which can take several days) but otherwise building all the latest submissions.
Then there's a fairly labor intensive "integration" phase where the built bits are all put on a box and booted. If a "quicklook" QA process shows that the build is hoarked, the integrator goes and pesters the submitters of the latest project that was submitted and gets them to fix it. (Some percentage of the time, the new code has exposed a bug elsewhere, regardless, the project that is the proximal cause of the failure is rolled back to the previous revision, it anticipation that all the projects that need to rev be submitted at once.)
The whole thing is set up through symlinks via NFS, so if you want to see the latest version of any piece of code in the system (modulus those projects that are "locked down" for security issues) you can just get your release name, append the build number, and you've got the source code, symbol'd binaries and build log *for any release* at your fingertips.
When a new build comes out, you just do a clean install. It takes about two hours on the internal network, so typically you pull the disk image and slam it to a firewire drive, (usually, you can bum a disk with the image already grabbed from a teammate) and do a full install in 15 minutes. I can't imagine having to spend a day (as some other posted mentioned) setting up a machine...
Most projects have 3 or 4 contributors. In many cases, and entire framework is the responsibility of a single person (and he or she may actually own several small frameworks.) Lots of small projects produce cleaner interfaces that lead to fewer dependencies. (Of course there are dependencies, and circular ones, but these are kept to a minimum.) Projects are encouraged to use public API from other projects, rather than SPI or other project internals. If there's something useful enough for some other project to use, its first made into SPI for internal consumption, with the goal that developers will eventually be able to use it through a public API.
Most groups don't have dedicated QA by the way - the engineers are responsible for their code, and everyone is generally just very smart about what they're doing.
As to this start menu problem: the entire UI team is about 5 individuals, plus Steve Jobs and Scott Forstall - and they're likely to say "Thats fucking stupid, just do this" and boom(tm), the decision has been made the product ships, and life goes on.
It looks to me like Apple has solved Microsoft's problem by simply not having the problem: many fewer developers, many fewer dependencies. And of course Apple has its not-so-secret weapon: Objective C. What this means is that Apple has the capability to scale much further than where they are now without getting crippled by complexity and bloat. And because they are actually in control of their products (rather than by large customers or record companies), they can maintain this situation as they scale.
As I write, Apple is a $78.3B company and Microsoft a $288B company. I reckon that Microsoft has topped out, so Apple has to grow to less than four times its current size (3.6 times) to have a market capitalization greater than Microsoft. At 20% per year growth, that's only seven years. And during that time, they will eat a huge piece of the PC business away from the current players.
I'll make a wild prediction here: AAPL will be at 160 by the end of 2007. Ninety dollars a share seemed impossible less than a year ago, and yet the price today is 91.66, so it's not that crazy an idea. Why so high if only 20% growth? Because by the end of 2007 Apple will no longer be viewed as a niche player. Once their full potential is appreciated, there will be a huge rush to get on board the stock. Not a bad prize to win.
The Bagelturf site welcomes Donations of any size