Aperture: Hazards of Referenced Masters -- Bone-Headedness Part 1
2007-07-06
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.
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.
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.
The Bagelturf site welcomes Donations of any size