Projects
Aperture: My Projects Have Disappeared -- Is My Library Corrupt?
2008-02-11
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:
|
What Is Missing From The Aperture Library?
2008-01-09
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.
Aperture: Having Found One Image With A Filter, How Do I Find Others In The Same Project?
2007-10-08
You are not missing anything obvious. The features for doing this are somewhat limited, but it can be done.
Here is an album that displays some images. I want to find out which project the dog photo comes from:
By selecting the image and bringing up the metadata panel of the information pane I can look at the Master Location:
The Master Location is the name of the project that contains the master, so I can just go look there. If the project is in a blue folder or two, then those folder names will be given in a bread-crumb style list: Outer folder > Inner folder > Project.
A more specific method that will locate the master image more uniquely is to copy the File Name, and do a search on it. Start by creating a filter on the entire library:
And then either paste the file name into the text box:
Or use the + pull-down menu top right to add a new search term (Other Data) and specifically choose the File Name option.
The former can be very slow because it may search all the text in the library in a linear fashion. The latter takes longer to set up, but is more precise, matching only file names, and much faster. In either case, check the Ignore stack groupings box if you want to look inside stacks. More than one image may be found because, depending on how you have your master files named, there may be duplication. In the example I show here, the name that the camera gave me has the date appended, so I will only find a single image.
The same technique can be applied to the caption. I caption everything I keep, layering captions onto many images at a time. To find "similar" images, usually from the same project, I just search using part of the caption.
A fast way of finding images taken with the original (and usually part of the same project) is to note the date it was taken and filter the library on that date:
Using the calendar uses very few clicks and uses indexed information, so can often be the fastest.
None of these methods will show which albums contain a particular image. Nor is is possible to find out how many time and image has been used in albums. The best workaround I can think of is to delve into the library and search for image UUIDs, but this is messy.
Aperture: Delete JPEGs Imported As RAW+JPEG
2007-09-27
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.
First I export the project to a temporary location. It looks like this:
It's a package just like the library, so I control-click and select Show Package Contents to view its insides:
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.
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.
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:
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:
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.
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.
Aperture: How Do I Display The Number Of Images In Each Project?
2007-07-01
Turn on the display of the number of versions in the Aperture preferences:
When you have it turned on, the library shows the number of versions in each project like this:
That version count includes all versions, including those in stacks. So you may have 100 versions in a project, but only 5 images that are really different, the other 95 being the non-pick stack items.
Aperture: How Do I Manage Adjusting, Rating, and Keywording In The Field With A Small Hard Drive?
2007-05-27
After I erase the master files the images and ratings etc still appear in Aperture but of course the images show as off line. Upon returning home I copy all of my images onto my eSATA hard drives (from DVD or from Wolverine). Now I want to have Aperture look for the master images on the eSATA drive and re connect, but cannot figure out how to do this. The only solution I have so far is to re do the rating, culling, keywords etc referencing the images on the eSATA drive and erase the older versions. This besides being time consuming is for me fraught with peril. My administrative skills are almost non existent.
You can reconnect the copied masters with the Referenced File Manager. I have an article that describes how to do this called Burning Masters To DVD and The Referenced File Manager. However, you can make all of this workflow faster and less perilous by working with complete projects rather than individual masters. And you won't have to go near the Referenced File Manager to do it.
As you import images into the Aperture library on your laptop, make the projects fairly small. Do your rating and sorting. When your laptop is too full, export these projects a few at a time.
You can check that the projects look OK by dropping them onto an open TextWrangler document and seeing if the expected files are present:
Looks good to me. Also check the size of the project in the Finder as a sanity check:
My project has 18 images of about 2.5MB each, so that looks right.
Burn as many as will fit onto a DVD, verify the DVD, and then delete the project in the Aperture library and empty the trash. Emptying the trash is necessary because the deleted masters in the projects will be moved there. Repeat with all the projects you want to move. You'll have to come up with a foolproof scheme for naming these projects so there is no chance of deleting the wrong thing.
Now when you get back into the office, just import the projects into Aperture's library. That's it. Mount the DVD and drag the projects to the library:
If you trust that the keywords coming in with the projects are well-behaved (ie match the scheme you are using, have the correct spelling etc.) then before importing the projects, unlock the keyword HUD by bringing it up with shift H and clicking the lock icon. This will give the newly-imported images the same keywords are are already used in the library. If you leave the keyword HUD locked, the imported keywords will be added to a separate keyword hierarchy called Imported Keywords and have to be merged later.
The big advantage of using projects to move images around is that they are self-contained. They include all the masters, versions, keywords, ratings, albums, adjustments, and everything else needed to work instantly as soon as they are put back into the library. They even contain thumbnails, so you won't have to wait for them to be regenerated once you are back in the office.
Aperture: Merging Projects
2007-01-22
Merging Aperture projects is something that I very rarely do. Aperture projects represent the way that images were acquired, and it is unusual for two separate projects to have the same circumstances and therefore belong together.
But here is an example of merging that does make sense: two people shoot the same event at the same time and later each imports their own images into a separate Aperture project to do some initial rating and tagging. Once that is complete, these images could all be merged into a single project (for the event). Now in the same project, stacks can be built from images of a single subject taken simultaneously but from different viewpoints. As separate projects stacks could not be built this way because Aperture requires that all images in a stack come from the same project.
Another advantage of combining projects is that since projects can be exported, this creates a single archivable collection of images, ratings, and metadata.
I will merge these two projects Home and Garden into a single project called Home and Garden:
I select Home, ensure that all the images are visible by clicking on the X in the filter, and select all the images with command A. Then I just drag and drop those images into the Garden project:
That moves the master files into the Garden project if they are managed. If they are referenced, then they stay where they are, but the references to them are moved. Finally I double click Garden to rename it to Home and Garden and delete the now empty Home project. There should be no warning when I delete the Home project: it is empty. If for some reason it is not empty, then this dialog will appear:
And I have to cancel and figure out why images are left in the project before proceeding.
Any albums, galleries, light tables, or smart albums that reference images in the merged projects are not affected by the merge, as would be expected.
There are alternatives to merging projects. Putting the projects into a common blue folder is almost as good as merging the projects. If the blue folder is selected thee bowser will show the contents of the projects intermingled. Blue folders can be nested and so allow a whole hierarchy of projects and project groups to be filtered and browsed. This allows the projects themselves to be small and fast, while the scope of browsing is wide. Filtering works as expected too. Here I have several projects in blue folders and also blue folders in blue folders:
But using a common blue folder has one significant disadvantage: stacking will not work if an attempt is made to include images from more than one project.
Creating an album that contains the sum of the images in a number projects achieves many of the same goals as having a single merged project. It also allows images to be manually discarded without resorting to rating, deleting, or filtering. This allows you to weed out every frame that contains the one guest that everyone would prefer to forget without adding complex keywording. An album of this sort can be located anywhere in the library, inside or outside of any project or blue folder.
Another way of grouping the images from many projects is through a smart album. If all of the images in the two projects share a common keyword or other metadata, then that can be used to find all the images in both projects and a smart album created to recreate the set at any time.
Keeping projects separate can be useful for exporting images or using referenced masters. The dialogs for these actions include the ability to define a folder organization and using the project name is one of the selectable elements:
So in the example used at the beginning, having a separate project for each shooter would allow the images for the whole event to be exported into two folders, one per shooter, together with a different folder structure above and below those folders.
Another potential problem with merging projects is that it can make archiving and moving them difficult simply because of their size.
But here is an example of merging that does make sense: two people shoot the same event at the same time and later each imports their own images into a separate Aperture project to do some initial rating and tagging. Once that is complete, these images could all be merged into a single project (for the event). Now in the same project, stacks can be built from images of a single subject taken simultaneously but from different viewpoints. As separate projects stacks could not be built this way because Aperture requires that all images in a stack come from the same project.
Another advantage of combining projects is that since projects can be exported, this creates a single archivable collection of images, ratings, and metadata.
I will merge these two projects Home and Garden into a single project called Home and Garden:
I select Home, ensure that all the images are visible by clicking on the X in the filter, and select all the images with command A. Then I just drag and drop those images into the Garden project:
That moves the master files into the Garden project if they are managed. If they are referenced, then they stay where they are, but the references to them are moved. Finally I double click Garden to rename it to Home and Garden and delete the now empty Home project. There should be no warning when I delete the Home project: it is empty. If for some reason it is not empty, then this dialog will appear:
And I have to cancel and figure out why images are left in the project before proceeding.
Any albums, galleries, light tables, or smart albums that reference images in the merged projects are not affected by the merge, as would be expected.
There are alternatives to merging projects. Putting the projects into a common blue folder is almost as good as merging the projects. If the blue folder is selected thee bowser will show the contents of the projects intermingled. Blue folders can be nested and so allow a whole hierarchy of projects and project groups to be filtered and browsed. This allows the projects themselves to be small and fast, while the scope of browsing is wide. Filtering works as expected too. Here I have several projects in blue folders and also blue folders in blue folders:
But using a common blue folder has one significant disadvantage: stacking will not work if an attempt is made to include images from more than one project.
Creating an album that contains the sum of the images in a number projects achieves many of the same goals as having a single merged project. It also allows images to be manually discarded without resorting to rating, deleting, or filtering. This allows you to weed out every frame that contains the one guest that everyone would prefer to forget without adding complex keywording. An album of this sort can be located anywhere in the library, inside or outside of any project or blue folder.
Another way of grouping the images from many projects is through a smart album. If all of the images in the two projects share a common keyword or other metadata, then that can be used to find all the images in both projects and a smart album created to recreate the set at any time.
Keeping projects separate can be useful for exporting images or using referenced masters. The dialogs for these actions include the ability to define a folder organization and using the project name is one of the selectable elements:
So in the example used at the beginning, having a separate project for each shooter would allow the images for the whole event to be exported into two folders, one per shooter, together with a different folder structure above and below those folders.
Another potential problem with merging projects is that it can make archiving and moving them difficult simply because of their size.
Aperture: Create New Projects Quickly
2007-01-16
It is possible to create new Aperture projects quickly and without taking your hands off the keyboard:
• Select an existing project that is inside the library or blue folder where you want the new projects to be
• Press command N
• Type the name of the new project
• Don't hit return or click anywhere: just hit command N again and repeat for the next project
• Select an existing project that is inside the library or blue folder where you want the new projects to be
• Press command N
• Type the name of the new project
• Don't hit return or click anywhere: just hit command N again and repeat for the next project
Aperture: Splitting A Project
2007-01-13
Sometimes I want to split an Aperture project into two or more smaller projects. It's pretty rare though, since my projects are simply time-based (one a month) due to the relatively small number of photos I take. Also my picture taking is incidental to the other things I do: there are no clients, locations, models, or weddings for me.
For others this may not be the case and project splitting may be a more regular activity. For instance, after a day in the field with five CF cards and two people, the images associated with similar activities during the day will be split across cards. It's probably a good idea to dump all of the cards into one project and then split the images into several projects by client, shooter, location, or other category that ties them to their acquisition.
Splitting an Aperture project into two or more projects is as simple as dragging thumbnails. Here is a small example project called Home and Garden with 13 images:
And here are the images:
I'll split it into two: one project called Home, and the other called Garden. It is not possible to create a new project from a selection as can be done with albums, so I have to create a new empty project and fill it. Pressing command N with the Home and Garden project selected gives me a new empty project that I can rename:
Then I double click and rename the original project to have the two projects I want:
To move the images I select the project I want to move from, make the selection (manually in this case, but a filter will work too), and drag them to the project I want to move them to:
I wait a little while for the move to complete, and I now have two projects with the original images split between them. (If I had held Option down as I dragged the cursor would have gotten a green plus sign and the move would have become a copy operation)
If it makes sense, I can group these two projects into a blue folder. This will let me filter both of the projects at the same time, selecting all the images in both projects by day or keyword, for instance. To create the blue folder I select the enclosing folder (or the library if I am at the top level) and hit shift command N:
I name the folder Home and Garden, and then drag the two projects into the folder where they are automatically put into alphabetical order:
I can see all of the images in two ways. Either I click on Garden and then option click on Home to get two browsers:
Or I click on Home and Garden folder and get them all in one place:
When a project is split, the import sessions are split as well. Both the Home and the Garden projects have the same two import sessions in my case because I moved photos that were in both. This allows the images to retain information about their source.
Another thing that happens when projects are split is that all the albums that reference the images are adjusted to suit. It doesn't matter where the albums are located: they can be in the project just split or anywhere in the library. One way to organize albums affected by project splits is to give them their own folder to live in:
Selecting the Albums folder does not display the contents of the albums, however.
But before splitting a folder, ask yourself some questions first. The idea of projects in Aperture is to represent the circumstances in which the images were acquired. This is a separate system from the actual file storage (referenced masters do that) and from the image presentation (taken care of by albums, metadata, and filters). Am I splitting because I want to use the new organization to get images out? (don't -- use albums or metadata). Or am I splitting because I want to better represent how the images were acquired (do).
For others this may not be the case and project splitting may be a more regular activity. For instance, after a day in the field with five CF cards and two people, the images associated with similar activities during the day will be split across cards. It's probably a good idea to dump all of the cards into one project and then split the images into several projects by client, shooter, location, or other category that ties them to their acquisition.
Splitting an Aperture project into two or more projects is as simple as dragging thumbnails. Here is a small example project called Home and Garden with 13 images:
And here are the images:
I'll split it into two: one project called Home, and the other called Garden. It is not possible to create a new project from a selection as can be done with albums, so I have to create a new empty project and fill it. Pressing command N with the Home and Garden project selected gives me a new empty project that I can rename:
Then I double click and rename the original project to have the two projects I want:
To move the images I select the project I want to move from, make the selection (manually in this case, but a filter will work too), and drag them to the project I want to move them to:
I wait a little while for the move to complete, and I now have two projects with the original images split between them. (If I had held Option down as I dragged the cursor would have gotten a green plus sign and the move would have become a copy operation)
If it makes sense, I can group these two projects into a blue folder. This will let me filter both of the projects at the same time, selecting all the images in both projects by day or keyword, for instance. To create the blue folder I select the enclosing folder (or the library if I am at the top level) and hit shift command N:
I name the folder Home and Garden, and then drag the two projects into the folder where they are automatically put into alphabetical order:
I can see all of the images in two ways. Either I click on Garden and then option click on Home to get two browsers:
Or I click on Home and Garden folder and get them all in one place:
When a project is split, the import sessions are split as well. Both the Home and the Garden projects have the same two import sessions in my case because I moved photos that were in both. This allows the images to retain information about their source.
Another thing that happens when projects are split is that all the albums that reference the images are adjusted to suit. It doesn't matter where the albums are located: they can be in the project just split or anywhere in the library. One way to organize albums affected by project splits is to give them their own folder to live in:
Selecting the Albums folder does not display the contents of the albums, however.
But before splitting a folder, ask yourself some questions first. The idea of projects in Aperture is to represent the circumstances in which the images were acquired. This is a separate system from the actual file storage (referenced masters do that) and from the image presentation (taken care of by albums, metadata, and filters). Am I splitting because I want to use the new organization to get images out? (don't -- use albums or metadata). Or am I splitting because I want to better represent how the images were acquired (do).
The Bagelturf site welcomes Donations of any size