Multiple Aperture Libraries the best way to go?

I'd say that nobody will dispute that a library with only relatively few images in a few projects will perform better than one large library containing each and every image you captured with your camera(s).

However, one of the main advantages and the purpose of such an Aperture library is to easily find and manage your images. If you split your images into many different libraries they may perform well within their scope of images but you will problably loose much of the performance a well organized library may offer you. Just because you would then always have to take care of which library to open.

As you may export each project at any time to another library if you consider this as beneficial I would not recommend you to worry too much about the number of projects, folders or albums within your library. As long as you build up a consistent taxonomy it will help you organize your photos.

Pros may give both of us an idea of how large a library may grow (e.g. in no. of images or MBytes) until they have experienced problems, if any.

Cheers, d-light

Hi. Welcome to Aperture and the user-to-user forum.

I think you've pretty much got it ... completely reversed.

Aperture has no trouble with enormous numbers of large files (as long as you have up-to-date hardware and 4+ GB of RAM). I have run Libraries with half-a-million Images in c. 20K Projects -- no problems. I consider "large" to be 25 MB. Some users have reported problems with very large files such as stiched panorama TIFFs.

You choke Aperture as a DAM every time you split a Library. Unless you have strong reasons to do otherwise, I recommend using one Library per photographer.

The only strong reason I can think of is security -- but those needs are unusual and particular (forensic photos, etc.).

Both Time Machine and Aperture's in-built back-up feature, "Vault", are engineered as differential back-ups: they only back-up changes, not your whole Library.

"Project" is, imho, the single worst interface decision made by the developers of Aperture. I recommend using "Project" to hold "shoots" -- this was how Aperture was designed, and is still recommended in the User Manual -- and use Folders and Albums for things a photographer would think of as a "Project" (e.g.: "Smith Wedding", "The Deserts of West Africa", "Oktoberfest").

It was generally advised to keep Projects to less than 500 Images. I don't know if this has changed with any of the upgrades to 3.x. My Projects sometimes get close to 1,000 Images, but this is unusual.

Message was edited by: Kirby Krieger -- small additions, and corrected first link.

However, one of the main advantages and the purpose of such an Aperture library is to easily find and manage your images. If you split your images into many different libraries they may perform well within their scope of images but you will problably loose much of the performance a well organized library may offer you. Just because you would then always have to take care of which library to open.

I'd like to add to this exellent argument: With your images distributed over many libraries you'll loose the ability to define relations between your images.

In my Aperture Library are images collected over many years, and it is easy to retrieve images by time, by place, by subject, by any criteria I want. If I need a sequence of images showing how a certain building changed over the last three decades it can be done with a simple smart album, because all images reside in one library.

moonlightcaravan wrote:

I thought, making each Project its own Library would be better sooner than later.

Nope. Like others have eloquently described above, multiple Libraries are a bad idea.

What you do want to do better sooner than later is use a Referenced-Masters Library workflow, which will keep your Library size civilized. Keep the Library on an internal drive and Masters on external drives.

IMO referenced Masters make far more sense than building huge managed-Masters Libraries.

• Hard disk speed. Drives slow as they fill so making the internal drive more full (which managed Masters always does) will slow down drive operation.

• Database size. Larger databases are by definition more prone to "issues" than smaller databases are.

• Vaults. Larger Library means larger Vaults, and Vaults are an incremental repetitive backup process, so again larger Vaults are by definition more prone to "issues" than smaller Vaults are. One-time backup of Referenced Masters (each file small, unlike a huge managed-Masters DB) is neither incremental nor ongoing; which is by definition a more stable process.

Managed-Masters Libraries can work, but they cannot avoid the basic database physics.

Very important is that image originals should be backed up in multiple locations prior to import into Aperture or any other images management application. Yes there are printed workflows that fail to note that critical step. Such manuals, tutorials, etc. are incompetent in that regard.

As you start out with Aperture learn what referenced Masters are, and always use a Referenced-Masters Library. If you screw up and some images get "managed" instead of "referenced" that is no big deal because from within Aperture Masters can easily be relocated.

Managed masters or mixed managed and referenced masters are fine in the beginning with few images; the reason for always using a Referenced-Masters Library even in the beginning with only a few GB of image files is for consistency. Consistency reduces the likelihood of error, and later as Library size grows having Masters referenced on external drives will be far superior.

HTH

-Allen Wicks

Correction.

Please change:

Both Time Machine and Aperture's in-built back-up feature, "Vault", are engineered as differential back-ups: they only back-up changes, not your whole Library.

to read:

Both Time Machine and Aperture's in-built back-up feature, "Vault", are engineered as differential back-ups. After the first complete back-up, they will back-up only changes to your Library (not the entire Library each time).

A good point, Kirby. And with a huge Library, the waiting for that first TM backup to complete could try the patience of a saint. But even that big backup could be done in easy installments, since you can interrupt TM and continue later, if you need to dismount your backup volume for some reason. TM will just continue were it left off the last time.

So what I've heard about Aperture having problems as the library grows very large - not true? It was hearing, reading about this a few times that gave me the idea of multiple libraries.

1. It used to be problematic to make incremental backups of the library, but these problems have been solved. You may have performance issues with a huge library, but only if you make beginner's mistakes when you set up your library. If you understand which operations can be time consuming, you can set up your queries so that not always the whole library has to be scanned. You can define folders encapsulating subsets of your projects and albums, and thus restrict searches to only parts of your library.

2. How does one back up Image Originals - before importing into Aperture? I usually import to Aperture first (to look at and edit the photos) and then delete many of the photos. So there would be no need to have the Image Originals for most of the pictures.

The idea is to copy all your image files from the card to your disk and create a back up the originals, at least until you are satisfied that these images have been imported correctly. The import might go wrong, and maybe you do not even notice it, because you are browsing the previews and not the masters.

3. I think Kirby Krieger already answered this. Time Machine makes an incremental backup. Only the added images will be added to the backup.

I do not use a vault, so i will refrain from answering that part of the question.

4. You would turn your Library in a referenced Library. Use relocate to move the master files to the external disk. Then you can browse your Library, even if the disk it not connected. To edit images you will have to connect the disk, however.