Previews
Aperture: Recover Images With File Juicer
2007-12-28
File Juicer is a small Mac OS X application that extracts images, movies, text, and other useful data from practically anything. It's useful to Aperture users in two important ways: it can recover usable images from the library if the masters are lost and and can scrounge deleted images from memory cards.
One of the hazards of working with referenced image masters is that their management is the responsibility of the owner. Accidental deletions are not that uncommon, and if that happens then while Aperture can display the images, it cannot export or otherwise use any of the versions that are based on the lost masters. If the masters are truly lost -- no back ups, nothing in the trash -- then whatever images can be found become valuable.
If high resolution previews were generated, then these can be extracted from the Aperture library by simply selecting the thumbnail images in the browser and dragging them to the desktop. They will be in JPEG format and at a size and resolution that depends on the settings in Aperture's preferences:
If there are no previews, then attention turns to the thumbnail files that Aperture stores in each project. It is these images that are used to display the on-screen thumbnails in the browser pane and as placeholder images in the viewer while Aperture processes the RAW image. The files that contain the thumbnails are called AP.Tinies, AP.Minis, and AP.Thumbnails and contain images at 32, 256, and 1024 pixel sizes respectively. They are also present in exported projects, but not in vaults.
To get to the thumbnails, I control-click on the library and select Show Package Contents. Then I navigate down to the project of interest and open that with a control-click and Show Package Contents:
The AP.Thumbnails file is one big chunk of binary data, but inside there are complete JPEG images. File Juicer will go into it and locate and extract the JPEGs without knowing the format of the file.
I launch File Juicer and check that the preferences are set to include JPEG images (at least):
I also make sure that the extracted files will be stored somewhere sensible, such as on the desktop, because I don't want the extracted images put inside my Aperture library:
With the selections I have made, File Juicer will put each image type into a separate folder and create a parent folder for those. It will also get an HTML index file for easy browsing. To start scanning for images, I drop the AP.Thumbnails file from my project onto the main File Juicer window and wait for it to process:
After processing I get a new folder on my desktop containing the images:
And I can either open the jpg folder and browse the image icons in the Finder (or watch a slide show), or click on the index.html icon and see all the images in a browser window as a panoramic display:
Now my images have been extracted, I can reimport them into Aperture and sort through them. They will be smaller then the originals -- only up to 1024 pixels on a side-- and there will be one image per version. So a single lost master will result in five recovered JPEGs if it had five versions in that project. This is good because I get my adjusted images, albeit at low resolution.
Since File Juicer is scavenging for JPEGs rather than following any information that Aperture provides, there are some side-effects. The first is that there may be old images or possibly corrupted images in the folder of JPEGs. The second is that the names of the images are sequential and bear no relationship to the order in which they were taken or anything else. The third is that there is no EXIF or other metadata in the JPEGs, so all the keywords, camera and shooting data are lost.
File Juicer will also recover RAW and other images that have been deleted from camera cards, so if masters have been lost it is possible that they can be obtained that way. The process is very similar to the thumbnail recovery described here, except that there is an extra step at the beginning where File Juicer creates a disk image of the card and scans that.
The File Juicer web site has a page dedicated to its use with Aperture, and one about RAW image formats.
|
Aperture: How Big Should My Library Be?
2007-12-06
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)
Aperture: Can I Store Previews Outside The Library?
2006-10-10
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.
Aperture 1.5: Preview Storage
2006-10-04
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.
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.
Aperture 1.5: Preview Correction
2006-10-02
In a previous article I said this about previews:
2. Previews are never used for on-screen display except for slide shows
I'm wrong about this. Aperture does use the high resolution previews for regular screen display, but only if it thinks it can do better than the built-in library image and the master is off-line.
You can test this yourself. Set the preview quality to be 0 and the size to be 1280x1280. Take a project that uses big images and regenerate all the previews. Now move the project masters to another volume and take it off-line. Try displaying the images in the project at 100% and you will see the fuzzy image based on the built-in library image appear first and then the blocky low-quality preview replace it. If the master is on-line then the preview is not used -- or at least I have never been able to catch it using it with the technique just described.
However, this error does not change my advice. Most people don't need high resolution previews for every image. If you have off-line images and you need high resolution, then previews are most definitely for you.
2. Previews are never used for on-screen display except for slide shows
I'm wrong about this. Aperture does use the high resolution previews for regular screen display, but only if it thinks it can do better than the built-in library image and the master is off-line.
You can test this yourself. Set the preview quality to be 0 and the size to be 1280x1280. Take a project that uses big images and regenerate all the previews. Now move the project masters to another volume and take it off-line. Try displaying the images in the project at 100% and you will see the fuzzy image based on the built-in library image appear first and then the blocky low-quality preview replace it. If the master is on-line then the preview is not used -- or at least I have never been able to catch it using it with the technique just described.
However, this error does not change my advice. Most people don't need high resolution previews for every image. If you have off-line images and you need high resolution, then previews are most definitely for you.
Aperture 1.5: Preview Management
2006-10-02
Quick -- which of these two images has a preview?
Managing previews in Aperture 1.5 is a little tricky. First, there is no "preview" badge that tells you whether an image has a preview already made. Secondly, the controls you need to use to manage these things you cannot see are scattered and confusing.
The easiest way I have found to check if a preview exists is to try to drag the images to the desktop. If there is no preview in the selection they will all spring back to the browser. On the left below, neither image has a preview. On the right, at least one does:
The little red 2 shows how many are being dragged, not how may will actually drop. It's the green plus you have to look for. The contextual menu for these images doesn't give a clue either. For images with and without previews, both of the preview actions Update and Delete are present:
So no clues there. And there is nothing in the metadata to help either. And there is no way to filter based on preview status, size, or quality. Maddening really. I believe that the thinking (evidenced by the default for all images to have previews generated) is that you should not care -- everything has previews and they are always available. But I don't believe that most people really want this because off the extra burden of the files and the processing.
When you drag an image with a preview to the desktop it will always use the master file name. It does this if you drag three versions of one file too, so they all end up with the master name and _2, _3 etc. appended. So if you have given your versions sensible names and expect them to still be there, you will not be happy with this behavior.
The second problem, actually controlling previews, is thornier. Since you can't see what is going on, you are operating blind. However it is possible to maintain order as long as you understand your actions and have some sort of philosophy for your personal use of previews. So I will attempt to make things clearer.
Every thumbnail, and hence every version of every master can have one preview. When the preview is created, the current settings in the prefs window are used:
If you don't limit the size of the preview it will be as big as the image. So a 4000x3000 pixel TIFF will result in a 4000x3000 pixel JPG. If you do limit the size, it will be scaled to fit inside a square of the size given in the pop-up. The size with the asterisk by it is the size of your screen, so is a good choice. The preview quality sets the JPEG compression and the file size varies greatly as it is moved. Anything from 7 up seems to be good. All of my images are JPGs, so previews with unlimited size don't make sense for me (they will just be lower-quality copies) unless I need much lower file sizes by setting the quality way down.
If you change the preview settings, nothing happens to your existing previews. And because you cannot filter on preview status, there is no way for you to update all the images with previews to the new settings fully automatically.
Deleting previews is easy and simple. Control click on the thumbnail selection, project or entire library and select Delete Previews. It always does the same thing: deletes your previews. And they are gone completely -- no copies in the trash.
What you cannot do is delete previews for an album, at least by control-clicking on the album. You can select the album, then select all the images, and then delete the previews.
The next simplest thing to do is to generate a preview. Generate means "delete the existing preview if there is one and build a new one using the current settings in the prefs window". You access Generate by option-control clicking on an image selection, project, or library:
Generate will silently fail if the original image is not available; if it is off-line for instance. It won't delete the old preview and it won't generate a new preview, but it won't tell you that is what happened either.
The logic for Update is as follows: "If a preview is already present, do nothing. Otherwise create a preview using the settings from the prefs window". So update really means make sure that all of these images have a preview. You can only make sure that it is a preview of a certain size and quality, however, by using Generate. My advice on the preview settings is to figure out what you need and then never change it.
Each project has a setting to maintain previews or not. It is in the action menu (cog) on the upper right of the project pane. Select a project and turn maintenance on or off:
With maintenance off, all preview generation is manual. You have to delete, update, generate, all by hand. If you turn maintenance on, it will do a one-time Update for all images in the project (not a generate!) so ensuring that all images have a preview. Once on, maintenance will make previews for all new images and will generate a new preview for all image edits, making sure that the previews stay in sync with the thumbnails. However if you create a new version of an image, it will not get a preview. I think that is a bug. It is certainly inconsistent behavior, and one that adds to the confusion. Further, if you delete that new version, the preview does not get deleted from the library. One way to quickly force a new version preview from the keyboard is to rotate the image left then right using the [ and ] keys.
You can also turn on preview maintenance for the whole library. This does the equivalent of turning on maintenance for every project in the library.
When you turn off preview maintenance for a project preview control goes back to being fully manual. The existing previews stay as they are. Turning off preview maintenance for the whole library simply turns off preview maintenance for every project.
And finally, the setting in the prefs window New Projects Automatically Generate Previews determines whether new projects are created with maintenance turned on or off.
Once you have mastered this behavior you should be able to keep previews from taking over your library and your life. For a workflow-oriented application, they are implemented a little oddly. But I expect Apple to tweak this behavior as they learn how people want to use them. For my own part I will be turning automatic creation of previews off and generating screen-sized images for only the last few months' projects so that I have something to use in other applications and put on my desktop as wallpaper.
Managing previews in Aperture 1.5 is a little tricky. First, there is no "preview" badge that tells you whether an image has a preview already made. Secondly, the controls you need to use to manage these things you cannot see are scattered and confusing.
A Game Of Spot The Preview
The easiest way I have found to check if a preview exists is to try to drag the images to the desktop. If there is no preview in the selection they will all spring back to the browser. On the left below, neither image has a preview. On the right, at least one does:
The little red 2 shows how many are being dragged, not how may will actually drop. It's the green plus you have to look for. The contextual menu for these images doesn't give a clue either. For images with and without previews, both of the preview actions Update and Delete are present:
So no clues there. And there is nothing in the metadata to help either. And there is no way to filter based on preview status, size, or quality. Maddening really. I believe that the thinking (evidenced by the default for all images to have previews generated) is that you should not care -- everything has previews and they are always available. But I don't believe that most people really want this because off the extra burden of the files and the processing.
When you drag an image with a preview to the desktop it will always use the master file name. It does this if you drag three versions of one file too, so they all end up with the master name and _2, _3 etc. appended. So if you have given your versions sensible names and expect them to still be there, you will not be happy with this behavior.
The second problem, actually controlling previews, is thornier. Since you can't see what is going on, you are operating blind. However it is possible to maintain order as long as you understand your actions and have some sort of philosophy for your personal use of previews. So I will attempt to make things clearer.
Preview Size and Quality
Every thumbnail, and hence every version of every master can have one preview. When the preview is created, the current settings in the prefs window are used:
If you don't limit the size of the preview it will be as big as the image. So a 4000x3000 pixel TIFF will result in a 4000x3000 pixel JPG. If you do limit the size, it will be scaled to fit inside a square of the size given in the pop-up. The size with the asterisk by it is the size of your screen, so is a good choice. The preview quality sets the JPEG compression and the file size varies greatly as it is moved. Anything from 7 up seems to be good. All of my images are JPGs, so previews with unlimited size don't make sense for me (they will just be lower-quality copies) unless I need much lower file sizes by setting the quality way down.
If you change the preview settings, nothing happens to your existing previews. And because you cannot filter on preview status, there is no way for you to update all the images with previews to the new settings fully automatically.
Deleting Previews
Deleting previews is easy and simple. Control click on the thumbnail selection, project or entire library and select Delete Previews. It always does the same thing: deletes your previews. And they are gone completely -- no copies in the trash.
What you cannot do is delete previews for an album, at least by control-clicking on the album. You can select the album, then select all the images, and then delete the previews.
Generating Previews
The next simplest thing to do is to generate a preview. Generate means "delete the existing preview if there is one and build a new one using the current settings in the prefs window". You access Generate by option-control clicking on an image selection, project, or library:
Generate will silently fail if the original image is not available; if it is off-line for instance. It won't delete the old preview and it won't generate a new preview, but it won't tell you that is what happened either.
Updating Previews
The logic for Update is as follows: "If a preview is already present, do nothing. Otherwise create a preview using the settings from the prefs window". So update really means make sure that all of these images have a preview. You can only make sure that it is a preview of a certain size and quality, however, by using Generate. My advice on the preview settings is to figure out what you need and then never change it.
Maintaining Previews
Each project has a setting to maintain previews or not. It is in the action menu (cog) on the upper right of the project pane. Select a project and turn maintenance on or off:
With maintenance off, all preview generation is manual. You have to delete, update, generate, all by hand. If you turn maintenance on, it will do a one-time Update for all images in the project (not a generate!) so ensuring that all images have a preview. Once on, maintenance will make previews for all new images and will generate a new preview for all image edits, making sure that the previews stay in sync with the thumbnails. However if you create a new version of an image, it will not get a preview. I think that is a bug. It is certainly inconsistent behavior, and one that adds to the confusion. Further, if you delete that new version, the preview does not get deleted from the library. One way to quickly force a new version preview from the keyboard is to rotate the image left then right using the [ and ] keys.
You can also turn on preview maintenance for the whole library. This does the equivalent of turning on maintenance for every project in the library.
When you turn off preview maintenance for a project preview control goes back to being fully manual. The existing previews stay as they are. Turning off preview maintenance for the whole library simply turns off preview maintenance for every project.
And finally, the setting in the prefs window New Projects Automatically Generate Previews determines whether new projects are created with maintenance turned on or off.
Once you have mastered this behavior you should be able to keep previews from taking over your library and your life. For a workflow-oriented application, they are implemented a little oddly. But I expect Apple to tweak this behavior as they learn how people want to use them. For my own part I will be turning automatic creation of previews off and generating screen-sized images for only the last few months' projects so that I have something to use in other applications and put on my desktop as wallpaper.
Aperture 1.5: Who Needs Previews?
2006-09-30
You've upgraded to Aperture 1.5 and clicked on the little box that asked if you wanted to make previews. Now you are waiting while 80,000 images are created and you don't really know why you clicked on that little box. Meanwhile your disk is filling up, your machine is slow, and the fans are going crazy.
The fact is you don't understand previews. And you almost certainly don't need the 80,000 new images that Aperture is creating for you right now. Blasphemy!
So, lets get rid of all of those previews that have been generated and take control of the situation. Click on the Library and uncheck Maintain Previews For All Projects in the action menu (cog top right in the projects window):
Then delete all the previews by control-clicking on the Library and selecting Delete Previews For Library:
And while we're at it, prevent any more previews being automatically created by opening the Aperture preferences deselecting New Projects Automatically Generate Previews:
Whew. Those fans will die down in a little while and you will be able to think.
Down to business. There are only four reasons that you need Aperture 1.5 previews:
1. You use slide shows
2. You need high resolution versions of your images with you while you are away from the originals
3. You or someone else needs to access images from other applications (including iLife) while Aperture is not running
4. You want to click and drag thumbnails from Aperture to the Finder or other applications.
And if you do need previews, then you probably don't need a library packed with them at the resolution and quality that Aperture has picked for you.
Furthermore:
1. You don't need previews to view, browse, sort, or rate images while you are away from the originals
2. Previews are never used for on-screen display except for slide shows [update -- see below]
3. Previews cannot be used to export versions or masters
4. Previews are always used at the resolution and quality they were created
Really I did not expect previews to be the way they are, but they are that way.
[Update: I'm wrong about this. Aperture does use the high resolution previews for regular screen display, but only if it thinks it can do better than the built-in library image and the master is off-line. You can test this yourself. Set the preview quality to be 0 and the size to be 1280x1280. Take a project that uses big images and regenerate all the previews. Now move the project masters to another volume and take it off-line. Try displaying the images in the project at 100% and you will see the fuzzy image based on the built-in library image appear first and then the blocky low-quality preview replace it. If the master is on-line then the preview is not used -- or at least I have never been able to catch it using it with the technique just described. However, my error does not change my advice though, given in the paragraph below. If you have off-line images and you need high resolution, then previews are most definitely for you].
Aperture already has images stored in the library that it uses for screen and thumbnail display. You don't have any control over which images have them (all of them do) or the quality or resolution they are generated at. The previews are an extra mechanism that the user can control. But you only need them if you need high quality or high resolution images that you don't have the means or the time to generate from the master on the fly. Hence the rules above.
If you do need previews, then a better way to manage them is as follows:
1. Decide how high a resolution you need and set it up by going to Aperture preferences and selecting the quality and size. Pick the size by figuring out how big you will ever want to view the images away from the originals. Pick the quality by experimentation. A setting of 7 or above seems fine to me. Check the box to share the previews with other applications:
The asterisk shows your screen size. That's a good choice for slide shows.
2. Now pick the projects and albums that you do need previews for, and make them. Control click on the project or album and select Update Previews. When it is done, you are done:
Check on progress by selecting Window > Show Tasks List to see how far it has to go:
There will be more on previews. Managing them is very confusing until you understand a few things.
The fact is you don't understand previews. And you almost certainly don't need the 80,000 new images that Aperture is creating for you right now. Blasphemy!
So, lets get rid of all of those previews that have been generated and take control of the situation. Click on the Library and uncheck Maintain Previews For All Projects in the action menu (cog top right in the projects window):
Then delete all the previews by control-clicking on the Library and selecting Delete Previews For Library:
And while we're at it, prevent any more previews being automatically created by opening the Aperture preferences deselecting New Projects Automatically Generate Previews:
Whew. Those fans will die down in a little while and you will be able to think.
Down to business. There are only four reasons that you need Aperture 1.5 previews:
1. You use slide shows
2. You need high resolution versions of your images with you while you are away from the originals
3. You or someone else needs to access images from other applications (including iLife) while Aperture is not running
4. You want to click and drag thumbnails from Aperture to the Finder or other applications.
And if you do need previews, then you probably don't need a library packed with them at the resolution and quality that Aperture has picked for you.
Furthermore:
1. You don't need previews to view, browse, sort, or rate images while you are away from the originals
2. Previews are never used for on-screen display except for slide shows [update -- see below]
3. Previews cannot be used to export versions or masters
4. Previews are always used at the resolution and quality they were created
Really I did not expect previews to be the way they are, but they are that way.
[Update: I'm wrong about this. Aperture does use the high resolution previews for regular screen display, but only if it thinks it can do better than the built-in library image and the master is off-line. You can test this yourself. Set the preview quality to be 0 and the size to be 1280x1280. Take a project that uses big images and regenerate all the previews. Now move the project masters to another volume and take it off-line. Try displaying the images in the project at 100% and you will see the fuzzy image based on the built-in library image appear first and then the blocky low-quality preview replace it. If the master is on-line then the preview is not used -- or at least I have never been able to catch it using it with the technique just described. However, my error does not change my advice though, given in the paragraph below. If you have off-line images and you need high resolution, then previews are most definitely for you].
Aperture already has images stored in the library that it uses for screen and thumbnail display. You don't have any control over which images have them (all of them do) or the quality or resolution they are generated at. The previews are an extra mechanism that the user can control. But you only need them if you need high quality or high resolution images that you don't have the means or the time to generate from the master on the fly. Hence the rules above.
If you do need previews, then a better way to manage them is as follows:
1. Decide how high a resolution you need and set it up by going to Aperture preferences and selecting the quality and size. Pick the size by figuring out how big you will ever want to view the images away from the originals. Pick the quality by experimentation. A setting of 7 or above seems fine to me. Check the box to share the previews with other applications:
The asterisk shows your screen size. That's a good choice for slide shows.
2. Now pick the projects and albums that you do need previews for, and make them. Control click on the project or album and select Update Previews. When it is done, you are done:
Check on progress by selecting Window > Show Tasks List to see how far it has to go:
There will be more on previews. Managing them is very confusing until you understand a few things.
Aperture 1.5: First Impressions
2006-09-30
My first impression is that my machine is going to be very busy for a long time.
After updating to 10.4.8 I installed and ran Aperture 1.5. After selecting to update my library, my Mac went to work. First there is a preparation stage during which I think it copies all the non-image library information to a safe place. Then it converts projects one by one. Then it validates the projects one by one, presumably comparing them against the data it save during preparation. At this point the projects start to reappear in the projects pane. Then it upgrades all the albums one by one and they reappear.
Then it is done! But not quite. In the background it is generating previews, about 20,000 of them in my case. This will take a while (it is still going). Use Window > Show Tasks List to see how far it has to go:
At the rate it is processing them right now, I have about 4.5 hours still to go. I can use Aperture in the meantime, but I know it is going to be sluggish.
To find out how to use the new loupe, go to Help > Late Breaking News. You bring up the old loupe first (tilde, above the TAB key on my US keyboard), then select View > Use Centered Loupe (command shift tilde). The manual that is in the Help menu is more up to date than the one on the Apple web site, but still incomplete.
The most obvious visual difference is that the keys 1 through 8 no longer add metadata to images. Option 1 through 8 do that. Keys 1 through 5 are now used to change ratings. 0 now means not rated and 9 means reject. + and - increase and decrease as before.
Clicking on the filter button brings up the filter much faster for projects with a lot of keyworded images.
After updating to 10.4.8 I installed and ran Aperture 1.5. After selecting to update my library, my Mac went to work. First there is a preparation stage during which I think it copies all the non-image library information to a safe place. Then it converts projects one by one. Then it validates the projects one by one, presumably comparing them against the data it save during preparation. At this point the projects start to reappear in the projects pane. Then it upgrades all the albums one by one and they reappear.
Then it is done! But not quite. In the background it is generating previews, about 20,000 of them in my case. This will take a while (it is still going). Use Window > Show Tasks List to see how far it has to go:
At the rate it is processing them right now, I have about 4.5 hours still to go. I can use Aperture in the meantime, but I know it is going to be sluggish.
To find out how to use the new loupe, go to Help > Late Breaking News. You bring up the old loupe first (tilde, above the TAB key on my US keyboard), then select View > Use Centered Loupe (command shift tilde). The manual that is in the Help menu is more up to date than the one on the Apple web site, but still incomplete.
The most obvious visual difference is that the keys 1 through 8 no longer add metadata to images. Option 1 through 8 do that. Keys 1 through 5 are now used to change ratings. 0 now means not rated and 9 means reject. + and - increase and decrease as before.
Clicking on the filter button brings up the filter much faster for projects with a lot of keyworded images.
The Bagelturf site welcomes Donations of any size