My Aperture library is getting pretty full and I was considering splitting up my library into multiple libraries for organizational purposes. I'm wondering if this is something that should be done. I am also wondering if by doing so it will make Aperture more efficient while I'm working in it.
I'm just looking for some basic feedback.
Macbook Pro 17, Mac OS X (10.6.7), 2.93 GHz Intel Core 2 Duo, 4 GB 1067 MHz DDR3
Hi Mac. It really depends. In general, smaller Libraries don't run appreciably faster than larger ones. This is partially because the entire database is never loaded. That's why very fast throughput is important (say, replacing a hard drive with a SSD). Equally important, bigger databases are almost always more useful than smaller ones. "All the photos I ever took" is really an order of magnitude more useful than fifty separate databases, one for each year of image capturing ("Show me 'Cats'." "Show me 'Grayscale'." Etc. In short, it is always much easier to create sub-sets than to search across multiple databases.
Therefore, unless you have a pressing reason to break up your database, I wouldn't.
Storage space is cheap today. Buy some 1TB and when you run out of internal space familiarize yourself with Referenced Masters and move your Masters to these external drives (FW800 or faster is recommended).
I have and manage several Aperture Libraries. My rules-of-thumb are:
Hi Mac. It really depends. In general, smaller Libraries don't run appreciably faster than larger ones. This is partially because the entire database is never loaded. That's why very fast throughput is important (say, replacing a hard drive with a SSD). Equally important, bigger databases are almost always more useful than smaller ones. "All the photos I ever took" is really an order of magnitude more useful than fifty separate databases, one for each year of image capturing ("Show me 'Cats'." "Show me 'Grayscale'." Etc. In short, it is always much easier to create sub-sets than to search across multiple databases.
Therefore, unless you have a pressing reason to break up your database, I wouldn't.
Storage space is cheap today. Buy some 1TB and when you run out of internal space familiarize yourself with Referenced Masters and move your Masters to these external drives (FW800 or faster is recommended).
I have and manage several Aperture Libraries. My rules-of-thumb are:
Kirby,
Good stuff as always. Thanks for taking the time to respond. Most of what you said was in-line with what I was thinking. The reason I posted was because I have certain folders which are starting to accumulate a lot of separate projects. So many in fact, I was thinking that it might just make sense to create separate libraries for them.
I think I'll stick with it the way things are. I do currently run a referenced library, backed up to FW800. I keep the Aperture library itself on my internal. Things run just fine as it is, so no real problems there. It was more a matter of trying to simplify things.
Thanks again,
Mac
The reason I posted was because I have certain folders which are starting to accumulate a lot of separate projects.
Have you tried Folders with sub-Folders? I hadn't really thought about it, but I just looked and I have Folders seven deep in places. (Admittedly, I love outlining.) Two hints which you may already know:
. "{Option}+click" a disclosure triangle to open or close it and all its children
. Make useful top-level Folders, and don't put any item except Folders at the top level.
. . (This is actually a principle of outlining: all levels should contain either body-text or headers, but not both.)
I regularly get "re-centered" by "{Option}+clicking" the disclosure triangle next to "PROJECTS AND ALBUMS" to collapse my whole long Library outline, then clicking it again to show just my top-level Folders.
But I don't break up Folders because they have too many Projects. One database I set up has thousands of Projects in each of dozens of Folders. That's just how the data was best organized.
I do currently run a referenced library, backed up to FW800. I keep the Aperture library itself on my internal. Things run just fine as it is, so no real problems there. It was more a matter of trying to simplify things.
Thanks again,
You'll find the going easier if you can shift to thinking of each image having a Master, and that Master being either Managed (inside the Aperture Library) or Referenced (not inside the Aperture Library). Masters are either Managed or Referenced. A Library can contain both images with Managed Masters and images with Referenced Masters.
Simple is always good. The trick with Aperture is to provide what you need, and nothing else.
Your welcome. :-)
Good Luck.
Kirby,
I've tried all sorts of different organizational schemes - managed, referenced, folders, sub-folders...projects...
I feel pretty comfortable with the one I am using now. I have it set with top level folders that are pretty general - Holidays, Birthday, Outdoors, Travel, Special Occasions, etc... I have found it best to stick with one level of folders, which then contain their appropriate projects. Once something doesn't fit, I just create a new top level folder.
I can't recall why I moved to this, but I think it had something to do with the way projects were displayed in the Projects pane. It just simplifies things. I had tried using lots of sub-folders at one time and it just didn't work for me.
I typically name my folders as described above and then name the projects that are kept inside of them by date_name. So, mountain biking pics taken on June 9, 2011 would go into the folder, Outdoors, and be placed in a project named, 2011-06-09_Biking. This is just an example. I have found it easier to keep track of things when using this convention. I don't typically like to put the year first when naming by date, but it is the only way to keep things purely sequential. For example, 03-11-11 would come before 06-02-10 even though the latter is chronologically earlier.
I have also played around with the naming of my images a lot. I'm really just looking for the most efficient work-flow, but I also want something that is going to provide simplicity in the long run. I usually name my images with image date_custom name_Index. I had been renaming the masters in this fashion too, but have since questions whether I want to continue to do that. I do not like when I have multiple images with the same name - IMG_0024, for example. This happens quite a bit if you use Auto_Reset for the naming convention on your camera. I also felt that if I used continuous naming, that after 9999 on my camera, things would reset back to 0001. I'm torn as to how to continue, and while I know it really doesn't matter that much in terms of being able to know my images in Aperture, I'm kind of anal about this kind of stuff.
One issue I find with doing this is that it negates the "Do not import duplicates" function built in to the import function. This wouldn't matter if I always had a fresh card, but sometimes I don't delete my older images from my card before shooting again.
Any advice on file naming and work-flow would be appreciated. I'd like to hear what you have to say on the subject.
You've already seen my file-naming convention, I think. (DiploStrat's response is spot-on.) Like you, I realized that a sequential numbering scheme would not work long-term. I rely on a combination of shoot information, camera-assigned file name, and date. This gives me unique names (theoretically fallible, but in practice fool-proof), and provides for easy file identification (by me) without having to see an image.
I try to be careful about not loading cards without re-formatting them (and not using them until the images on them are both imported and backed-up). My naming convention negates "Do not import duplicates." It's a trade-off I recommend.
Creating new libraries
