Adam Tow has been migrating his collection of more than 100,000 photos to new drives and to Aperture 2.1. He writes about his experience on his blog. It was a little complicated because he had duplicates and a mixture of managed and referenced photos and had several different schemes of library organization in use.

Tags: Aperture, Library, Migration, Duplicates

After playing with the free trial of Aperture 2.0 yesterday, I purchased the upgrade package and receive my key today. The Aperture menu has an Authorize entry and I could put my key in immediately and get full use of the product.

The next thing I did was update my library. I did a couple of smaller libraries first as a sanity check, and all was well. My 90GB library with 32,000 images took about ten minutes to convert. Inside I can see that the original Aperture database has now been split into two. The original database pretty much doubled in size, while the new one is obviously dedicated to Blobs (binary large objects) and is quite small.

The surprise can when I quit Aperture: quitting took more than 20 minutes! The sheet said Writing Files... and I believe it was updating the database. It also used up an ungodly amount of RAM. I only have 3GB and it sucked up everything it could find. I sampled the Aperture process while it was doing this and saw 16 Exabytes in use -- about 5 billion times what I actually have:

It did finish, and all was well. My guess is that this delay was because I am still on Tiger and this is a Core Data efficiency problem.

Next I looked at the possibility of migrating my images to the new RAW converter:

Entire projects can be converted, or just individual selections. I selected Migrate and got this rather confusing dialog:

Upgrade existing RAW images
This means that of the images selected all the non-RAWs will be left alone. The RAW images will have their RAW converter changed to 2.0 and the versions and previews updated. While I can't go back on this, I can individually set the RAW conversion back to 1.1 from the RAW Fine Tuning adjustment panel if I want:

I can also create new versions manually and compare the RAW 1.1 and RAW 2.0 converters side by side for individual images. Note that none of this affects the masters. The reference to "images" should be to "versions".

Create upgraded versions of existing RAW images
This works exactly the same as Upgrade existing RAW images except that a new version is created (in a stack) with the original and the converter changed to 2.0 for that new version only.

All images
Means all selected RAW images. The other two selections are similar.

I don't recommend updating converters en masse. I am finding that the new converter is quite different, particularly for heavily adjusted images. Here is a quick example: RAW 2.0 is on the left here:

The new RAW converter does do a much better job with highlights.

Tags: Aperture, Updates, Library, Migration, RAW

As you can see the blue september folder has photos in it directly, there used to be several projects in the september folder, now just the folders are there with no projects. Also you can see that April, May, June also have no disclosure triangles next to them indicating they have lost their projects as well. Other months may be missing some projects as well. Also note the project caelyn books near the bottom, this had books in it but is now empty. Ever see anything like this?

If you have projects disappearing but not the images they contain, then you probably have selected Recent Projects at the top of the library pane. Change that to Show All and everything will be back to normal.

Recent Projects will show projects and blue folders that have been recently modified. What is confusing is that clicking on the blue folders will show images, and yet there can be no projects inside the selected blue folder to contain them. For example, I have 2005 selected and images are visible:

Tags: Aperture, Q&A, Library, Projects, Lost Images

Aperture's smart album filtering logic offers only the most basic logical choice: all the conditions set in the dialog or any of the conditions set in the dialog. This means that while there are many different criteria provided, it not apparently possible to combine them in complex ways.

However, due to the fact that there are actually two levels of filtering provided by the thumbnail and grid views, impossible filters can be constructed. For instance, I can find images taken on Wednesday OR Thursday OR Friday AND at between 100 and 130mm focal length. I can find images with the keyword Duck OR Swan OR Goose AND the keyword Lake AND rated two stars and above. And if I want, I can make these type of smart filters specific to a single project or to a collection of projects in a blue folder.

Here is how to combine logic using the two available levels. I'll use the requirement that I need to view all RAW images taken in 2007. To find all RAW images I have to create a filter that ORs together all the different kinds of RAW there can be, since there is no setting for "is RAW".

First I select the library and create a new smart album and call it RAW-2007:

I select the Library before I create the smart album because I want this to work on all my images. The dialog reflects this in its title.

Then I set the match to be ANY and filter to Filename ends with .CR2. I add some more conditions for the file name ending that deal with all the RAW formats I am going encounter:

I could check the Ignore stack groupings box at the bottom if I wanted to look inside stacks. This first filter finds all the RAW images in my library.

I close the dialog and with the smart album still selected I click on the filter icon on the browser, top right.

To set up the second level of filtering I filter on the EXIF capture year and match it to 2007:

I could add more conditions at this point, such as ratings or camera model, if I wished.

To make more filters similar to this one, say for different years, I duplicate the smart album, rename it, and then change the year number in the filter:

This second level of filtering works because each album, project, and smart album remembers its current filter setting. I have to be careful not to change it once I have the thumbnails displayed or else it will not work as expected when I reinvoke it. One way to reduce this risk is to select all the RAW-2007 images and create a new regular album from them (or just use the New Album With Current Images button) Since no more images will be added in 2007, the contents of that static album should never change.

Tags: Aperture, Filtering, Metadata, Smart Albums, RAW, Library

Brett Gross recounts his experience tackling the message from Aperture: An inconsistency in your database has been detected.

He did all the right things. He immediately made a back up of the library. Then he tried repairing the problem. When that didn't work, he broke the problem down and solved one part at a time. After he had some success, he made another back up in addition to the first. Eventually he found what was causing the problem, deleting the offending files, and all was well.

Tags: Aperture, Library, Database, Backing Up

What is missing is a search field at the top of the library pane that filters on the name of projects and folders. Aperture works best with relatively small projects and provides blue folders for grouping them. But as time goes on, the number of projects and folders increases to the hundreds, and the point is reached where it is impossible to remember where anything is; hence the need to be able to filter.

Another missing feature is the ability to tag projects. Aperture is hot on keywords and has all these features based on metadata, but still offers only a hierarchical organization for projects. If I could tag projects then I could classify them in several different ways simultaneously. For instance, I could have some projects tagged Personal and Biking and others tagged Business and Biking and be able to filter to any Biking projects, not caring about the situation in which I shot them.

In the Finder list view I can open and close all folders at once with command right arrow and command left arrow respectively. I can include nested folders if I add the option key. But there is no similar facility in Aperture's library pane. In looking for a project I have to manually open, open, open, all the folders, and then when I'm done, close, close, close, all the folders. This adds to the frustration in dealing with many folders and projects.

Tags: Aperture, Library, Folders, Projects

It's 2008 and I have imported Jan 1 photos but there is no 2008 blue folder under library like my previous years. These are not regular blue folders rather a double rectangle in blue with an asterisk in the bottem right corner. How is this created? Thanks. Great site!

Those are built-in smart albums and there is nothing you can do about them:

I never use them. If you find where they are defined and change them, then Aperture will put them back to their defaults. But you would think that 2008 would have been automatically created since it follows 2007. Every time, so far at least.

The fix is to make regular smart albums for years. I click on Library and create a new smart album like this:

By selecting the library first, the scope of this smart filter is the entire library. Renaming the new smart album and clicking on the magnifying glass gives me the filter dialog. Notice that the title says (Library), showing the scope. I could use the + pop-up top right to add a Date line to the filter and then set a range of dates:

But this is messy. Once the dates are entered they change to include the time and time zone. When I set up one for 2007 the filter did not find images I had shot during the last 8 hours of 2007. I am 8 hours behind UTC, so I assume that this filter works on UTC. Handy for those who require the same universal time comparison worldwide so that everyone agrees on when 2008 starts and ends, but not what I need.

So I go for the quick fix by selecting select EXIF from the + button top right and matching the Capture Year:

In both cases I select Ignore stack groupings in order to allow images inside stacks to be included.

Tags: Aperture, Q&A, Smart Albums, Library, Workflow, EXIF

First, quickly, I love your site, and thank you for the useful information you have on it. Quick question: I have an aperture library with referenced masters. My library is approx. 13000 images, totaling approx 25GB. I do not automatically create previews for the images, in fact I periodically select all images and choose to delete previews. I only have previews for about 200 images that I sync to my iPhone. I use keywords, but not overwhelmingly; I do have Blue and Gray folder organizational structure within Aperture. I have very few smart albums/lightables/etc. Mostly I have 7-8 Blue (top level folders) with each shoot being a separate project under one of the Blue folders. So the question is, why is my ApertureLibrary.aplibrary file over 7GB in size? Thank you in advance for your help.

For 13,000 images, that works out to 540k each, about right in my estimation. The space is used mainly by the thumbnails that Aperture stores for each version.

Here I have a small project with 13 images, all referenced. None of them have previews. To look inside, I open my library with control-click and select Show Package Contents, then navigate down to the project and open that the same way:

Pretty much everything is small except for the AP.Minis and AP.Thumbnails files. The former holds 256 pixel thumbnails at 16 bits per pixel, 128K per image. The latter holds 1024 pixel JPEGs, about 415k each. The whole project is 7.3MB, so those two thumbnail files account for about 95% of the space used. This also shows why vaults are smaller than libraries: they omit the thumbnails.

Creating high resolution previews for these images would add somewhere between 2MB and 5MB per image, depending on the size and fidelity of the JPEGs generated. That would boost the project size by between 26MB and 65MB, a significant increase over the current 7.3MB.

The library has some overhead beyond the projects it contains. By opening the library with control click and Show Package Contents I can see the files at the top level:

The biggest non-project item is the database file at 2.2MB Not particularly significant in this 7GB library.

To a very rough approximation the library size is given by:

(number of managed masters * master size) + (number of versions * 500k) + (number of previews * 3MB)

Tags: Aperture, Q&A, Size, Library, Thumbnails, Previews

Jürgen Banda-Hansmann has written a short series of articles about Aperture that cover:

• Optimize Libraries
• Optimize your folder structure
• Personalize and structure your Keyword List
• Create your own Metadata Presets
• Autostacking

Tags: Aperture, Blogging, Metadata, Keywords, Folders, Stacks, Library, Speed, Presets

Josh and Ellen Anon have a very interesting post and discussion going on at O'Reilly. The topic is this: suppose you have lots and lots of images that were shot as RAW+JPEG in your Aperture library and you no longer want the JPEGs? They can use up a ton of space. How do you get rid of the JPEGs?

The short answer is that you don't. At least not with the tools supplied in Aperture, since Aperture treats the RAW file and the JPEG as a single composite master and won't let you do anything with them individually except create a new master from the JPEG. That new master can be deleted, but it doesn't buy you anything since the original JPEG is still there with the RAW file.

I have as technique that I think is better then Ellen and Josh's. It uses only the Finder and doesn't require any Terminal typing or scripts. And I don't leave any files behind. So without further ado, I'll show you what I do.

[Update: Aperture.fr has an Automator action that achieves the opposite: gets rid of the RAW files and leaves the JPEGs. It does, however, lose any adjustment history. Site is in French]

Here is a project called Yard shoot inside a blue folder:

All three of the images are RAW+JPG. Here they are:

I'll look inside the project to see how it is organized. I open up my Aperture library with control-click and select Show Package Contents, then navigate to the Z folder and then control-click on the Yard shoot project file and select Show Package Contents again. Here are all the files:

I can see the RAW files (CR2) and their JPEG (JPG)sisters. I can also see the apfiles which contain Aperture's information about the image files and the apmaster file that documents the master. What I want to do is to get rid of the JPG files and their apfiles, but leave the CR2 files alone and not leave the apmaster file in a state that will confuse Aperture. Also notice the JPEG files in there that are in the Previews and Thumbnails folders. Those are the previews used for iLife and other applications, and I may want to keep those.

1. Export the project

First I export the project to a temporary location. It looks like this:

2. Open up the project package

It's a package just like the library, so I control-click and select Show Package Contents to view its insides:

3. Find all the JPEG files in the package

I type .JPG into the search box top right and press return:

The Finder window changes to show me the apfiles and the images that match. I can tell the image files apart by looking at the pixel sizes underneath.

4. Select all the files and delete them

If I want to delete all the JPEG files (including the previews) then this step is easy. Select all with command A and delete them with command Delete. Command delete does not appear to do anything at all, but actually it has moved the files to trash. Close the window.

4a. or Select some of the files and delete them

If I want to delete only some of the JPEGs or if I want to leave the previews alone then I have to be selective. By command clicking on all the images that I want to delete, I can make a selection. I'm deleting the JPEGs for images 2563 and 2565 in this case, so I select those.

While it is not critical that the apfiles get deleted too it can be good to be neat. Making this additional selection can be made much easier with the following trick. Press command J to bring up the Finder view options and make sure that This window only is selected. Now select Group By Date and within the group, By Name:

The window changes, but the selections are still there:

Now I can easily command click the apfiles that immediately follow the images already selected and add them to my selection. I do that, and then press command Delete and close the window.

Now if I look in the exported project I see that the JPEGs I wanted gone are gone and the JPEGs I wanted to keep are still there:

5. Reimport the project into Aperture

I create a new blue folder for my project to avoid confusion, and drag the fixed project in:

Now the images I removed the JPEGs from no longer have the option to create a new master from the JPEG:

6. Clean up

After checking the project, I delete the temporary copy and the original. I am done.

Why do all this with an external project? One reason is that it is much safer to operate on a copy of the data than the original, so exporting the project satisfies that urge. The other reason is that the result is much neater. When the project is imported, Aperture does some checking and fixes up the apmaster files.

The original apmaster files have the JPEG listed (originalJPEGFileUUID):

But the fixed and imported image no longer lists the JPEG:

Hopefully Apple will add this facility into a future version of Aperture and we can avoid jumping though all these hoops entirely.

Tags: Aperture, JPEG, RAW, RAW+JPEG, Library, Projects, Deleting

I am very frustrated when I go into aperture and look at my pictures I look at the previews on the bottom and there are a lot of preview photos are the wrong photo. When I click on the photo a different photo comes into the view screeen. What can I do to fix this I tried holding option and command while I started aperture and it said it was regenerating. Afterwards still the same result. Any other suggestions? Also when I click on library now nothing displays in the view window? THanks

It looks like your thumbnails have been corrupted. Rebuilding the database won't fix that, so you'll need to delve into the affected library. It's easy to fix.

Another symptom of corrupted thumbnails is that they look like this:

To fix, quit Aperture and locate the Aperture library with the problem. Control-click on the library icon and select Show Package Contents:

A Finder window will open. Navigate down through the folders (they correspond to the blue folders in your Aperture library) until you get to the project with the problem thumbnails:

Open that project with a control-click Show Package Contents and locate these three files:

Drag those to trash, or select them and hit command-delete.

Close the windows that you opened, and launch Aperture. Aperture will immediately start regenerating the thumbnails, and that could take a little while. To see what it is doing, click on Window > Show Tasks List and you'll get a count-down of the number of images still to process:

When it is done, all should be well, at least with that project. You'll need to repeat this with each affected project in the library.

Tags: Q&A, Aperture, Thumbnails, Library, Corruption

This is the last in a series of short articles about how to protect referenced masters from one of their worst natural enemies: bone-headedness. From Part 1: The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?

Part 4: Write Protect

For maximum paranoia against accidental modification or deletion, write protect the master image files. This can be easily achieved from the Finder.

From the Finder I select the top-level folder of the folder structure to protect and press command I to bring up the Info window. I open up the permissions part at the bottom, and it looks like this:

By changing the Details pop-ups to Read Only and applying it to all enclosed items, the settings are propagated to all the files and folders:

Now if I try to modify a file, I get a dialog like this:

I get an opportunity to override by authenticating, but usually I would not want to, just accepting the OK button. If I drag a file to the trash, I get the same dialog.

To change everything back, I use the same procedure, this time setting the permissions to Read and Write for myself.

Tags: Aperture, Masters, Referenced, Reconnecting, Bone-Headedness, Library

This is a series of short articles about how to protect referenced masters from one of their worst natural enemies: bone-headedness. From Part 1: The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?

Part 3: Organize Masters For Growth

Relocating and renaming masters imported into Aperture helps to ensure that they will not be accidently altered, misplaced, or deleted as referenced files.

But when they are relocated, where should they be put? Everyone has a different system for doing this. Often that system arose from a need to either find images or process them, but these are requirements that Aperture does not have of disk storage: the library and its tools take over that organizational role.

What is left to organize? There must be some logic to the folder structure. My answer is to organize around change and minimize risk. What can change?

Adding Storage

The first thing that changes is that the disk fills up and more is needed. Unless you have a RAID system that can be transparently expanded, you must either add a new disk to your computer and split the masters across both, or replace the old disk with the new one and copy everything over. Which is the better approach depends on how the masters have been organized, so ideally your master organization is planned according to your plans for expansion. Do you have any plans for expansion?

If you are storing referenced masters primarily chronologically, say by month, then you add a new drive and all the new images get put on the new drive and the old ones stay on the old drive. It's a quick upgrade and you are unlikely to accidently delete or damage anything. Further, you can stop backing up the old drive: it will never change. Just keep the old off-site back up until you get rid of the smaller drive a few years from now. One small catch is that the addition of the new drive will happen mid-month. So do you have two July folders, one on each disk, or move the July folder to the new disk and then continue adding to it? I recommend the latter, and will be looking at how that can be achieved in this article.

If you are not storing referenced masters primarily chronologically, then the approach is different. Masters organized by client and then by project cannot be handled the same way as the strictly chronological system because any client could ask for another project and overrun an already-full disk. In this case it makes sense to copy everything over and stop using the old disk. Copying between disks can take a little while, even with fast disks -- about an hour per 100GB -- so this is something that may take some planning. The catch with this method of storage expansion is that backing up will need to include both drives now, so don't forget to change your settings or procedures to do that.

Both method of adding storage require copying, and Aperture can do it for you. In fact you should always use Aperture to do the copying. In that way Aperture always knows where its library masters are at all times and reconnecting is never needed.

To move referenced masters to another drive using Aperture, relocate them using exactly the same system of organization that was in use on the old drive. You already have a preset for this because the current organization or referenced masters was built with it.

Archiving

In deciding how to organize referenced masters there is more to consider than just storage expansion. The other change that occurs is that archiving is needed: some images no longer need to be at-hand and can be stored more cheaply or in a place that is not immediately available. These are not back-ups (copies stored short-term as insurance that you hope to never need) -- they are archives (originals stored long-term with the expectation that they will be needed).

I described one folder systems based primarily on date, and another based on client and project. But there are others. Which one is best? In my mind the best folder system is one that Aperture can create and maintain and that can be adequately backed up incrementally.

That may sound restrictive because you may not want to look at a library organized that way, but remember that the folder organization on the disk does not have to follow the library organization at all. For instance your library may be organized by client and then city (both using blue folders) and then by project because your work involves travel to different locations for each client to shoot vacation accommodation. But since renovation is common, you almost never need access to images that are more than three years old. So you organize your referenced masters on the disk by year and project (using Finder folders) and archive a whole year at a time to DVDs or a hard drive each time you start a new year. Note that the library still contains the thumbnails and the metadata for all images, allowing you to view, tag, and find those other images at any time.

Organize masters to reflect how you archive images and manage storage. Organize the library to reflect how you find and work with images.

Part 4 has been posted.

Tags: Aperture, Masters, Referenced, Reconnecting, Bone-Headedness, Library

This is a series of short articles about how to protect referenced masters from one of their worst natural enemies: bone-headedness. From Part 1: The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?

Part 2: Manage, then Relocate

Always import new images into the library as managed masters as a first step. Then edit, cull, rate, tag, stack as usual. Then finally move the masters out of the library using the Relocate command to a reserved area of your disk and add another prefix to show that they are referenced, such as "REF". Finally, possibly much later, delete the rejects.

You can relocate masters in two ways: either by selecting individual images and from the File menu going to Relocate Masters For Library... or by control-clicking on a project and selecting Relocate Masters for Project to relocate an entire project full of images at once:

Relocating the masters also has the ability to rename as it moves. To relocate and rename at the same time, set up a new Name Format preset from the Relocate masters sheet:

By clicking on the Name Format drop-down and selecting Edit... Give the new name format a name and set it up something like this:

Then select that new name format and do the relocate. As the files are moved, the names will be changed. Here is a referenced master on the disk after it was relocated (I used a slightly different prefix than above in this example to show this image is referenced, omitting the dash):

The original image was called 6830-1.JPG. Importing added MAS-2005-04-20 and relocating added REF.

Why work this way? This workflow keeps all the images that are still being worked on in one place so they can easily be found with a smart album that shows only managed masters. This workflow means that if it's managed, then you're not done with it. The library becomes a staging area. Once relocated and renamed, the master files are immediately identified as being referenced from their name and you know that they have already been processed and so are ready for use or to be archived. And, since importing into the library makes a copy, the originals are still on the card or disk they came from and another layer of corruption insurance has been created.

Creating a smart album to show only managed files is straight forward. Create a new smart album by clicking on the magnifying glass next to the library (so it will apply globally) and add a File Status filter:

Then filter on Managed status and check the Ignore stack groupings box so that stacks don't hide any images:

Part 3 has been posted.

Tags: Aperture, Masters, Referenced, Reconnecting, Bone-Headedness, Library

Hello, I stumbled onto your page looking for help with Aperture., I'm new to digital photography and I think I accidentally moved my, master files to a removable hard drive and then deleted them, thinking, that they were saved in a vault somewhere else. Obviously I don't know, what I'm doing, but is there anyway to get aperture to let me work, with the library images that it has on my hard drive? All of my, pictures are there, in good enough resolution, but aperture won't let, me do anything with them because I don't have the masters. No, exporting, no emailing, no editing, nothing., Am I stuck with looking at these pictures forever and that is it?, Thanks a bunch for any help.

I see a quite a few postings on message boards and get emails from Aperture users who have done disastrous things to their referenced masters because they didn't realize that the files were still part of their Aperture library. Referenced masters are master image files stored outside the Aperture library. This feature allows a small internal hard drive, such as on a laptop, to maintain a very large image library where the originals are stored on a separate removable drive or central storage system. In the other kind of master storage, managed masters, the masters live inside the Aperture library itself. While not impossible, damaging managed masters takes some persistence and the barrier formed by the library protects them against most bone-headed errors.

That referenced masters live outside the library leaves them prone to several kinds of abuse. Moving them by hand is harmless, unless the move goes to another volume. That will break the connection with the library and require a reconnect. Aperture's Referenced File Manager does this well, but it is very fussy about restoring the connection. If the image has been edited, for instance, it will likely not reconnect. If the pixel dimensions have changed, it will not reconnect. If the file size has changed, it will not reconnect. And this is where the big problems start. Since Aperture only checks these things when reconnecting, problems can go undetected for a very long time. A reconnect is needed and suddenly many masters (and hence their versions) are effectively lost.

The best medicine, then, is prevention. So how do you go about protecting referenced masters? They could be stored anywhere and called anything -- what kind of barriers can be constructed to protect them?

This the first of a four-part series on protecting referenced masters.

Part 1: Name Defensively

When you import, rename the masters in such a way that all of them can be seen to be masters. Prefixing with "MAS" or an equivalent short word will make masters instantly recognizable and you will no longer feel compelled to trash them in haste.

The input screen allows a selection for the version name and can optionally rename the masters:

Above that setting is a block of information that gives confirmation of the change if an image is selected:

Another recommendation is to rename the masters in such a way that all of them have unique names. For instance, add the current date to the name given by the camera. This will ensure that as the camera or card numbering rolls over, the images still have unique names. While not critical, this defensive step may help in the future when it is necessary to list or index all of the images. Ensuring unique naming now will obviate managing duplicates and messing with hierarchies later on.

At the bottom of the Version Name drop-down the Edit... option allows the naming schemes to be edited. Here is how MAS prefix used above is defined:

Part 2 has been posted.

Tags: Aperture, Masters, Referenced, Reconnecting, Bone-Headedness, Library

This is really neat. John Hoogstrate has created a PHP-based system for browsing, filtering, and viewing Aperture libraries with a web browser called PHPture. It's open source and available at Source Forge . It uses SQLite to access the Aperture database and makes use of the high-resolution previews feature of Aperture 1.5 to display the images. It only ever reads the database so should be completely safe. Installation is not trivial since it needs PHP 5.

The design is very Aperture-like as you can see from the screen shot. An obvious application for this is when you have a number of people who need to be able to browse a library. Share it on the network or your machine and point PHPture at it. Multiple copies of Aperture are not needed.

It *does* need a new name though.

Tags: Aperture, Web Tools, Library, Interesting Stuff

I have a sizable article published in MacZealots today entitled Backing Up With Aperture. It looks in detail at the various ways of backing up your Aperture library.

Tags: Aperture, Backing Up, Library, MacZealots

TextWrangler is a freeware text editor and general-purpose text-processing tool published by Bare Bones Software. One of the things it is good at is processing a whole folder hierarchy of files at once, making the same edits to each with just a few mouse clicks. Since Aperture libraries and vaults are just large file hierarchies, I can use this tool to browse and modify them.

TextWrangler can be set to automatically process hundreds or thousands of files, so it is a really fast way to destroy an Aperture library too. Conversely, if I really know what I am doing, it is a fast way to find things and make changes that Aperture cannot, such as recovering from corruption, removing problem data, or globally changing parameters.

The simplest way to use TextWrangler is to open a new blank document and drag an Aperture library onto it. TextWrangler reads the file hierarchy and displays it as tab-indented text:

Now I can browse and search this text document. If there are lines that I don't want to see I can use the Text > Process Lines Containing... function to delete or modify all lines that matches criteria I define, such as file name endings or character patterns.

I can also do the same thing with two libraries and two windows and then go to the menu and compare their contents with Search > Compare Two Front Documents. In this way I can compare the contents of two Aperture libraries side by side:

Another way to use TextWrangler is to look inside the files in the library. In the example that follows I browse all my library image file information files (only the XML .apfile files) and examine the information they store about the disk that hosts the image.

I launch TextWrangler and hit command F to bring up the find panel. To get TextWrangler to open the library, I locate it on my hard drive and drag it onto the drawer on the left (the Open dialog will not allow it to be selected):

Pressing the Options... button bottom right allows me to set up a filter so that TextWrangler will only open certain files in the library. I set up the dialog as below:

I click on Edit Filter to set up a new filter called apfiles that will make TextWrangler only open the XML files that describe images in the Aperture library:

Closing that and clicking OK takes me back to the Find window. By typing diskUuid into the top search box and clicking Find All I get a window that shows all the matches:

I can scroll up and down by clicking on the top pane and using the up and down arrow keys. This allows me to view each file in turn in the lower panel and look at the disk and other data that the apfile contains. It's so fast that I can easily flick back and forth across several files and see the differences.

This technique can be used to make global edits on the Aperture library. By filling the Replace With box and clicking Replace All, TextWrangler will go through all the matching files and match and replace the values. Of course this is very dangerous, so I recommend only working on a copy of the library, and even then going very carefully. Since exported projects are almost identical to a library, they make a good practice area.

Many changes to the files that make up the library also have to be made to the database if they are to have any effect. But since the database is out of bounds to applications like TextWrangler, the only way to accomplish this is to quit Aperture, delete the database and then open the library, so causing Aperture to rebuild it. Another way to achieve the same effect is to launch Aperture with option and command held down.

I've only scratched the surface of what TextWrangler can do. It's a very powerful tool and can be put to good use to explore and solve Aperture library problems. But be careful with it!

Tags: Aperture, TextWrangler, Library

To get my randomness I will use the MD5 message digest. That delivers a 128 bit number based on an input of any number of bytes. Since Mac OS X ships with MD5 functions in a dynamic library, all I have to do is to call that appropriately.

Appropriately in this case means using code that has already been written. Andreas Mayer submitted some code to the Cocoa mailing list that creates a category on NSData for MD5 and SHA1 digests. A Cocoa category is a collection of methods that extend those of an existing class. They cannot add ivars. The interface to the category AMDigest looks like this:

It declares two methods, each returning an NSData object with the digest inside. Since it is a category on NSData, the methods are used just as any other NSData methods are. The implementation code wraps some C function calls and returns a new autoreleased NSData object:

To add the methods, I create a new Objective C class called AMDigest in my XCode project and paste in the code. Left as is, this does not work, because I have not told XCode to link to the library and the function calls go unresolved. It took some work to figure out that the libcrypto.dylib file that is provided with OS X is a stub and should not be added to the project in the Frameworks and Libraries folder. All that is actually needed is to select the Random_Wok target and add this item to the build configuration:

To use the new method I also have to #import the header file that contains the interface in my Random_Wok.m file.

The plan is to concatenate the salt and the UUID of the Aperture image together and create an MD5 digest of that. I can then use 64 bits of the digest to create a random string based on the settings of the length, format, and alpha case that the user has selected.

The other parts of this series can be found via the Cocoa page.

Tags: Aperture, Plug-ins, Cocoa, Random Wok, MD5, Library

Very occasionally I need to use an external editor with Aperture. It's rare because I don't do much tweaking of my images, try to remove distortion, composite anything, or create anything artistic with other tools. I actually don't have many other image tools: Photoshop Elements 3 is it. It's PowerPC only, but runs at a quite acceptable speed for my use on this dual Intel iMac.

To use an external editor with Aperture, I must first visit the preferences and choose an application:

The file format choice is between PSD and TIFF. The DPI setting really doesn't matter except in the way it is interpreted by the external editor. It's a number that gives the image an absolute scale and does not affect the number of pixels at all. The image passed to the external editor is always 16 bit. As well as the obvious choices, non-conventional image editors can also be used.

Here is an example of using an external editor. I want to mess with the colors in this picture of a Corvette:

So I control-click the image to open it in Photoshop Elements:

As Photoshop opens, Aperture creates a new master in a stack for me and adds a target-shaped badge so that I know it was created in an external editor:

It's in a stack out of convenience. I can drag it out if I want. The new image is a complete copy with all the same metadata as the original. I adjust my image in Photoshop to get the effect I want:

I don't have all the options in the menus of Photoshop Elements enabled because not all of the filters and effects work with 16 bit images. When I save the image (using Save, not Save As), Aperture sees the file change and updates the thumbnail and the copy in the library:

If I make more adjustments and save again the image is updated again:

I can also convert the image to 8 bit in Photoshop, use some other filters, and save and it will be updated:

Internally Aperture created a new master it the library with the same name as the original, but added (1). This new master is always created in the library, even if the original is referenced:

One thing to watch is that while using Save As in Photoshop will work, it will not update the image in Aperture. The new image has to be imported into Aperture by hand. Apple also has a handy FAQ that describes how to avoid issues with external editors.

Tags: Aperture, External Editor, Library

Congrats on your blog! There definitely is a lack of consciousness on Apple's side with regard to the ease of use of manuals which should - in our opinion - reflect the ease of use of their hard- and software (which is not the case). Thanks for every effort to change that! I spent a lot of time trying to understand the project/album/folder business. It may become a little easier with your help. The next thing (which I suppose is linked with the above subject) I will have to get my teeth in is "How do I delete a version and keep the master"? Until now I have not found a way to delete just this one file and be sure I have not done harm to something else.

A warning dialog is always presented when a master is about to be deleted. When no masters will be deleted, the delete proceeds without the warning and the operation can be undone with command Z.

When you select an image and delete it with Delete Version, that version will always be deleted. The master is only deleted if the last version is deleted, so if you see the dialog, that's the last version. File > Delete Master Image and All Versions always trashes the master and all the versions, and gives the same warning dialog.

Some confusion arises with images in albums. Remember that albums are just a different way of looking at the same images that are in projects. They are not themselves separate versions. Any change to an image in an album (including deleting) will affect the image in the project and all other representations of that image in other albums in exactly the same way. On the other hand, removing an image from an album will make it disappear without deleting it.

Note that the images you see are always versions, since you cannot see or manipulate the master directly. Each time a photo is added to Aperture, it stores the master and creates a version from it that contains no adjustments or modifications. There is nothing special about that particular version. The consequence of this is that if new versions are created either by duplicating existing versions or directly from the master, then none of them is the "master" version. You can delete versions in any order and only when the last version is deleted will the master be deleted.

Tags: Aperture, Deleting, Versions, Masters, Library, Q&A

I'm an advocate for putting everything into one library. That lets me find what I want without trying to figure out how I classified the images I put in. But what if I have several libraries right now and want to merge them into one big library? Aperture has no built-in way to do this.

Merging Aperture libraries can be done almost perfectly just by exporting and importing by project. It requires some extra space: about the same amount as the smallest library you want to merge. That's because to merge, you'll have to export each project from the small library and then import it into the large library. Once all the imports are done, the small library can be deleted. Going from small to large minimizes the amount of extra storage needed.

I say to do it this way (process all the projects first, then delete) rather than deleting projects as you go, because deleting a project deletes its masters. And any other project that has not yet been copied that uses images in an album from a deleted project will have those missing once the libraries are merged.

Merging using prroject export and import will preserve all the versions, edits, metadata, import groups, previews, albums, and almost everything else. Anything in the small library that is not inside a project, however, will not be copied across -- smart albums stored at the top level for instance. So move everything into one project or another before the copy.

To export a project, select it in the projects pane, and select File > Export > Project... That will bring up a dialog to select a destination:

The Consolidate images checkbox will take any referenced masters and make a copy of them in the exported project. The projects in the library are not changed by this. The checkbox appears even if there are no referenced masters in the project, which is a little confusing.

An exported project looks like this in the Finder:

And it can be imported simply by dragging onto the projects pane:

There is one thing extra that will come across with the import: image duplicates. If one project has an album with images from another project, then when the first project is exported, copies of the masters for those album images from the second project will be included in the export. So when the projects are both imported into the destination library, there will be two copies of some of the masters. That will cause duplicates to show up in some smart albums, and may cause confusion if the images are subsequently adjusted and the album versions remain unchanged. Fixing this requires a lot of manual work.

Keywords will come across correctly, since the keyword database is automatically merged. If you are sure that the keywords in both libraries are organized the same way and correct, then I recommend importing the projects with the keyword HUD unlocked. This will allow the keywords to merge. Bring up the keyword HUD with shift H and click the lock icon to lock or unlock:

If the keyword HUD is locked for the import, the new keywords will end up in an Imported Keyword section at the end of the keyword list and they will have to be rearranged by hand.

Hopefully Apple will add the ability to merge libraries to Aperture in the future.

Tags: Aperture, Library, Merging, Masters

Here is how to find your Aperture library if you don't know where it is.

Launch Aperture and open the application preferences under the Aperture menu (or hit command comma). At the top of the window the current library location can be seen and changed:

The ~ character (tilde) means my home folder.

There is also a quick way to find all of your Aperture libraries on any or all of your disks. Open a Finder window -- any one will do. Then press command F. That turns the Finder window into a Find window (confusing but true):

Now select Computer or Home, or appropriate disks (via Others) using the buttons just below the toolbar. That will limit the search to whatever is chosen. Then delete the Last Opened entry by clicking the - button on the right end of the line. All you need for this is one line that starts with Kind, so if there are others, get rid of them too, and change the remaining one to Kind.

On the pop-up to the right of Kind, select Others... and type Library into the box. Instantly you will get a list of all the libraries:

This will find all sorts of libraries, not just Aperture libraries, but you can easily scroll through to find what you are looking for.

The TextWrangler and Preview icons are on my toolbar because I dragged the application icons there. It's a little-known feature that you can put almost anything in the toolbar and it will appear on all the Finder windows for easy access -- either for clicking or for dropping things onto. The only thing I don't recommend adding is servers and other volumes that may go off line. That can hang the Finder.

Tags: Aperture, Library

Following preparation, the next step in moving my old photos from iView to Aperture is importing. There are two things to import: the images and the metadata.

Import Images
At the end of this process my Aperture library will contain managed images. But initially I import all of them by reference into the projects I prepared. The reason for this will become clear. I import entire folder hierarchies at once by using File > Import > Folders Into A Project. This puts all of the images from the folder hierarchy into a project and creates a hierarchy of brown folders and albums that matches the folder organization. In this way I still have my old hierarchy represented but can archive it without manual blue folder work and lots of separate imports. Of course I can throw away the albums if I wish: I may not want to have any remnants of my old folder structure remain in Aperture.

When importing I use a rename setting called Version Dash Date. That takes the version name and adds the image date. I leave the images in their current location. So on the import dialog, the settings look like this:

I don't have to wait for the imports to complete. Aperture will queue imports and automatically go through all of the ones I have set up:

Then when my imports are all complete, I wait for all the thumbnails to build -- just to be sure nothing odd happens -- and check the projects over to make sure they look right.

All of the images so for imported have been referenced, but the next step changes that. For each project in the blue folder I created (called iView) I consolidate the masters with the Move option selected. File > Consolidate Masters for Project brings up this dialog that confirms my selection:

This step moves the referenced masters into my Aperture library, so leaving the original folders empty. But are they empty? If they are not then there has been a problem and I need to go sort it out. Possible reasons for the folders not being empty include bad image files, images files in formats that Aperture will not import, text and other foreign files, and permissions problems.

Any easy way to do this check is to display the top-level folder in list view in the Finder, select everything with command A, and then press option command right-arrow. That opens all the folders recursively and shows their contents. Close them all up again with option command left-arrow.

I deal with anything that has not been consolidated, and get all the remaining images into the library or trash them if they are corrupt.

Once consolidated, I mark all the images with a new keyword notreviewed using the keyword HUD. I'm not sure I will need it, but this is the last opportunity to have a way of automatically tying together all of the images I have removed from my old folder structure.

Import Metadata
Now I break out Annoture. The version I am using is 1.0.2. Annoture processes all of the metadata for the images in a project by scanning the iView catalog for the file names of those images, retrieving the metadata, and adding it to the Aperture database.

Here are the preferences I use for Annoture:

By ignoring file extensions I can have Annoture copy metadata from old files that had no extension but were corrected to have an extension before they were added to Aperture. Comparing capture dates allows images in the iView catalog that have the same name to be distinguished. Without that metadata from the first image found rather than the correct image will be transferred.

I set up the main window like this:

Each time I run Annoture I select the appropriate project in the pop-up. I have to make sure that all of my projects have different names, because it is not possible to distinguish identically-named projects here.

Important: Annoture transfers metadata for each image in the selected Aperture project by examining the current selection displayed by iView. It is important to know this, because if I have a subset of my thumbnails displayed in iView when I run Annoture two things will happen: 1) it will run faster because it has fewer images to scan, and 2) there will be some images that do not have their metadata transferred.

I can use this behavior to my advantage. Since my old images are organized into folders by year or month, I set up the Aperture projects that way. By filtering the iView display by using the Catalog Folder pane:

I can limit the number of images that Annoture has to search and speed it up dramatically. Instead of searching 10,000 images, iView will only search a few hundred. That drops the processing time from 15 seconds per image down to less than one.

Since I tagged all of the images in my iView catalog with iviewimport, any of the imported images in my Aperture that were not successfully processed by Annoture lack the iviewimport keyword. So after copying the metadata for each project I run a filter that looks for all images without iviewimport in the IPTC keyword field:

Now I can examine those images and figure out why they could not be found in the iView catalog. The usual reason is that the image was never put into the iView catalog and hence has no metadata. In other cases the iView thumbnail was incorrect and somehow had become attached to a different image.

Import is now done. Next is the final step: reorganization.

Tags: Aperture, iView, Importing, Keywords, Library

Of course I like your website.. :) Great articles that help a lot. So I had a question of my own, to which I hope you have an answer; Is it possible to remove any of those 'smart' albums under 'Library'?

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.

Tags: Q&A, Aperture, Library, Smart Albums

Don't do what I just did. It caused my Aperture library problems serious enough that I am currently restoring it from a back up. I don't believe I have lost any images or data, just suffered some inconvenience. Others may not be so lucky.

So what did I do? I imported read-only JPG images that lacked JPG extensions as referenced masters and then consolidated them using the Move option. The result was that although Aperture had them in its library (still as read only files), it was convinced that they were referenced but not readable, so showing me the broken link badge. The situation is unrecoverable as far as I could determine.

I am not sure which exact combination of events caused this, but I am sure that the missing extension is part of it. Only the images with the missing extension show the problem. Although I am sure that the read-only JPGs in the library will cause problems later.

Tags: Aperture, Updates, Library

With Halloween almost here, it should not be all that surprising to know that keywords in Aperture 1.5 are haunted. Really they are. In 1.1 keyword management was somewhat confusing and a little dusty, but at least it was under control: you applied keywords to images and there they sat. Suddenly in 1.5 they jump out at you in the dark.

I have turned my attention to keywords. Before I tackled my own scramble of keywords, I wanted to understand what makes the new system tick so I could use if effectively and not fall afoul of anything sinister. I had read a number of reports of some very odd behavior; some of it I had seen myself. One of the first things I did after upgrading to 1.5 was open up the keyword HUD. Where did all that come from? I had many more keywords than before, all sorts of old stuff, and things I didn't think I had ever entered.

So I looked at Apple's documentation for guidance on keywords in Aperture 1.5 and saw what it has to say:

Automatic Updating of the Keywords HUD
The Keywords HUD provides a versatile way to apply keywords to images. The Keywords
HUD is now updated automatically with any keywords you add. For example, when you
enter a new keyword in the Metadata Inspector, that keyword also appears in the
Keywords HUD. When you change a keyword, for example, by changing its spelling or
capitalization, the keyword is updated on all images that have that keyword assigned. In
addition, the Keywords HUD can be locked to prevent unintended changes.

That is all I could find. Two new features; no mention of the spirit world's involvement.

Investigation has shown that there are a lot of changes under the hood, and they are for the better. The behavior of keywords has quite substantially changed in Aperture 1.5 and with a little work I hope to help you understand them. But first, I need to explain keywords in Aperture 1.1.

Keywords in Aperture 1.1

The diagram below shows how I understand keywords worked in Aperture 1.1 (you may want to drag a copy of this to the desktop and open it so you can view it alongside the text):

The dotted lines are manual operations and the solid lines are automatic operations. When Aperture 1.1 was launched, the Keyword HUD got its list of keywords from a global list of keywords stored in the user's Application Support folder. When the application quit, that list was written back to the Keywords.plist file. If you imported a list of keywords, that list just overwrote what was in the plist and the Keyword HUD was updated automatically.

The images themselves were stored as files in the library (managed images only on 1.1) with sidecar files that contained the metadata. When a keyword was manually applied to an image, those sidecar files were updated to reflect the new keywords. If an image was imported and it had keywords, those were put in the sidecar file too. I have also shown another library, Library B. When Library B was opened with Aperture 1.1 it was handled the same way as Library A, reading from the global list of keywords. In that way adding keywords only had to be done once, and they were available in every library.

If new keywords were added to the HUD or current keywords were edited, nothing happened to the keywords in the image sidecar files unless the new keywords were manually applied. So tagging 55 images with Ferd meant that those keywords had to be removed in one operation, then the HUD edited, and then Fred added to the images to correct the error.

Keywords in Aperture 1.5

Now look at this diagram that attempts to illustrate how keywords are managed in Aperture 1.5. Note that although all of the images are not present (they are referenced), their sidecar files are still in the library:


The big difference is that there is a thing called SQLite database inside the libraries. In the 1.1 diagram I did not show the library database because although it is there, it does not participate in keyword management. The other thing to notice is that the database is central to everything connected to keywords. And Aperture's database is very hungry for keywords. Every keyword Aperture 1.5 ever comes across is put into the currently open library's database.

The keywords in the database are synchronized to the Keyword HUD and to the sidecar files. So if you edit a keyword, Aperture 1.5 knows exactly where it is used and can update it immediately. This centralization also explains why Aperture 1.5 is so much faster than 1.1 on filtering with keywords: it's just a database query and it is easily combined with other queries that are used to make the complex filtering that is possible. Aperture 1.5 also allows you to move keywords between hierarchies and move hierarchies of keywords around. All the affected images have their keywords updated to match the new organization.

Because of the close association between the database and the sidecar files, 1.5 can enforce the requirement that the database contain all the keywords of all the images it is managing at all times. This is why in 1.5 when you go to delete a keyword you are forced to remove it from all the images that have it if you proceed: if this were not done, then the keyword database would no longer be complete. The database also contains keywords that are not used in any image.

Another difference is that imported keywords now add to the list of keywords in the HUD (via the database) rather than replacing the list, as was the behavior in 1.1. And images with keywords that are imported, alone or as part of an imported project, (or have keywords added during import) also have those keywords added to the hungry database.

This explains the first spooky behavior of Aperture 1.5: where did all those old keywords come from? They came from Aperture 1.5 rescanning all of my images and sidecar files during the upgrade and storing everything it could find in its database. So all those old images with old keywords have come back from the dead to haunt me. I also think that 1.1 was incorrectly recording the keyword hierarchy in the sidecar files in some cases, so I actually had Activity > Running as well as Running on my images. On 1.1 it made no difference, they behaved the same. But on 1.5 the two show up in two places on the Keyword HUD.

The reason for my including Library B is more obvious now. When Aperture quits and the database is written out to the Keywords.plist file, it will include every keyword that is in any image of library A. If library B is opened, all the keywords used in images in library A will be added to the database in library B because that global list of keywords will be read in. So even if I delete keywords in one library, those same keywords can come back to haunt me via another library that still has them in its database. This is the second type of spooky behavior: Zombie Keywords. To kill them once and for all (after you have added the appropriate correct keywords), select all the zombies with command-clicks, and delete them from all versions. Then close Aperture and open another library. Repeat the delete with all the libraries in turn and they will finally be dead.

There is a third spooky behavior that I think is simply a bug. Sometimes if I delete a keyword and accept that it is going to be removed from all the versions it disappears. But then a short while later it reappears in the Keyword HUD, right in front of my eyes! However if after deleting the keyword I immediately quit Aperture, all is well and it does not come back.

The Way Ahead

So how will I work with the new keyword system of 1.5? I haven't tried yet, so I don't know (another article). But I already know that I prefer the new way: it is faster, more consistent, more comprehensive, and importantly more comprehensible. It gives me the complete picture, warts and all, and allows me to do something about what I see.

I did find a couple of keyword bugs. Show keyword Controls (shift D) is grayed out unless the viewer is visible. And using the period and comma shortcuts for moving up and down the list of keyword sets results in some very odd widths for the keyword buttons. What is with the central justification of the buttons and pop-up anyway? Just right-justify the whole thing and it will stay in exactly the same place as I navigate.

The filter dialog really needs to show keywords as a hierarchy. The biggest improvement to the keyword system I can think of centers around the HUD. Each line should show how many images in the library use that keyword. And all keywords used in the current selection should be bolded. iView works like this and it is very, very useful.

Tags: Aperture, Keywords, Haunting, Library, HUD

[Regarding previews] Do you know where they are located and can this be customized?  I would love to have my library in the external FW drive and have the previews in my local drive, so when I travel, I can always have a small size replica of all my images.  

Previews are stored in the Aperture Library and that cannot be changed. I have some details of exactly how and where in an article on Preview Storage. However, there are a couple of ways of achieving what you want to do.

The first is to copy out the previews from the library each time you want to travel. If you have iView then quit Aperture and drop your Library file onto the iView icon and let it catalog. It will find all your originals and two sizes of preview, one at full size (or whatever you selected in Aperture's prefs), and one at 240x240. Use iView's search features to isolate the previews by finding those created after a certain date, or of a certain type (previews are JPG), or of a certain size, or some other salient features that will work. Once isolated you can use iView's copy tool to duplicate the selection on your laptop. This will also give you an incremental solution because you will be able to see the date you last updated your laptop by examining the file dates and use that to filter the iView results.

The second is to change the way you are working. Put your library on your laptop, complete with previews, and store the originals as referenced images on your Firewire drive. This will mean that you no longer have to make copies and manage the previews so much. If you also have a desktop machine then you can also have a library on that and have it reference the same images on your Firewire drive.

Tags: Aperture, Previews, Library, Q&A

When Aperture upgraded its library the first time 1.5 ran, it changed a few things. One of the things it did was to add a new file called ApertureData.xml to the library. Here is the top level of a small library (opened by control-clicking and selecting Show Package Contents) before the update:

and here it is after the update:

Opening that file XML with a text editor, or better still an XML editor like Property List Editor shows it to be a complete description of all of the previews and where they can be found. In fact it shows two locations: a preview in a Preview folder and a another in a Thumbnail folder.

The purpose of this XML file is to allow other applications such as Keynote to dive into the library and pull out a list of albums and projects, present them to the user for browsing with names and thumbnails, and then fetch the high resolution preview image. In this way, Keynote does not have to mess with Aperture's folder structure, database, or built-in image thumbnails that are used for screen display. And Aperture does not have to be running. An application like Keynote can also keep a copy of some of that data so it can present the user with a window of thumbnails quickly and then update it as it scans and processes in the background.

When you quit Aperture it will sometimes pause while it writes this file to disk. You may see a dialog box appear to this effect.

If I drill down into the project and the import session to the folder with my butterfly image inside, I see the following files:

This image is managed so the original is here too, that's the first file. The .apfile file is a file that helps Aperture maintain the integrity of the file project structure. And the .apmaster and .apversion files describe to Aperture how to process the master for display, including RAW conversion and adjustments. But none of those have any information about previews -- previews are sort of tagged on.

What is new in 1.5 is that there are two folders added: Previews and Thumbnails. The former holds the generated previews for all versions. These can be as big as the master, or can be limited in size by the choice in the prefs window. They do contain metadata, so that is available to any application that can extract it from the JPG file. The thumbnail is always fitted to a 240x240 pixel square. Here is the one from the window above:

So this mechanism, XML file for information and JPG files for data, provides a parallel and independent image system for Aperture. It means that Aperture does not have to know anything about the applications that use the images, and the applications do not need to know anything about how Aperture works or where the originals are or how they were prepared. It is a very simple system.

Tags: Aperture, Previews, Library

Allan Marcus has contributed this handy Applescript to the Apple discussion boards. Compile and save it as an application using Script Studio, then drop onto the icon the Aperture library you want Aperture to open. If you double-click on the icon, Aperture will open.

on open (theFiles)
set lib to quoted form of POSIX path of theFiles
if isAppRunning("Aperture") then
tell application "Aperture" to quit
end if
repeat