Aperture 3 Faces and Storage
On the whole, I’m very happy with the new features and interface improvements in Aperture 3. Many of the changes have been discussed elsewhere, however I wanted to mention a few points that I haven’t seen covered:
Face Detection
I’ve been putting off keywording people in my photos because I assumed that face detection was on the way. Now that it’s here, I’m not sure how much I’m going to use it.
In one of my projects, the faces were totally messed up. Aperture detected “faces” in solid-color areas near the corners of the photos, completely ignoring the prominent people in the middle of the frame. I manually added some faces, drawing rectangles and naming them, but Aperture forgot this as soon as I clicked on another photo in the browser. The only way I could get faces to work with this project was to delete the versions and re-import the masters. Luckily, these versions did not yet have any keywords or adjustments because they would have been discarded.
In my other projects, at least the dozen or so that I’ve gone through since upgrading, the face detection seems to be working properly, pretty much like in iPhoto.
Face Naming
There was some confusion when multiple people had the same first name, or the same first and last name with different middle initials. Also, the Address Book integration didn’t quite work the way I expected. Now that I see how it works, I think it’s adequate, but I would rather that Aperture not get cute and try to abbreviate to ambiguous first names.
The “Unnamed Faces” strip doesn’t seem to offer a way to zoom out or jump to the original photo. As a result, there are some faces that I can’t identify because I can’t see enough context. I don’t want to click Skip, because then how do I get back that list of untagged faces? But if I don’t click Skip, it seems the strip will be forever filled with those same unnameable faces.
Face Storage
Aperture uses a sensible storage model (which I first saw in Mail and copied for EagleFiler) where an “index” database is used for speed but the data and metadata are stored in flat files and XML. If the database is deleted or damaged (or not backed up), the data and metadata remain intact, and the database can be reconstructed from the other files.
Unfortunately, this does not seem to be true for faces. It looks as though Aperture stores the face information in the Faces.db SQLite database but that it does not save it in the XML files along with the other metadata. (It does export faces as keywords in the JPEG files, but that’s not particularly helpful when reconstructing a library.) This makes me wary of spending lots of time tagging faces and possibly losing that work if there’s ever a problem with my Faces.db.
I’m considering using the face detection to aid in assigning keywords. However, there doesn’t seem to be an easy way to generate and assign keywords from faces (other than exporting) or to assign faces from keywords (if I were reconstructing a library where the face information had been backed up in that way). It’s a shame because, although Aperture has good support for keywords, the faces feature is better suited for tagging people (though, alas, faces don’t show up in the various metadata displays).
Core Data
Aperture 1 and 2 used Core Data, but Aperture 3 seems to have dropped it in favor of using SQLite directly. As a user, this doesn’t particularly matter to me, but as a developer making heavy use of Core Data I wonder about the reasons for the change. It’s curious that Mail, iTunes, iPhoto, and Aperture are highly visible “database” applications, none of which use Core Data. Does Apple think that Core Data is the wrong kind of technology for these applications? Or are there limitations/flaws that make the dog food unpalatable? My hunch is that for what Mail needs to do it’s more efficient to use SQLite directly. However, Aperture seems like exactly the kind of application that Core Data was intended for.
Backups
The folder structure inside the library package has been improved so that Time Machine backups should be much more efficient, especially if you rearrange your projects and folders. The thumbnails are now excluded from Time Machine backups, as is the BigBlobs.apdb. Other large database files are included, however: Faces.db, History.apdb, ImageProxies.apdb, Library.apdb, and Properties.apdb. My guess is that, except for Faces.db, these could all be reconstructed, so I’m excluding them from my CrashPlan backups.
Performance
Even after face detection completed (and I rebooted), Aperture 3 seems slower and more RAM-hungry than ever. I’m using a 2009 MacBook Pro, maxed out with 4 GB of RAM, and my library has about 34,000 versions. Aperture 2 was sluggish at times but bearable. Aperture 3 often locks up itself—and the rest of my Mac—for seconds or minutes. I’m going to see whether DiskWarrior helps.
25 Comments RSS · Twitter
"Aperture 3 often locks up itself—and the rest of my Mac—for seconds or minutes. I’m going to see whether DiskWarrior helps."
Given that this occurs in close to 100% of Aperture 3 reviews, I'd say your file system is likely not the culprit here...
Chucky: I don’t suspect file system damage. However, upgrading even a relatively small library like mine involves creating and deleting hundreds of thousands of files and folders, so I think rebuilding the directory may help. I imagine there are also other problems, in Aperture itself, though.
To get at the skipped faces you can use a smart album. I'm not on my Mac so I can't tell you the exact rule but it should be fairly obvious.
In the case of Mail, I think the main reason Apple didn't use Core Data was because of Spotlight. Spotlight only returns individual files as search results, so Apple had to make Mail store its messages one per file starting in Tiger in order to have Spotlight work well with it.
iTunes is a cross platform Carbon application, so it doesn't surprise me at all that it doesn't use Core Data.
iPhoto is the most curious of the bunch, with the latest version also using plain SQLite rather than Core Data. The best I can surmise on that one is that Apple decided that rewriting the entire object model of iPhoto into NSManagedObject classes was too much to bite off, and I'm sure there's plenty of legacy cruft built up over 6+ versions of iPhoto to make that plenty hard. So instead, they kept their object model the same and just rewrote the persistence code to use SQLite.
Brian: The per-message files for Spotlight have nothing to do with which technology Mail uses for its index database.
Funny. The workaround to the delays in Aperture 3.0 seems to be to launch the app in 32-bit mode.
I wonder if desktop OS X is viewed as a "hobby" in Cupertino at this particular moment in time...
This is all a reminder that Apple's frameworks are here to get you up and running in no time, but they are general-purpose frameworks and they can only go so far. Depending on your application, it is sometimes better to write your own version. If you write a document-based image editing application, you might still use CoreData, but you will probably have to go beyond the built-in facilities in CoreImage and NSImage. If you write a photo management application, you will probably need to go beyond CoreData, but won't need to rewrite any of the image handling stuff provided by Apple.
What's nice about CoreData is that it brought SQLite on OS X. It also gave some interesting ideas about the APIs that a persistency framework would need to provide: a lot of the alternatives out there are still inspired by these APIs, and that's a great thing.
Chucky: Interestingly, the 32-bit option in the Get Info window wasn’t available for me until after I rebooted in Safe Mode.
To follow-up: Running in 32-bit mode doesn’t seem to help. At this point, I wish I hadn’t upgraded to Aperture 3. It’s so slow that I don’t even want to import the photos from my camera.
does the face recognition ever end? It has completely locked up Aperture, my mac has dozens of errors and freezes. I've had to force quit just to type this comment. really am concerned that my mac just became a paper weight. went to apple store and was told to upgrade to latest operating system, did not help
Cliff: Yes, actually the face recognition wasn’t a problem for me at all. However, the bad news is that Aperture freezes the Mac even after the recognition has finished (or if it’s turned off).
I also had big performance issues with Aperture 3 (on a 2009 Macbook Pro), probably connected to the face recognition but they seem to vanish after the 3.01 update.
Matthias: Glad to hear that. For me, defragmenting helped a little, and the update may have made some things a little faster, but it still freezes a lot where 2.0 didn’t.
I know you'll hate this but Aperture 3 is much quicker than 2. Simple things like renaming or moving a project would cause 2 to beach ball for minutes. Those problems are now gone.
My library is 140Gig ~30k photos.
Snow Leopard on a 27inch iMac
I also find Aperture 3 to be more responsive than 2. Currently my main gripe is that after I've gone to all the trouble of naming so many faces, it's quit trying to suggest them entirely. It still detects them but I am forced to type each name in..
[...] reading this post regarding aperture’s database, I’m even less confident in the program as a whole. I wonder if I’m just wasting my [...]
So is there no way of storing the Face and Places metadata inside the Jpegs if i export them from aperture??
[...] Aperture does not store the faces information as securely as the other metadata. Also, there’s no way to organize faces. I continue to use keywords [...]
To follow-up with Matts comment about skipped faces:
1) File->New->Smart Album (Shift-Control-L)
2) Add Rule Face
3) Checkbox in the Face field with the drop-down "is unnamed" selected
I find if you just turn off Faces, that Aperture 3 is a lot faster and more responsive. I just use keywords manually.
@Matt That may be true if you have enough RAM and a fast enough disk. On a 4 GB MacBook Pro it was a lot slower for me, even with Faces off.
