Aperture Library/Database hacks

Question

After one week playing around with aperture, i want to share my current insights with 'customizing' (my) aperture's way of dealing with my picture files.
Warning:
The following thoughts and arrangements are working for me, they're
undoubtly NOT supported by apple and the programmers of the aperture
application!
Reading a lot of articles in the forum when aperture hit the masses, i've been disappointed about how aperture will fit with me.
Over the years my growing picture collection moved over from one computer to the other, deploying more storage, and will continue to do so in the future. So the technical equipment has to be independent from the treasure's of my data, to follow state of the art hard- and software development.
For me, aperture approved to be of such a kind.
Despite aperture stores away all my digital masters into it's own Library, thus duplicating data during imports, it just brings in some kind of more detailed
directory hierarchies to my way of organizing my picture library. How does it do?
How do i store my Library?
Sorry to be that longish, but to explain my concepts i have to.
Modern operating systems distinguish private/personal and public/common data for their file storage locations. Hopefully they follow the 'FHS' (Filesystem-Hierarchical-Standard) brought up by linux, to name the diverse locations for classified data.
I do run mixed os'es within my networks, as no computer should be isolated from a networked environment anymore. But to be honest it's more a single-user situation in reality, then the multi-user aspects i always keep in mind when designing my infrastructure environment for a network.
My picture library/online-archive is classified 'common' data, so it stores outside my home-directory, and every user allowed to, has access to it. I do not support locales within my filenaming-conventions, users and me are german-spoken, so the 'common' data for my systems is always called
'/Bibliothek'.
Furthermore we're dealing with pictures (Bild), movies (Film), music (Musik) and documents (Dokumente) in all common used operting systems (os x, windows), storing private data to the home-directory within appropiate directories and public/common data to the equivalent directories at a common storage.
/Bibliothek
/Bibliothek/Bildarchiv
/Bibliothek/Filmarchiv
/Bibliothek/Musikarchiv
BTW, i customized windows to reflect this filetree within explorer windows, so users click to 'Eigene Bilder' (my pictures) and 'Bildarchiv' (common pictures) there, to change between directories, making it very convenient to work with.
Especially the 'common' picture files are strongly organized by date, which is reflected at the directory-structure, for example:
'/Bibliothek/Bildarchiv/2004/2004-04-17, make a good description/'
'/Bibliothek/Bildarchiv/2005/2005-12-00, a bunch for the whole period/'
A descriptive directory name is highly portable between operating systems, applications and last but not least, users!
For now, aperture seems to be pretty much a single-user solution.
But it's library can be 'distributed' to accomodate my needs.
I started to import my data by drag'n'drop, which works best for me. I didn't like the import assistent, which seemed to result in a different structure of my data in aperture's 'all projects' list. By creating a folder in aperture for the year, then drag'n'drop the multi-selected directories from the finder, i got within aperture:
All Projects + * (<-Aperture)
<div class="jive-quote">Library (smart-albums, collapsed)
2005 (folder)
2005-11-00 (folder, nested)
2005-11-17, sample bla (project, from directory)
Images from 2005-11-17, sample bla (album, inherited)
2005-12-08, take a better name (project)
Images from 2005-12-08, take a better name
Using aperture's preferences to switch between libraries i did import to different aperture libraries for the years, resulting in a bunch of directories, each holding an 'Aperture Library.aplibrary' paket there.
/Bibliothek/Bildarchiv/2004/2004.aplibrary
/Bibliothek/Bildarchiv/2005/2005.aplibrary
Yes, the pakets can be renamed, to better reflect whats in there. Aperture has to be restarted to change from one library to another!
The total amount of imported data, yet: 130 GB, ~33164 pics.
I am working with a 15" powerbook, 1,5gb ram, 80 gb hdd on the road and a 200gb external drive at home/office.
to make me feel comfortable with aperture, i switched to (terminal hacking!):
~me/Pictures/Aperture Library.aplibrary/
~me/Pictures/Aperture Library.aplibrary/2004/ ->
/Bibliothek/Bildarchiv/2004/2004.aplibrary
~me/Pictures/Aperture Library.aplibrary/2005/ ->
/Bibliothek/Bildarchiv/2005/2005.aplibrary
~me/Pictures/Aperture Library.aplibrary/Texturen/ ->
/Bibliothek/Bildarchiv/Texturen/Texturen.aplibrary
~me/Pictures/Aperture Library.aplibrary/...
/Bibliothek/Bildarchiv/2004/2004.aplibrary
/Bibliothek/Bildarchiv/2005/2005.aplibrary
/Bibliothek/Bildarchiv/Texturen/Texturen.aplibrary ->
/Volumes/HD39.1/Bibliothek/Bildarchiv/Texturen/Texturen Library.aplibrary
Linking folders to where i believe they are right placed in my systems.
Now aperture's settings don't have to be changed each time to switch between libraries. Not connecting the external hdd gives me grayedout
folders within aperture, for data stored on the external drive. Having a folder located on my inetrnal hdd and 'linked' to aperture:
~me/Pictures/Aperture Library.aplibrary/local ->
/Bibliothek/Bildarchiv/working.local.aplibrary
i can work with aperture normally, even if the external drive is not available.
the grayedout folders/subfolders/projects are browsable, but all thumbnails are just gray rectangles with its 'version name' underneath. same with smart-albums. available pics have colored thumbnails, unavailable pics are gray, naturally.
And aperture's database? well, i am very happy with it, really. Compared to my pre-aperture structure all the above mentioned tweaking gave me:
~me/Pictures/Aperture Library.aplibrary/Aperture.aplib/Library.apdb
This file is actually the sqlite3 database file. it's size is 111 MB now.
~me/Pictures/Aperture Library.aplibrary/Local ->
/Bibliothek/Bildarchiv/Working.local.aplibrary
I can store pictures there into folders and projects when i am on the road, filling up my local harddisk. Inspecting the paket shows up how aperture differenciated my pre-aperture filestructure:
/Bibliothek/Bildarchiv/Working.local.aplibrary/2005-12-08, take a better name.approject/2005-12-08 @ 01/49/06 PM - 1.apimportgroup/DSC0168/dsc0168.nef
All nicely packed into a single unit from the finder, easily browsable from aperture, and searchable by sql queries. Every Master enclosed in its own folder box, hm. Every import of files seperated to one folder, which makes clearly apparent that we will import redundant(duplicate) files for ever.
Adding two/three levels to my previous filestructure, strange namings all inclusive. As i sort my files with aperture into projects, the files accordingly move around at the filesystem-level. I'll let them go. They are there if i need access to them in case of failure.
T H E G L I T C H E S
within my setup the most current sql database is stored at:
~me/Pictures/Aperture Library.aplibrary/Aperture.aplib/Library.apdb
importing the way i did results in a sqlite3-database file for each library i switched to before linking them together. Right after linking one of those aplibrary pakets as a new folder, aperture will rebuild the current database at startup, which can indepently be invoked with 'option command aperture' anytime the program is started.
Changes to the metadata of a picture are written to the current database aperture is running on, but can be transfered to any other database file
when rebuilding the library at startup (which can be a time-consuming thing!)
Even if the external hd is reconnected before startup, some thumbnails are not properly generated all the time. At the current state i don't have any glue what's the cause for this. All Versions are properly accessable anyway.
Once again,
DO THIS AT YOUR OWN RISK,
if you try some of the suggestions i've made. Better you know how to handle a terminal before you even think about what i told here. Don't bother me, if something does not work for you - it works for me.
I can do this because it's my data, i am the only one affected by failure and i still do have my data on my windows system as a backup, for now.
Do the same before you trash your treasures.
Why i did made this post? Aperture really lacks support for team-working now. I cannot see how aperture can be really employed to its potential for an environment with more than a single user?. The sqlite3 database is said to handle concurrent users, i read on its homepage. So i still hope, there will be a group-worked aperture someday.

Answer 1

my reports, just for the logs.
drwxr-xr-x 2 fo03c fo03c 68 Dec 19 20:15 ArchiveInfo
-rw-r--r-- 1 fo03c fo03c 362 Dec 19 20:17 DataModelVersion.plist
-rw-r--r-- 1 fo03c fo03c 173107200 Dec 20 00:26 Library.apdb
comparing the timestamps, the time needed to recreate 'my' library, is:
4h 11 min.
The sql database contains 972 projects with 57952 picture items, as the startup overlay tells me. not that bad, i think. depends on the situation, and how much zen you learned, if you can wait for the 'recreate'.
but i didn't stop to mature aperture!
i switched to one of my 'old' libraries (choosing from preferences panel) and set some new
a) ratings
b) keywords
c) deleted a master from that 'old' library.
after changing back to the 'linked' aperture database file (within my home-directory, as described previously), and restart aperture -
yes, it crashed! oops.
yet another try - crash. i realized, i deleted the first pic from the 'current view' aperture tries to load after relaunch. ?! =:-(
if the database is corrupted again, i would have to reinvest ~4 hours to recreate the database? but how about the preferences?
apple this is a bug! when i made the preferences file
~me/Library/Preferences/com.apple.Aperture.plist
UNAVAILABLE (delete or rename as you like), aperture starts with the import assistent, as at its first time.
Since then i can start aperture and navigate to the project i deleted the file from (very unpolitly). The corresponding thumbnail shows up with a new 'icon' to lower right corner of the thumbnail. It clearly means: this file is UNAVAILABLE.
YES =:-) i deleted it!
the rating and keywording on the 'old' database is gone -
thus making the precedence of the database against the sidecars obvious, doensn't it?
selecting the 'orphaned' thumbnail, now leaves aperture with the message 'loading', but it does not crash. Changes in ratings or keywording to the current library (the 'recreated' new one) on different files are persitent across restarts of aperture. btw, aperture restarts with the focus on the orphaned first thumbnail, now marked with the icon 'i am NOT available', but it does not crash anymore, when starting.
my conclusion:
someone in the forums pointed towards the difficulties maintaining a database of pictures and the separation of their storage, as users will delete or move files seperated from that database, breaking everything.
NO, aperture does widely tolerate such doing.
But why should we do so? =:-)f
For me: its fun, i will not complain about failure, when i do mature an application like this.