I finally found some time to work on bringing Aperture 2.0 compatibility to Annoture. You can download the latest pre-release here.

I recognize that this blog has become very technical lately. Forgive me, ever since I was a kid in San Diego playing Ultima I through V on the home Apple ][ computer, I’ve always wanted to talk computer stuff!

Today, I tested the performance of the MacBook Pro hooked up to my Apple 30-inch Cinema Display. One reason why I chose the Pro over the regular MacBook or the Air was that it could drive a 30-inch display (2560×1600 resolution). The laptop features a Nvidia GeForce 8600M GT with 256MB of RAM; the newer Penryn-powered MacBook Pros have the same video chipset except with 512MB of video RAM. As you would expect, more video RAM typically equals better performance, especially with applications that make use of Mac OS X’s Core Image.

As I’ve known for two-years and counting, Aperture is one of the most GPU-intensive apps I’ve come across. My Quad G5′s beefy 7800GTX 512MB video card — an after-market upgrade that I purchased following my supreme disappointment with the stock 6600 card — has greatly increased the speed of Aperture’s editing adjustments. There’s only a slight delay when changing white balance, exposure, vibrancy and contrast during full-screen edits. Certain adjustments like levels and especially highlights and shadows are a little jerky, but the speed is acceptable.

With Aperture maximized or in full-screen mode, the MacBook Pro starts to struggle when only a few adjustments (WB and Exposure) have been turned on. Don’t even think about using highlights and shadows at fullscreen! Reducing Aperture to its minimum window size results in excellent performance with every default adjustment turned on (WP, Exposure, Enhance, Levels, Highlights and Shadows, and Color).

At fullscreen on a 30-inch display, four megapixel images are being displayed and manipulated in real-time by Core Image! A 24-inch Cinema Display would force the GPU to deal with a 2.25 megapixel image. At its minimum window size, Aperture only has to deal with images that are roughly 825×550, less than half a megapixel.

Having a big view of the image is great; that’s why I bought the 30-inch display in the first place. Performance is also very important, so you can be sure that the window size is getting reduced when I’m editing images on the MacBook Pro.

A great source for Aperture speed tips can be found on Steve Weller’s Bagelturf website. The list was originally compiled for Aperture 1.5, but most of them are still valid with Aperture 2.1.

I’ve been using Aperture since version 1.0. When the application was released in 2005, all images had to reside within the Aperture Library. This did not prevent me from using the product, but it was deal-breaker in terms of switching to Aperture completely from iView Media Pro. Version 1.5 was released a year later, and it allowed users to store the master images by reference. This was great for me, since I could now import all of my images by reference and keep the annotations synced with iView using Annoture.

When Aperture 2.0 was released a few months ago, I decided to make a permanent switch to using Aperture as my primary photo organization tool. For

Projects can now contain 100,000 images, which is great since I was running into the 10,000 image limit in 1.5.6. Image editing plug-in support in version 2.1 means Noise Ninja from Picture Code is coming soon to Aperture.

My goal is to have my entire image collection — work and personal — contained in a single Aperture Library. I know other people who use multiple libraries, but I wanted a single one so I can easily share photos via iLife and sync to my iPhone.

This post is my odyssey to Aperture’s Promise Land. Does it exist? If so, will I get there? Read on to find out the issues I have to overcome along the way!

Storage

Up until a year ago, I was storing all of my RAW photos on a 1TB RAID 5 (650GB available) Infrant ReadyNAS. Before I purchased the Infrant in 2005, I had run out of space on my primary photo volume, a 250GB FireWire drive, and was using a spare 80GB external disk to store my recent images. Last year, I ran out of space on the Infrant, and the overflow images were being stored on a 750GB hard drive. As I wrote in 2005, and as I write today:

This was not a good solution because (1) the data wasn’t being backed up and (2) I didn’t like the idea of my photos residing on multiple hard drives, and (3) I’ve already had one hard drive crash in the last year. Since my data is priceless, I was eager to find a better solution.

First, I copied all of my RAW images from the Infrant to a new 750GB hard drive. I made the mistake, however, of naming the hard drive Photos instead of photos, which was the Infrant’s volume name. This caused Aperture to lose track of all referenced files. I could have simply changed the name of the hard drive to photos, but the anal-retentive in me decided to reconnect all referenced images to the new Photos drive. I’ll be the first to say that reconnecting over 100,000 photos can take a long time.

Double Masters

Next, because I have been using Aperture since version 1.0, I had a number of projects with managed photos. This meant the Aperture Library contained the RAW files. Remember, however, I also had these same images imported by reference in the Aperture Library. As a result, I had duplicate photos:

• Managed Photos (A) with adjustments, ratings, and metadata
• Reference Photos (B) with no adjustments, ratings, nor metadata

Obviously I had painstakingly added adjustments, ratings, and metadata to all of the managed files, and I didn’t want to lose them. After consulting with Steve Weller, I did the following:

1. Exported the managed projects (A). I chose to consolidate the masters photos in the exported projects. I did this to create a backup in case I screwed up anything.
2. Relocated the masters photos in the managed projects (A).
3. Moved the relocated master photos to the trash. This caused Aperture to lose the reference to the master files.
4. Located and deleted the exact same master versions in my referenced projects (B). Obviously, I did not check move referenced files to the trash.
5. Reconnected the dereferenced photos from (A) to the files referenced by (B)

If that sounds complicated, it’s because it was! The end result, however, is that I have one master version pointing to one file, not two master versions pointing to the same file — or worse, two identical files.

Now my Aperture Library has over 120,000 referenced images and 177 managed files. Fortunately, most of those managed files exist in one project, which is much more manageable than thousands of managed files spread across twenty projects! My Aperture Library is still large at 74GB, but it’s not the 105GB behemoth that it once was.

Backups and Vaults

Up until now, I haven’t used Aperture Vaults to back up the library. I first tried copying the library to another hard drive, but 50GB into the copy, Finder popped up with an error saying it had encountered a problem writing one of the files in the Library. Ugh!

As I’m writing this post, Aperture is creating a brand-new vault on a separate external hard drive. It’s a tad over 50% done, and I really hope that there isn’t a problem with the remaining 40%. It would be a real bummer if I can’t back up my Library! Sadly, I’ve read of several problems getting Vaults to update properly.

If all goes well, in the morning, I plan to restore my library from the vault. Then, I will again attempt to copy the library to an external hard drive. My ideal backup scenario is twofold: automated backups via SuperDuper!, Carbon Copy Cloner, or RsyncX and periodic Aperture Vault updates.

Update: The Vault update failed, but at least there was a descriptive error message:

Looks like a corrupted thumbnail to me. I wasn’t able to delete the file using the Finder (it crashed), but was able to remove the file through Terminal. After doing that, the Vault update completely successfully, and the Vault refresh icon changed from red to black. Now, I will try copying the Aperture Library to the hard drive with the Finder.

Update #2: The Finder copy completed successfully.

Interesting, there’s a free AppleScript-based app from Apple called Aperture Caption Palette. This slick mini-app looks suspiciously like my own Aperture Caption AppleScript that I wrote in the beginning of February.

If only I knew what things are in development at Apple, it would save me a lot of time writing duplicate products!

A month after they released Aperture 2.0, Apple’s got a major updated out with Aperture 2.1. The most exciting thing is the new plug-in architecture. I can’t wait until PictureCode gets a Noise Ninja plug-in out! Update EXIF from Master is a great tool for those who manage their photos by reference too and occasionally update their images with additional information (i.e. GPS data).

Update: It looks like the image edit plug-in architecture creates full-resolution TIFF/PSD versions and files, which is a fast way to bloat up your image library. I hope that Apple has a way to add plug-in non-destructive adjustments filters. This would be essential for something like Noise Ninja, which I would want to batch across every image in a project without having to create mega-sized TIFFs for each file.

More in-depth discussion about the plug-in architecture can be found on Rob Galbraith’s site.

During the three weeks we were in China, the computers in our home office were turned off. Our electricity bill for the month was $24 cheaper than the previous one. In fact, our electricity usage has been steadily going down after we switched to compact fluorescent lights (CFL) and became smarter about turning off unused appliances.

I suspect much of the power savings came from the fact that my PowerMac Quad G5 was getting a well-needed rest. I’ve been using this machine, along with an Apple 30-inch Cinema Display, for over two years. The MacBook Pro isn’t as fast as the Quad G5, so it’s not about to replace the PowerMac when I have photos to process or our film to edit. For mundane tasks like email and web browsing, however, it’s perfect and much more portable. In addition, the MBP has distinct advantage over the Quad G5 in the energy usage department.

I used a Kill-A-Watt power meter to measure the power usage of the Quad (with the 30-inch display) and MacBook Pro performing various tasks.

Note that my PowerMac Quad G5 has 6GB of RAM, two 750GB internal SATA drives, an Nvidia 7800GTX video card with 512MB of RAM, and a TeraCard PCI-E SATA card. An iSight camera is also connected to the PowerMac via FireWire. The MacBook Pro has 4GB of RAM and a stock 160GB hard drive.

The Quad G5 is certainly powerful and power hungry! It certainly doesn’t help that I have even more peripherals attached to the Quad than I was measuring in my tests. In addition to the 30-inch Cinema Display, I have a FireWire iSight camera, a 17-inch Studio Display as a secondary monitor, and a WiebeTech RTX-400 4-bay external SATA box (it’s usually off unless I’m processing photos or editing video). Fortunately, everything is hooked up to a solid APC UPS, so I’m good (for a few minutes) in the event of a power outage.

Even if I plugged the 30-inch display into the MacBook Pro, the laptop would still be more energy efficient than the Quad alone. I read that the new Mac Pros are pretty good compared to the Quad G5, which appears to be the most energy inefficient Macintoshes ever produced.

We’ll never get to the electricity usage levels of Felix in Colorado. Our goal is to get our utilities costs under $100. Having a pool makes it difficult, as it uses tons of water and electricity. With a switch in the way we use our computers, however, I think we can achieve the goal!

The MacBook Pro (MBP) is my first Intel Macintosh. For the past couple of years, I’ve been using a Quad G5 as my primary machine and a first-generation PowerBook G4 12-inch for travel. Before I purchased the Quad G5 in 2005, my desktop was a Quicksilver PowerMac G4, purchased in 2001. Though the PowerMac G4 ran at the same speed (867MHz) as the PowerBook (purchased in 2003), it was faster overall due to a better graphics card, more RAM, and a faster hard disk.

It’s been two years, and here I am with a new MacBook Pro. Unfortunately, it’s not the new Penryn-powered MBP; I was on a plane to Hong Kong just days before the new ones were released. Once there, there was no way to take advantage of Apple’s 14-day return policy.

With a little time on my hand, I wanted to see if the MacBook Pro’s performance was up to par with the last of the great PowerPC Macintoshes. In addition, I’ve been curious for some time about about Aperture’s performance on Intel and Motorola PowerPC chips.

I conducted three tests using Aperture 2.0.1 and a sample library containing twenty RAW photos from an 8 megapixel Canon EOS 1D Mark II. Ten of the images had no adjustments, keywords, or metadata applied to them. The other ten images had keywords and metadata, in addition to white balance, exposure, enhance, and edge sharpening adjustments.

My Quad G5 features 6GB RAM, an Nvdia GeForce 7800GTX with 512MB of RAM, and a 750GB Seagate internal SATA hard drive. The MacBook Pro has 4GB RAM, an Nvdia GeForce 8600M GT with 256MB of RAM and a 160GB Hitachi internal SATA hard drive.

All tests were performed four times, and the results are averaged in the tables below:

Test 1: Export Ten Non-Adjusted Images to 16-bit TIFF

For the first test, I selected the ten images that had no adjustments and exported them to 16-bit TIFF files. Normally, this isn’t something I would do, but I wanted to see how fast Aperture could export without doing much processing.

Not bad. The MacBook Pro more than held up against the mighty Quad-core PowerMac in this test with the Quad coming in at 12% faster over the MBP. Since I don’t often export the files without performing any adjustments, I am more interested in the results from the next test.

Test 2: Export Ten Adjusted Images to 16-bit TIFF

Each image had its white balance, exposure, enhance, and edge sharpening adjusted. This is a better test, because the computer’s CPU has to perform additional calculations before exporting the image. If I had another video card for the Quad G5, I could see whether or not the GPU made a difference. In my Quad, I am using a reflashed Nvidia 7800GTX with 512MB of RAM. The original stock 6600GT card was such a dog that it’s no longer in my possession.

The Quad G5 is 22% faster than the MacBook Pro. When exporting hundreds or even thousands of photos, every percentage point counts. For a typical wedding shoot, I might be exporting 1000 images. The Quad G5 would take two and a half hours, whereas the MBP would take an additional forty five minutes.

Test 3: Export 1024 x 1024 JPEG

Exporting a web-sized or preview sized JPEG is a common task for me. Here I exported the ten adjusted images to fit within a 1024 x 1024 pixel box.

I was a little surprised by this score. While the Quad was faster at exporting an 8-bit JPEG over a 16-bit TIFF file, the MacBook Pro was slower. Exporting 1000 images, the Quad would take 2:26:00 while the MBP would take nearly an hour longer at 3:24:00. I wonder if the Quad was created the JPEG from its pre-generated preview image.

So, after two and a half years, the Quad G5 can still hold its own against a MacBook Pro. The gap might be a tiny bit closer, however, with the new Penryn-powered MacBook Pros. I’m curious to see how much faster the Dual 3.2GHz Quad-Core “Harpertown” MacPro is compared to the Quad. The MacPro would have to be twice as fast as the Quad before I would even consider upgrading. When I went from the Quicksilver to the Quad G5, I saw a 600% speed increase in RAW processing performance. Yes, the Quicksilver took about a minute to process one RAW file!

Another test I’ve been conducting is power per watt. With a Kill-A-Watt power meter, the MacBook Pro is well ahead of the Quad G5, which is one power-hungry computing beast!

In my brief testing, Annoture and Timeature are not compatible with Aperture 2.0.

For Timeature users, there is a new feature in Aperture 2.0 which allows you to adjust the timestamp of an imported image. Look for the Adjust Date and Time… menu item under the Metadata menu.

There is currently no timetable for updating Annoture to support Aperture 2.0.

Speak of the devil! Just days after I write Aperture Caption to help users of Aperture 1.5.2 to quickly caption images, Apple announces Aperture 2.0. One of the 100 new features is Metadata entry shortcut, described below:

Metadata entry shortcut

When adding or modifying metadata entries, press Command-Right Arrow (or Command-Left Arrow) to advance to the next (or previous) image. The cursor remains in the same metadata field, expediting the process of making metadata edits as you move from image to image.

I just tested Aperture Caption and it still works in the Aperture 2.0 Trial. In fact, because the script automatically moves you to the next image, it’s actually a little faster than hitting Command-Right Arrow in Aperture 2.0. Either way, Aperture users, you have a choice!

In addition, Aperture 2.0 has the ability to adjust a photo’s date and timestamp after import. My program, Timeature provided this ability, but it did not modify the master image, just the records in the Aperture database.

Adjust time/date offset

Adjust the timestamp assigned to each photo by your camera at the time of exposure and embed the changes in the original master image files.

I’ll have to check if there have been any changes to the AppleScript support for my other application, Annoture, which provided metadata copying capabilities between Aperture and iView Media Pro.

Apple also lowered the price of Aperture to $199, but they are charging existing owners $99 to upgrade.

Update 2008-03-28: In conjunction with Aperture 2.1, Apple has released a free AppleScript-based app for captioning called Aperture Caption Palette. Check it out.

I’ve been using Aperture as my primary RAW processor for quite some time now. One thing that has been bothering me and others is the lack of a keyboard shortcut to edit the captions of successive photos. This is one reason why I’m still using iView Media Pro to handle annotating my images — it’s much faster to annotate photos using the keyboard in iView.

Since we all can’t wait for Aperture 2.0 to fix all of our problems with the app, I finally found an hour this evening to come up with a quick captioning solution. Aperture Caption is a free AppleScript that makes it really easy to caption your images one after another. You don’t even have to touch the mouse!

Aperture Caption is a free AppleScript that makes it easy to caption and keyword images in Aperture using just the keyboard.

1. Download Aperture Caption
2. Decompress the archive and install it in the following location:

   ~/Library/Scripts/Aperture Scripts/

3. Make sure that you have the Scripts menu activated by running the AppleScript Utility application in the /Applications/AppleScript folder.

   

4. Launch Aperture and select an image you wish to caption
5. Choose Aperture Caption from the Script > Aperture Scripts menu.

   

6. Aperture Caption display the following dialog box on launch:

   

7. Click Captions Only to only add captions to your images. Click Captions & Keywords if you want to add both captions and keywords to your images.

   

8. After entering your caption, click OK or press Return. If you launched Aperture Caption using the Captions & Keywords, another dialog prompt will appear allowing you to enter keywords for the current photo.



9. Aperture Caption will then caption and keyword your image, replacing any existing caption or keywords in the image.
10. Aperture Caption will now go to the next image until you hit Cancel.

    

Tips

If you want to add a keyboard shortcut for Aperture Caption, download FastScripts Lite from Red Sweater Software. The standard Scripts Menu in Mac OS X does not let you assign a keyboard shortcut using the Keyboards and Mouse System Preference.

A bug was discovered in Annoture’s Aperture to iView annotation process yesterday. I’ve released a quick update to Annoture which resolves this issue. All users of 1.0.2 will be notified of the update the next time they launch the application.

Happy New Year everyone!

Annoture 1.0.2 has been released. This is a recommended update for all Annoture users. It has numerous bug fixes in the file comparison routines over the previous version of Annoture. In addition, the application will now notify users when a newer update is available. Users also have the option to compare the capture dates of files being compared between iView and Aperture. This is useful if you have multiple files with the same filename.

You can download the latest version from the Annoture web page.

Under the hood, Aperture stores information on an image in two places. The first is in a SQLite3 database, and the second is in an assortment of plist files. One would venture that this approach is used for data redundancy purposes and that the data is copied between the two methods on a frequent basis. If you choose to rebuild your Aperture Library by holding the option-key on startup, Aperture will recreate the SQLite3 database using the information stored in the plist files.

When discussing Aperture’s speed, people have rightfully focused on the computer’s processing power, the video card, or the speed of the hard drive. We should also take a look at Apple’s decision to use SQLite. From the SQLite website:

We are aware of no other embedded SQL database engine that supports as much concurrency as SQLite. SQLite allows multiple processes to have the database file open at once, and for multiple processes to read the database at once. When any process wants to write, it must lock the entire database file for the duration of its update. But that normally only takes a few milliseconds. Other processes just wait on the writer to finish then continue about their business. Other embedded SQL database engines typically only allow a single process to connect to the database at once.

I’m no SQLite expert by any means, but I wonder if this is the cause for Aperture’s close friendship with the the SBBOD (Spinning Beach Ball of Death). I was at Eric’s house yesterday and we were trying to use Aperture to export an image for a magazine. Eric was importing images into his system while making simple adjustments and annotations to the image and we must have experienced the SBBOD half a dozen times for over 30 seconds each time! It got so annoying that Eric fired up Capture One on his PC, editing the file, developed it, sharpened the file in Photoshop, and annotated in BreezeBrowser in the time of one SBBOD session.

I’m working on Timeature right now and have successfully duplicate the “database locked” problem that some of my users are experiencing. The way I have coded up Timeature is that it will keep trying to write to the database after a short delay for ten attempts. Whenever this happens, I quickly jump back to Aperture to see if I can perform any editing operation. Invariably, I get the SBBOD. When is disappears, however, Timeature is able to complete its changes. I have no idea what Aperture is writing to the database, but it must be a lot of information, as evidence by the amount of SBBOD we are all seeing.

This leads me to believe that one of the biggest bottlenecks in Aperture is its use of SQLite3 as a backend database. I’m not sure what Apple will be doing to remedy this issue. Perhaps the use of plist files is a preliminary step in the right direction. By tuning when the application writes and refers to the plist file instead of the database, perhaps we can see some immediate speed improvements. Long-term, perhaps the solution is to find a database engine that supports concurrent writes?

I’ve uploaded the results from running sample() on Aperture while the database is locked. Perhaps this can shed some more light on the slowdowns. Some interesting portions from the sample reading include how long the process was waiting for each action to complete (aggregate time):

Sort by top of stack, same collapsed (when >= 5):
semaphore_wait_signal_trap 51445
mach_wait_until 3041
wait4 3001
mach_msg_trap 1999
read 796
semaphore_timedwait_signal_trap 617
sqlite3AuthContextPop 386
lseek 315
sqlite3VdbeExec 128
sqlite3BtreeMoveto 127
sqlite3BtreePrevious 91
sqlite3VdbeSerialGet 81
sqlite3BtreeKeySize 70
sqlite3GetVarint 60
sqlite3pager_unref 55
sqlite3VdbeRecordCompare 53
sqlite3OsCurrentTime 47
__memcpy 44
sqlite3GetVarint32 41
sqlite3pager_pagecount 39
sqlite3MemCompare 38
sqlite3pager_get 38
sqlite3BtreeData 37
gldGetString 34
sqlite3VdbeSerialTypeLen 30
sqlite3VdbeMemRelease 28
szone_size 20
sqlite3BtreeCloseCursor 19
__spin_lock 15
sqlite3pager_pagenumber 14
szone_free 14
dyld_stub_memcpy 13
sqlite3VdbeCursorMoveto 12
szone_malloc 12
sqlite3RunVacuum 10
sqlite3VdbeMemShallowCopy 10
objc_msgSend_rtp 9
sqlite3BtreeDataFetch 9
malloc 8
sqlite3VdbeMemFromBtree 7
sqlite3pager_lookup 7
free 6
memmove 6
fcntl 5
objc_msgSend 5
sqlite3BtreeDataSize 5
sqlite3OsRead 5
sqlite3VdbeMemMakeWriteable 5

Also how many times a particular call was made:

Total number in stack (recursive counted multiple, when >=5):
82 gldGetString
73 sqlite3AuthContextPop
54 CFArrayApplyFunction
47 semaphore_wait_signal_trap
45 NSProApplicationLoad
44 pthread_cond_wait
34 -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:]
31 mach_msg
31 mach_msg_trap
28 -[NSRecursiveLock lock]
28 -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:]
28 -[NSView visibleRect]
28 _decodeObjectBinary
27 -[NSManagedObjectContext(_NSInternalAdditions) lockObjectStore]
25 sqlite3pager_unref
21 _recursiveDisplayInRect2
20 _CFRelease
20 _pthread_body
19 _decodeObject
17 forwardMethod
17 sqlite3BtreeKeySize
16 -[NSView _drawRect:clip:]
16 forkThreadForFunction
14 __memcpy
13 -[NSConditionLock lockWhenCondition:]
13 __CFBinaryPlistCreateObject
13 sqlite3pager_get
12 -[NSView _windowChangedKeyState]
12 __spin_lock
11 -[NSView _propagateDirtyRectsToOpaqueAncestors]
11 -[NSView hitTest:]
11 ripc_Render
11 sqlite3BtreeData

Lots of waiting and obviously lots of SQLite calls. Any thoughts?

Update 11/9/2006: Found some more interesting information on Apple’s Developer Website on CoreDate and SQLite. My emphasis in bold:

Saving to a SQLite Store

When writing data, SQLite ensures that the bytes are actually written through to the drive platter. Since fsync does not make the guarantee this on Mac OS X, SQLite sends a F_FULLFSYNC request to the kernel. This causes the kernel to flush all buffers to the drives and causes the drives to flush their track caches. Without this, there is a significantly large window of time within which data will reside in volatile memory—and in the event of system failure you risk data corruption. The same calls are not made for XML or Binary stores—since they are atomic, there is a much lower likelihood of data loss that involves corruption of the file, especially since the writes are typically atomic and the old file is not deleted until the new has been successfully written.

This behavior means that, in some situations, saving even a small set of changes to an SQLite store can considerably longer than saving to, for example, an XML store (for example, where saving to an XML file might take less than a hundredth of a second, saving to an SQLite store may take almost half a second). Since SQLite is updating part of a file, and loss of that partial update would be catastrophic, Core Data (through SQLite) goes to greater lengths to ensure that the bytes are really written.

You can set the defaults key com.apple.CoreData.SQLiteDebugSynchronous to one of three values, 0 (OFF), 1 (NORMAL), or 2 (FULL)

FULL: all disk syncing is performed via the fctl FULL_FSYNC command—a costly but rock-solid “write my bits to disk” operation.

We got burned in SQLite comparisons against Linux and such – since sqlite on other platforms used the fsync() operation to sync bits to disk (a cheaper but less robust disk syncing operation).

One could launch Aperture with com.apple.CoreData.SQLiteDebugSynchronous set to 0 to see if this improves performance. I’m hesitant to do this on my primary library, because one little mistake might cause the whole SQLite database to become corrupted. My SQLite database file is already 630MB in size. I can easily see how locking and editing a small part of that file can be fast for an individual change, but really long when you take in account dozens or hundreds of changes happening at the same or similar time.

An Annoture user can’t run the application because the Aperture SQLite3 database can not be opened. He’s getting the error from the program and from the command line when manually trying to access the database.

Unable to open database file

Any Mac OS X and SQLite3 gurus know why this might be the case. This is the first time I’ve encountered where a user can’t access the database. He’s running Aperture 1.5.1 on OS X 10.4.8.

In Timeature, I have the app tell Aperture to switch to the Library via AppleScript. What should be a very fast operation turns out to be glacially slow. Any AppleScript wizards care to explain why this is the case? Here’s offending code that you can run in Script Editor:

tell application “System Events”
try
set gLibraryRow to a reference to item 1 of every row of outline 1 of scroll area 1 of splitter group 1 of splitter group 1 of window “Aperture” of application process “Aperture”

select gLibraryRow
end try
end

The script tells Aperture to select the Library row in the Projects Pane. Getting a reference to the library row takes no time at all. It’s the select operation which takes something on the order of 30-60 seconds to complete.

I need to fire myself and hire a real QA team. A couple of international users discovered a problem related to number formats and localization in Timeature and Annoture. Since both apps share some of the same codebase, I had to release a point update — 1.0.2 and 1.0.1 respectively — to them.

The issue only manifests itself during registration, so if you haven’t paid, buy a license to experience the full gravity of receiving an AppleScript error dialog! All kidding aside, there’s no reason to update your apps to these versions unless you’ve purchased the app already and are experiencing difficulties during registration.

I’m happy to announce that Annoture 1.0 has been released! It’s taken me a little longer than I expected to get it out, but I think it will be worth the wait. Users of iView MediaPro and Aperture who need a metadata bridging solution can look no longer. Annoture makes it simple to transfer annotations back and forth between the two applications.

Version 1.0 brings dramatic speed improvements over previous versions of Annoture. Selection support in Apertre has been added, as well as German localization. You can find out more details on the Annoture webpage here.

I have been using Annoture on my 80,000+ image collection, which I’ve finally imported (by reference) into Aperture. It’s not done processing all of my photos yet, but it’s good to know that I don’t have to worry about manually copying annotations anymore.

I updated Release Candidate 1 of Timeature to full release status. One change was made in the application to overcome a bug discovered in a SQL statement call by Timeature.

Bugs are the bane of any software developer’s life. Many of us would much rather focus on adding new functionality than fixing things that are broken. It’s sad truth in engineering that a vast majority of time is often spent isolating and squashing bugs.

I’ve come across two bugs which have been driving me batty. The sad thing is that I can’t fix them myself; they are big bad motherbugging bugs in Apple’s software, Aperture and Interface Builder.

Aperture Metadata Export Bug

When you use Aperture to export to a PSD, TIFF, or JPEG, Aperture can optionally add IPTC metadata into the exported file. Today, there are two well-known ways of embedding such information into a file, and both place the information into the image file header. The first, XMP, is a relatively new standard created by Adobe. XMP is an XML-based markup language used for defining various types of metadata in an image. The XMP information can either be stored in the file or in a separate sidecar file. XMP is relatively new, unlike the section option, IPTC, which has its roots way back in 1965. Adobe led the charge in 1994 toward getting IPTC more widely adopted in the digital imaging world by defining a way to embed IPTC information in a file. This header block came to be known as the Photoshop Information Block, or PIB. For many years, applications were developed that could read and write to the PIB. The PIB block had a very set way in determining fields and values. Many fields were bounded, meaning they could only accept a certain number of characters, such as 8 or 256. Contrast this with the extensibility of XMP, and you can see why XMP will become the defacto standard for applications in the next few years.

Enough of the history lesson. What does this have to do with Aperture? It turns out that Aperture has multiple ways of exporting metadata, all of them located in the File -> Export menu:

1. Export Metadata: This feature dumps the metadata in selected images into a tab-delimited file
2. Export Masters: Export the master images with separate XMP sidecar files.
3. Export Versions: You can define an Export Preset which places the metadata into the exported files.

Let’s take a look at how Aperture handles option number three. Even though Aperture supports creating external XMP sidecar files, it does not know yet how to embed XMP into the image itself. When exporting versions, Aperture embeds the metadata into the PIB block in the image header. To compound matters further, Aperture simply takes whatever values were entered in the metadata fields and dumps them into the PIB block. Remember, however, that the format of the PIB is not up for renegotiation. Let’s take a look at an example, the IPTC Date Created field.

If you try to enter a value for the Date Created IPTC field in Aperture, you will be forced to enter the value to be compliant with the ISO 8601 standard. Thus, the field value should be YYYY-MM-DDThh:mm[:ss][tz]. This format, however, is in direct conflict with the original IPTC specification for the same field: YYYYMMDD! Aperture does not translate the ISO 8601 XML-compliant value for one that is works in the PIB block. This is the case with other IPTC fields in Aperture; because of this, exported image versions often have metadata that is incorrectly parsed and displayed by applications like Photoshop and iView.

For the technically inclined, take a look at the following hex readout of the Date Created IPTC field.

1C 02 37 00 19 32 30 30 36 2D
30 33 2D 30 39 54 31 32 3A 30
30 3A 30 30 2D 30 37 3A 30 30

1C02 is the marker for a new IPTC tag. 37 is the IPTC field type (37 (Hex) = 55 (Decimal) = Date Created). 00 19 is the length of the field, or 25 characters long. The rest of the information represents the string that the user entered in Aperture: 2006-03-09T12:00:00-07:00. Remember, Aperture requires that the value for the Date Created field follows the ISO 8601 guideline for formatting dates: YYYY-MM-DD[Thh:mm][:ss][Z], where the items in brackets are optional.

The original IPTC specification calls for the Date Created field to be exactly eight octets in length. If Aperture embedded this information into an XMP-block, it could use the value that the user entered. However, since Aperture is embedding the info in the older-style block, it must properly format the field. The correct field should look like this:

1C 02 37 00 08 32 30 30 36 30 33 30

Or in human-readable terms, the IPTC tag Date Created with the value of 20060309.

Because of this bug, I was not able to add a feature in Timeature which optionally set the value for the IPTC Date Created field when adjusting the dates of the selected images. There's really nothing I can do. If I code Timeature to write according to the ISO 8601 standard, the Date Created field will be corrupted in exported image versions. If I follow to the original spec, XMP sidecar files for exported masters would be broken. Damned if you do, damned if you don't!

The only solution is for Apple to fix this bug. If they insist on writing to just the PIB block, Apple engineers need to do a better job of ensuring they following the IPTC block format guidelines. Apple could also do what iView does, which is write to both XMP and PIB in the image. The problem there lies in the fact that there are two data structures initially containing identical information. What happens when you change the value of a field in one block (i.e. PIB) but not in the other? This is a actually an issue with iView, which has not been adequately dealt with.

Interface Builder

IB has crashed more times than I want to remember during the course of developing Timeature and Annoture 1.0. Once it crashes, it trashes the entire nib file. If you have set IB to create backup copies of your nib files, you're not out of the woods yet. For some reason, IB crashes while trying to save to a nib file that has somehow become corrupted. This literally happened a half a dozen times. The nib file gets corrupted, and the backup copy is in a state where its keeps making backups and keeps crashing IB. The only solution that I could find was recreating the entire nib file. That is annoying!

So, there you have it, two infuriating bugs that I can't fix. I've done what I could do to work around the issues. I can only hope that Apple will fix these soon!

Hot on the heels of the Timeature 1.0 release comes 1.0.1 Release Candidate 1. This version adds the following improvements to the application:

• Image Dates persist after Aperture Library Rebuild
• Added EXIF date adjustment
• Date Picker valid range is now beween 1902 and 2037
• Timeature switches to the Library during image processing to ensure that the changes are saved properly

This biggest fix is that the edited image dates now persist after a library rebuild, a common task when upgrading to the latest version of Aperture. The EXIF date adjustment option allows you to reset the values for the image date to what was originally imported by Aperture. As far as I can tell, Aperture does not look in original file when you make a call to retrieve the EXIF “Image Date” tag.

Finally, the app runs a lot more smoothly now that it doesn’t ask you to click to another project/album to complete the update process. Timeature will automatically switch to the Library to complete its changes. Sadly, there’s no easy way to programatically switch back to a specified album or project.

In all honesty, I’m sure that Apple will add such functionality to a future version of Aperture. It’s probably best that they do it, since Timeature is in effect going under Aperture’s walled-garden API and directly setting values in the SQL layer. This is a different approach than Annoture, which uses the SQL database for lookup only and the AppleScript API for all of the heavy lifting of copying annotations to and from iView MediaPro.

For the time being, however, Timeature fills a gap in Aperture’s list of features. For those photographers who need to get work done now and don’t have the time to wait for version 1.6 or 2.0 of Aperture — likely six months to a year from now — Timeature may prove very timley (pun intended).

I’m pleased to announce the availability of Timeature 1.0! With Timeature, you can easily adjust the Image Date field of images imported in Aperture! The correct Image Date ensures that your photos are sorted properly within Aperture. This field is sadly not currently user-editable in Aperture 1.5, hence the need for this application.

Some background information on the use of the Image Date field. This field is automatically generated at import time from the EXIF shooting date of the image. If the imported file does not contain this EXIF information, Aperture will use the file creation date as the value for the Image Date field. This information is stored for quick retrieval in Aperture’s database. It is this field that Timeature modifies. Timeature makes no modifications to the original master file.

Check out more information on Timeature here!

Update: Looks like I’ll have some more work to do with Timeature in the coming days. This thread on Apple’s Discussion Forums alerted me to the fact that I’ll need to update the plist file associated with each image version after I have done the SQLite3 database update. It turns out Aperture writes information about each version to two places: the database and a plist file. Fun fun.

I sense a pattern with these application names.

Timeature is coming right up on the heels of the impending Annoture 1.0 release. In the Aperture discussion forums, I’ve been tracking a growing need for users to be able to edit the image date of an imported photo. Aperture 1.0 and 1.5 haven’t let users do this, although iPhoto has a facility for modifying an image’s capture date.

I actually ran into this problem while importing — by reference — my entire photo collection of over 80,000 images. Some of my imported photos had the incorrect capture date. I had to manually remove the photos from Aperture, update the capture date using iView and reimport the photos. It was a very time consuming process. John talks more about the problem on his website.

Enter Timeature. This application will allow you to modify the capture date of selected images in Aperture. It does not change the EXIF date in the Master image file. Rather, it updates the ZIMAGEDATE field in the image version table (ZRKVERSION). The application will let you choose a specific date or adjust date by time increments — days, minutes, hours, or seconds.

Look for a release of Annoture and Timeature by the end of this weekend!

My investigations of Aperture’s internals continue with a question from John:

There’s no way in Aperture to change the image date value Aperture stores in its database. We know it doesn’t have to be the same as the embedded image metadata value because if you import from iPhoto Aperture stores iPhoto’s user defined date value.

Is there a Scriptable API for changing the value of the Aperture database date value?

Here’s what I have found. In the Aperture database table zrkversion, there are numerous timestamp fields:

• ZEXPORTMETADATACHANGEDATE
• ZEXPORTIMAGECHANGEDATE
• ZFULLSIZEPREVIEWCHANGEDATE
• ZDATELASTSAVEDINDATABASE
• ZCREATEDATE
• ZIMAGEDATE

The one we’re looking for is ZIMAGEDATE. The value looks to be in NSDate format. I wrote the following AppleScript to convert the value into a more useable AppleScript date object:

set theDate to call method "dateWithTimeIntervalSinceReferenceDate:"¬
	of class "NSDate" with parameter (theTimestamp as real)

There’s no AppleScript API in Aperture’s dictionary to access this data, so you’ll need to go directly into the SQLite3 database of Aperture if you want to edit the image date of selected images. Perhaps I’ll write an application that helps people edit the image date!

Email me if you have any suggestions. In the meantime, I will be poking around the Apple Discussion Forums for more details on what people want.

The task today for Annoture is localization. I’ve been looking far and wide across the Internet for an AppleScript equivalent to Cocoa’s stringWithFormat method to no avail. The lack of such a native function makes localizing an AppleScript Studio application difficult, as you can’t easily create formatted localized strings such as:

“%d image annotations were copied from %s to %s”

The alternative of creating several strings that I would have to concatenate was not very palatable, so I ended up writing a simple function that uses AppleScript’s do shell script command to call printf.

on localized_formatted_string(key_string, parameters)
	set cmd to "printf " & quoted form of¬
		(localized string key_string from table "Localizable")

	repeat with i from 1 to count parameters
		set cmd to cmd & space &¬
			quoted form of ((item i of parameters) as string)
	end repeat

	return do shell script cmd
end localized_formatted_string

If you’re not doing localization but want printf functionality in AppleScript, take out the line localized string key_string from table "Localizable" and replace with simply key_string. Parameters is simply a list of parameters to the printf command.

Now we’ll see how long it takes Google to index this post so people in the future don’t have to struggle as much as I did!

I’m putting the finishing touches on a revision of Annoture which will bring compatibility with iView 3.x and Aperture 1.5. Star ratings and faster processing of images are some of the highlights of this release. Once the app passes a few more tests, I’ll release it out to the world. Stay tuned!

This post will detail some of the new AppleScript goodies and oddities of Aperture 1.5.

Goodies

• Selection: I can’t stress how much I love this feature. It will certainly make development of new features much faster now that I have access to the currently selected images.

Oddities

• Selection: If you select a stack of images, the selection property will return all images in the stack. There no stack property in Aperture yet. I expect something like that to come in version 2.0.
• Sublocation becomes SubLocation: The IPTC tag name has gone from Sublocation to SubLocation with a capital L. In Annoture 0.9.3, iView 2.6.4 and Aperture 1.5, this caused problems syncing the SubLocation IPTC tag.
• Caption becomes Caption/Abstract: The IPTC tag name has gone from Caption to Caption/Abstract. This caused problems syncing the Description IPTC tag.
• Keywords property: Not sure if this is working properly, but I’m unable to access the keywords property for the selected image
  

  tell application “Aperture”
  set theImage to first item of selection
  set theKeywords to keywords of theImage
  end tell

  This doesn’t return a proper keywords list for me. Boo hoo.

It’s available via Software Update!

One feature that I’m eager to test out is the AppleScript selection property of the Aperture application:

selection (list of anything, r/o) : The objects currently selected in the browser

Right now, I’m upgrading my Library to 1.5 format. There’s no turning back now. I’m going to spend some time this weekend rethinking how I want to organize my photo collection. Now that we don’t need to store the actual images in the Library, I can recreate some of what I’ve accomplished with iView Media Pro where my photos are stored and referenced on an external hard disk (my 1TB ReadyNAS). Like iView, Aperture 1.5 would simply access the files from there. I have a feeling that performance will be impacted, however, when the files are served from the network, so I might just have to invest in a 750GB external hard disk and use the NAS as a backup drive. To date, all of my original and RAW images take up 400GB of disk space. A 750GB hard drive would give me a couple more years of service.

Update: If you select a stack and ask Aperture for the selection in AppleScript, it returns all the images in the stack, not just the one in the viewer.

Aperture owners across the world are no doubt clicking on the Software Update Check Now button every hour to see when version 1.5 is available. Yesterday, iTunes 7.0.1 was released, and today the iLife suite was updated. This update includes media browser support for Aperture. Thus, 1.5 is just around the corner; my guess is we’ll see it tomorrow morning!

I’m really hoping for some performance improvements in 1.5. I’ve used Aperture for the past three wedding shoots. Compared to Capture One, working on images in Aperture is overall much slower. Part of this has to do with Aperture’s real-time RAW decoding and image updating. Capture One uses a large preview image when performing image edits. In addition, Aperture default color profiles are no match for Capture One and Magne Nilsson’s custom color profiles. It simply takes longer to get accurate color with Aperture. If 1.5′s new hue and saturation controls lets me make a custom color profile preset that matches Capture One, I’ll be a happy camper.

Of course, Aperture is great for selecting and rating images. As I mentioned in my previous post, the 1.5 feature set has me thinking of switching from iView completely for DAM purposes. I’ll need to update Annoture to make sure my annotations transfer from iView to Aperture. That should run much smoother with the new AppleScript functions.

There are some juicy updates in Aperture 1.5 with regards to AppleScript support. One of the biggest problems I had in developing Annoture was getting references to the currently selected images. There simply was no way to accomplish this in versions prior to 1.5. Now, however, we have selection available in AppleScript, as well as easier ways to tag metadata to images. The next release of Annoture might be written as an Automator action with iView. Stay tuned for more details once I have my hands on 1.5.

It’s no surprise that Apple has updated Aperture on the eve of the Photokina photography conference. Version 1.5 brings several new features to the table:

• Flexible Library Management: Taking a cue from Lightroom and iView Media Pro, Aperture now allows you to store your images wherever you want. This is one feature that I was really looking for
• iLife integration: One big drawback with iView Media Pro is its relatively poor integration with the iLife and iWork products from Apple. Aperture used to be on its own island as well, but no longer!
• Export metadata to XMP files: Not quite embedding the metadata with the image itself, which I would prefer, but at least Aperture 1.5 lets you export to a sidecar XMP file now
• Advanced Color Controls: Finer-grained color adjustment tools. What I’d really like to see are custom color profiles for different cameras. Capture One with Magne Nilsson’s color profiles provide me with very accurate and neutral colors from the get-go. This means less dickering around with the temperature and tint sliders, something I’m endlessly doing in Aperture.
• Metadata Presets: Not much to say here, but a welcome improvement. Eric and I were discussing this feature yesterday at his place.
• Adjustment Presets
• Image selection via AppleScript: Finally! This will allow me to update Annoture to be even more powerful. I’ve been falling behind on updating my syncing app between iView and Aperture due to new incompatibilities with iView 3.1.x and Aperture 1.1.2.
• Automatically Generated Previews: I wonder if this willl make Aperture run faster, especially since the app now runs on any Intel-based Mac. Capture One uses a high-resolution preview image for all of its on-screen image refreshing. Previous versions of Aperture rendered the final image every single time you made a correction. Even if you had a really fast video card, image manipulation could get really, really, slow.
• Improved File Renaming: I’ll have to see, but maybe it’s time to replace the venerable ExifRenamer from Stefan Robl? In fact, on paper this new update may be just enough to leave iView Media Pro for good.
• Export plug-ins: A new extensible architecture allows access to Aperture from third-party applications. I wish I had been informed of this for my Annoture work, but it appears that the focus of the plug-in architecture is on exporting to third-party web sites like Photoshelter or iStockphoto.
• Free Update: The best news of all is that this version of Aperture is a free update for existing owners!

I’m sure there are more features in this release that are waiting to be revealed. When it’s available later this week, I’ll share with you my experiences using the app.

Update: Ben Long from CreativePro has a beta review of Aperture 1.5.

Ran CineBench 9.5 on my new video card last night. Here are the results:

****************************************************

Rendering (Single CPU): 381 CB-CPU
Rendering (Multiple CPU): 1135 CB-CPU

Multiprocessor Speedup: 2.98

Shading (CINEMA 4D) : 394 CB-GFX
Shading (OpenGL Software Lighting) : 1352 CB-GFX
Shading (OpenGL Hardware Lighting) : 3754 CB-GFX

OpenGL Speedup: 9.52

****************************************************

Oliver over in Germany did a similar test on his Quad with the 7800 GTX 512 and got the following results:

****************************************************

Rendering (Single CPU): 386 CB-CPU
Rendering (Multiple CPU): 1173 CB-CPU

Multiprocessor Speedup: 3.04

Shading (CINEMA 4D) : 385 CB-GFX
Shading (OpenGL Software Lighting) : 1286 CB-GFX
Shading (OpenGL Hardware Lighting) : 2748 CB-GFX

OpenGL Speedup: 7.14

****************************************************

So, I’m seeing a bigger OpenGL Speedup than he is. Results from a stock 7800 GT seem very close to what Oliver is getting. Anybody else with a 7800 GTX got CineBench scores to share?

I received and installed my new Nvidia GeForce 7800GTX 512MB video card from rubytuesday. For those of you who have not been following the saga, the stock Nvidia 6600 video card that most Dual-Core G5 PowerMac owners have purchased is dog slow when performing any Core Image tasks. CoreImage is used throughout Mac OS X but especially in apps such as Motion or Aperture. The 6600 was in fact removed from Apple’s list of recommended cards for Aperture a few months ago.

Since Apple isn’t offering any aftermarket video cards, people have had to purchase reflashed PC video cards. The 7800GTX has been reviewed and given a stellar review on the Mac performance website BareFeats. At $750, it’s not cheap. Given the speed increase over the 6600, however, the 7800GTX will pay itself off with my next photo job.

I’ve posted a couple of videos on YouTube that demonstrate the speed differences between the 6600 and the 7800GTX below the fold.

I ran my tests using the recently released Aperture 1.1.2. This version has some noticeable speed improvements over the previous updates, but as you can see, it’s still slow. The first movie shows Aperture running on my Quad with the stock 6600 video card. Notice how long it takes for the image to update after I have moved the sliders. The performance of the straightening tool is especially slow with the 6600.

The second movie shows Aperture running on my Quad with the 7800GTX. Notice how much more quickly the image is update when operating the sliders. The straightening tool, for instance, updates in pretty much real-time.

All in all, this is looking to be a good upgrade. If you are a photographer using Aperture with a Dual-Core PowerMac and the stock 6600 video card, do yourself a favor and purchase a 7800GT or a 7800GTX today! rubytuesday has four cards for sale:

• 7800GTX 512MB RAM
• 7800GTX 256MB RAM with Quadro Cooler
• 7800GTX 256MB RAM
• 7800GT: Equivalent to the OEM 7800GT

Update 6/28/2006: Apple released Mac OS X 10.4.7 update, which some people say improves Aperture performance even more. Will test out in the next few days with my observations.

Some photos from the installation.

When I bought the Quad, the only video option around was the entry-level card, the Nvidia GeForce 6600. The 7800GT was a BTO and would have taken an additional month or two to arrive. Had I known how dog slow the 6600 would be with applications that rely so heavily on CoreImage and the GPU, such as Aperture, I might have held out.

This morning, I sent in an order for a reflashed Nvidia GeForce 7800GTX 512MB. From the review on BareFeats, it’s the fastest video card for the Mac today. In a few months, when Apple releases the new MacPros, that will likely change. That’s tomorrow, however, and I need faster performance now.

This afternoon, I swapped hard drives out of my PowerBook. It was a harrowing experience the first time I did it a couple of years ago, and it was harrowing today as well. The “new” hard drive in the PB is actually the original 40GB hard drive. The “old” hard drive was an 80GB model that has developed several bad sectors. Disassembling the laptop is not was the faint of heart, and I am very glad that there are several websites that detail the process. Thanks to Vin and Chris for their help today!

A user of Annoture has discovered an incompatibility between the recently released iView Media Pro 3.1 and Annoture 0.92. Annotations from iView to Aperture do not work. I’m investigating the problem and hope to have a fix soon. If you use iView, consider using version 3.0.2 instead of 3.1.

When iView released version 3.0, they changed some of the AppleScript dictionary terms making scripts developed for previous versions of the product fail horribly. They fixed this problem in 3.0.1 days later. Let’s hope that the fix is something similar.

I also have the shaking suspicion that Aperture 1.1.1 changed the underlying SQLite Database. Annoture has been running much more slowly when paired with Aperture 1.1.1. More stuff to look into!

Jon Gruber has more information on the recent Aperture team news.

I have noticed that certain operations on my Quad PowerMac with Aperture 1.1 seem slower than they did with Aperture 1.0 or 1.0.1. I think I’ve found the culprit, the Nvida GeForce 6600 video card. I’ve found several threads on Apple’s discussion forums:

• Thread #1
• Thread #2
• Thread #3
• Thread #4

Apparently, Aperture performance is significantly better with a 7800GT or Quattro video card. The 6600 card has been removed from Aperture’s system requirements in the Apple Store. I would have gone for the 7800GT BTO option, but they weren’t available when I ordered my Quad.

I’m a little disappointed that we can’t buy any third-party video cards for the latest PowerMacs. Sadly, Apple’s video card upgrades are for new systems only. There is the possibility of getting a reflashed 7800GT from eBay or from this store, but the idea of paying an extra $750 isn’t all that appealing.

I read today on ThinkSecret that Apple has axed or transferred much of the team behind Aperture. I had heard rumors, but this is the first time I’ve seen it published on a Mac news site. I don’t see this as a problem for the future of Aperture. Software engineering teams come and go these days. I doubt many large-scale software products have their original team members around.

Update: Some interesting posts in this Slashdot thread.

Anyhow, I’ve been using Aperture 1.1 to process photos from Facing East’s Family Style performance in San Francisco two weeks ago and their performance at Wright State University this past weekend in Ohio. It’s still not the complete end to end solution that I want, but it’s getting better. I still have to perform some extra Noise Ninja work on the final Aperture output, but I have to do that with Capture One and Digitial Photo Professional too.

I’ll have a fuller recap of the dance performances soon. I keep saying that, but work and life lately has been busy! For now, enjoy some of these photos from Family Style!

Apple released Aperture 1.1 today. Some surprising things aside from the expected bug fixes and feature improvements:

• They lowered the price from $499 to $299
• They are offering $200 voucher for the Apple Store to early adopters of Aperture

The second item really threw me for a loop! If anything, it’s an admission on Apple’s part that they are serious about the pro photo marketplace and are apologizing for the deficiencies in the 1.0 product.

I’ll be installing 1.1 this weekend and putting it through its paces. I’ll be photographing Rae’s dance performance tonight during their tech rehearsal. Should be a good for testing Aperture’s new noise reduction algorithms.

Today, I received an email from Apple asking me if I wanted to do an Aperture user survey. I took 20 minutes out of my morning to fill it out, and I was surprised at how disappointed I was with the 1.0/1.0.1 release. There’s a post on Photography Blog that lists some of the new features in the upcoming 1.1 release. I’m hoping that the update will fix what I marked in the survey as the most disappointing aspects of Aperture:

• RAW processing algorithms
• Noise reduction
• Photo organization and management

Aperture has great potential, and I really want to use it on a regular basis. Today, I’m still using iView Media Pro 2.6.4 for my photo organization and CaptureOne for my wedding projects. For studio shoots, Aperture works great, but for those projects that require high-ISO image processing, it can’t yet compare to the combination of CaptureOne/DPP and NoiseNinja.

Apple is showing off Aperture 1.1 at PMA this week. MacWorld has a good article detailing some of the new features.

Better RAW decoding, sharpening, and noise reduction algorithms are the ones that I’m most interested in. I’ve been using Aperture for several projects the past couple of months. In the studio, the results are not bad. In shooting conditions with good light, Aperture’s results are perfectly acceptable. Where the program breaks down is in high ISO, low-light environments. Aperture’s 1.0/1.0.1′s noise reduction sucks.

There’s also a report from InsideAperture that has additional details. Rob Galbraith has positive initial thoughts on Aperture 1.1′s RAW conversion results:

The real news of v1.1 is something we knew Apple was beavering away on, but we didn’t expect to see results this soon: RAW file decoding that at first blush appears to have none of the improperly sharpened and somewhat smeared look of Aperture conversions today. Instead, what we saw when we got in close to the monitor was Canon EOS-1Ds Mark II photos that had the finely detailed, photographically natural look we’ve seen in our own EOS-1Ds Mark II workflow in which Canon’s Digital Photo Professional 2.0.3 is the converter and converted files are optimally sharpened in Photoshop to compensate for the softening effect of the camera’s optical low-pass filter.

Adobe released Beta 2 of Lightroom today. Some of the new and improved features include:

• Now available as a Universal Binary for compatibility with Intel-based Apple hardware
• Crop and Straighten tools included in the Develop module
• Ability to add music to slideshows
• White balance support for the Nikon D2X, D2Hs and D50 cameras
• Ability to create hierarchical keyword sets
• XMP Import and Export capabilities. (Please consult Known Issues list for details)
• Improved Edit in Photoshop capabilities
• Improved metadata handling

Our COBA meeting last week featured demos of Lightroom, Aperture, Bibble, Raw Shooter Premium, and LightZone. I’ll have some photos from that event up soon.

I’ve been using Aperture for several projects lately, and I have been happy and frustrated with versions. I want to create a separate version of a photo that exists solely in one project or another. When I drag a version from one album to another, it creates a link between the two. Thus, if I make a change to one of the versions — such as adjusting the exposure or the crop &mdash the change is reflected in the other album. While this can be a good feature, it can also be very annoying when you want to keep them separate. I’ll dig around the support forums later this week to find a solution to the problem.

Adobe fired back at Apple with a public beta release of Lightroom. The beta is fully functional until June, 2006! There’s quite a bit missing from this iteration, especially in the realm of metadata handling, but Adobe plans to release several more versions before the final release.

After downloading, do check out the 20 minute video overview of the product. You can make a drinking game out of the number of jabs the narrator makes against Aperture. Things of note include:

• Ability to reference images in existing locations. You can import images directly into Lightroom’s library or keep your files when you originally placed them.
• Ability to run on less powerful machines.
• Speed of exporting images. Uses a high-resolution version of the image for exporting to PDF. No need to rerender the image.
• Camera RAW. The RAW processing algorithms should be similar to Adobe Camera RAW. If you like the results from ACR, you should like the results from Lightroom.
• Fitts Law. You can configure the app in a way where you drag your mouse to the edge of the screen, and various UI elements, such as the adjustments panel, the library pane, and the thumbnail film strip appear. Nice.

MacWorld is this week, and you can be sure that both the Adobe and Apple booths will be packed with photographers asking questions about Aperture and Lightroom. Good for us. The pro photo organization software market is ready for some innovation and competition!

What I continue to find amazing is the frequency of concurrent product ideation. Lightroom and Aperture have been in development for some time, so it’s not as if one product was whipped up days after the other’s product release. The feature sets for both products are very similar. It’s as the industry is a real entity with a mind. The companies act simply as implements for its thought processes.

More people are talking about Lightroom:

• Uwe Steinmueller has an in-depth preview of Lightroom on Outback Photo.
• Michael Reichmann on Luminous Landscape
• Story on the development of Lightroom

Version 0.9.2 of Annoture has been posted onto my website.

There’s almost always a simpler solution to the problem. Hours after I released Annoture 0.9.1 to the world, I discovered an easier way to locate the current Aperture Library. I didn’t realize how many people would place their Aperture Library in a location somewhere other than ~/Pictures/. Since I haven’t switched to using Aperture full-time, I stuck with the default library location. I have since found out that many people are placing their Aperture Library on external hard drives or secondary internal hard drives.

I am now retrieving the Aperture Library Path directly from Aperture’s preferences file, located at:

~/Library/Preferences/com.apple.Aperture.plist

There are two property fields that need checking, LibraryPath and LibraryPathOnRestart. If you change your Aperture Library location in Aperture’s preferences, you need to restart Aperture to load the new library.

Annoture 0.9.2 uses this preference to determine the current Aperture library location. Because of this, I removed the Aperture Library Path preference in Annoture’s Preferences window.

Thanks to Carsten H, Charles J, and Don K, for helping me debug this situation.

I squashed a bug today in Annoture. When selecting another location for the Aperture Library, Annoture did not correctly set the preference. As a result, when you copy annotations from iView to Aperture, no matches could be found.

Version 0.9.1 of Annoture has been posted onto my website.

I have my Aperture Library on my boot drive, but I suspect many people have chosen their primary Aperture Library location to be an external FireWire hard drive or a second internal hard disk. If you are installing from version 0.9, be sure to reset your Aperture Library location in Annoture’s Preferences.

iView Keywords to Aperture works on both iView MediaPro 2.6.4 and 3.0.1. The script will add new or append to existing keyword groups in Aperture’s Keyword HUD.

Visit the iView Keywords to Aperture web page.

A post on Rob Galbraith’s led me to discover where Aperture is storing its auto-complete items for Keywords and IPTC fields.

Although Annoture copies keywords/people from iView media items to Aperture image versions, the keywords/contacts are not copied over to the autofill lists. Aperture keeps a list of keywords and autofill items here:

~/Library/Application Support/Aperture/Keywords.plist
~/Library/Preferences/com.apple.Aperture.plist

iView 2.6.4 and 3.0.x maintain lists in two different places:

~/Library/Application Support/iView/Plug-ins/Favorites/
~/Library/Application Support/iView/Plug-ins/Vocabulary/

It wouldn’t take much to convert iView keywords to Aperture keywords and back, although going from Aperture->iView, you won’t get the hierarchical keywords. Note that Aperture has two types of keyword support, it’s hierarchical keywords system and an IPTC keywords property that appears to be used when importing already annotated images.

~/Library/Preferences/com.apple.Aperture.plist is chock full of interesting preferences. I’m going to enjoy looking through all of the properties to help improve my applications.

Well, it’s not as easy as I thought it was going to be. Such is life when scripting Aperture

I was able to write a script that adds People from iView to Aperture’s iptcProperties.Contact.Completions property in the com.apple.Aperture.plist preference file. Inspecting the file in Property List Editor shows that the items were copied correctly.

Restarting Aperture shows that only the first nine or so annotations are used in the auto-complete. If I start typing the first few characters of the 10th item, auto-complete does not happen

Furthermore, quitting the application changes the value of iptcProperties.Contact.Completions, removing all of the items we just added from iView!

Here’s the current script that I’m using for testing purposes.

property aperturePrefPath : "~/Library/Preferences/com.apple.Aperture.plist"
property apertureKeywordsPath : "~/Library/Application Support/Aperture/Keywords.plist"
property libraryPath : path to library folder from user domain as string
property iView2Aperture : {{"People", "iptcProperties.Contact.Completions"}}

set iView2Path to libraryPath & "Application Support:iView:Plug-ins:Favorites:"

-- This script runs with iView 2.6.4. iView 3.x users will have to modify
-- the script to work on their systems

on iViewCompletionsToAperture()

	tell application "System Events"
		set aperturePrefs to property list file aperturePrefPath
	end tell

	repeat with anItem in iView2Aperture
		set iViewPrefsFilename to iView2Path & first item in anItem
		set apertureIPTCProperty to second item in anItem

		set theList to iViewGetCompletionList(iViewPrefsFilename)

		-- now replace aperture's completion prefs with iView's
		-- we could do a union, but this is a quick and dirty method

		if theList is not {} then
			tell application "System Events"
				set value of property list item apertureIPTCProperty of aperturePrefs to theList
			end tell
		end if

	end repeat

end iViewCompletionsToAperture

on iViewGetCompletionList(theFilename)
	set theList to {}

	-- read the contents from the iView preferences file
	try
		set theContents to ""
		set fp to open for access (alias theFilename)
		set theEOF to get eof fp
		set theContents to read fp until theEOF

		if theContents is not "" then
			set AppleScript's text item delimiters to return
			set theList to text items of theContents
			set AppleScript's text item delimiters to ""
		end if
		close access fp
	on error
		try
			close access fp
		end try
	end try

	return theList
end iViewGetCompletionList

iViewCompletionsToAperture()

I’ll try now with Aperture’s hierarchical keyword list. Maybe things will be different for that since those preferences are not stored in com.apple.Aperture.plist.

Introducing Annoture, a metadata bridging solution for Aperture and iView MediaPro! With Annoture, you’re just a click away from sharing metadata between these two popular image management and cataloguing applications. Spend more time working with your decisive moments than worrying about double-entry and incomplete metadata!

Annoture lets you transfer annotations from iView MediaPro catalogs to Aperture projects and albums and back. This two-way transfer of IPTC and metadata information means you are not tied to any one application for your image management and workflow needs. Annoture also features a modular interface that can be extended to support additional applications in the future.

Users of Aperture and iView can download a fully-functional version of Annoture. The unregistered version will occasionally display a reminder to register, and all images processed in Aperture by Annoture will have a custom “Annotated with Annoture!” tag added. You can remove these items with the full version after purchasing and entering your license code.

For more information, please visit the Annoture web page.

I love it when a plan comes together!

Annoture is now successfully transferring annotations from iView to Aperture and back. I completed the last piece, Aperture to iView, just a few minutes ago, and it’s great to see things running smoothly.

There’s just a few more pieces to finish before I can wrap up this application and release it into the wild. I can finally see the end of the tunnel from here!

One issue which will be difficult to resolve happens when copying annotations from Aperture back to iView. Since Aperture lets you have multiple versions of the same image, which one do you pick? The application currently selects one of the master versions to transfer on a semi-random basis. There’s no guarantee that it’s the one with the most up-to-date annotations. In the SQLite database, there is a ZEXPORTMETADATACHANGEDATE field, but the format of the date is strange. Sample values include: 155143329.224529, 155139934.77349, 155139919.663023, and 155139928.835527. Anyone know how to decipher this? I could add an additional query to select the version that was updated the last.

In honor of Paperture, I’ve changed the name of the program to Annoture.

Earlier, I discovered Apple was handling exporting IPTC information in an old manner. This unfortunately took out a couple of hours to figure out, time which I could have spent working on other parts of the application. For a program that does something quite simple, there’s a lot to do! The great thing is that I don’t mind coding. It’s fun, and I’m making great progress. There’s nothing better than loving what you do!

Some accomplishments from today:

• Aperture Project/Album/Folder picker. For version 1.0, the user can choose on which Aperture container to perform the annotation action.
• Preferences window. When the preferences grew from 3 to 5, they had to go into a separate window.
• Refactoring. I love to refactor, but it takes a long time to test the new sub-systems that I wrote to replace what wasn’t broken in the first place.

Some unresolved questions:

• How do you dynamically add a menu item separator to a popup menu in AppleScript Studio? I’ve searched through the applescript-studio mailing list and couldn’t find the answer. No one through Google seems to know either. Anyone?

It’s 3:14 am right now. I’ve been working non-stop for the past several days. As I said earlier, I don’t see this as work. Sure it’s hard work, but it’s amazingly fun!

Aperture’s metadata exporting routines need a little more work.

Aperture seems to flatten into a single string IPTC fields that can hold multiple values such as Keywords, Supplemental Categories, and Contacts — Keywords, Categories and People in iView terms — during import of JPEGs and TIFFs. If and when they ever read the annotation fields in RAW files, I suspect the app will do the same. Annotations in these fields are flattened into one comma-delimited string.

While it’s good that it was able to transfer the data, the format of the data is sub-optimal when you rexport the data and import it into an application like Photoshop or iView. Keywords and Contacts become one keyword string. In CS’s File Info browser, you can separate multiple keywords or people using the semicolon. iView 2.6.4 and 3.0.1 will happily read these annotations correctly.

Nearly four years ago, I was investigating a problem with the EXIF and IPTC in EOS-1D files. Looking at hex files, I discovered Canon created its JPEG headers in such a way so as to cause annotation issues with iView and Photoshop. Looking at the hex screens for images exported with Aperture, it seems something similar is afoot.

Earlier versions of Photoshop placed IPTC information in an APP13 block (sometimes also known as APP14) within a JPEG file. Photoshop called this information the Photoshop Information Block, or PIB. Newer versions of Photoshop place annotation information into an XMP block within saved files. I’m suprised that Apple is still placing information the old way. It might be that Aperture is using some system-level routines to export data. If this is the case, then it might not be Aperture’s fault as it is in Image Events.

Success!

I had to dig out an ancient version of iView Media Pro 2.0 beta 4 to figure this problem out. Had to change the date of my computer back before July, 2002 to get the iView 2.0 beta to launch! Take a look at how this old version of iView stored its IPTC information:

iView used to store annotation information in the resource fork of images. If you look carefully, IPTC fields are separated by 1C02 followed by a hexadecimal denoting the type of field. Caption is 78, for instance, and People/Contact is 76. Additional Contact fields can be made be simply adding additional 1C02 76 blocks. Each block also has the length of the string in hex format. As you can see in the Aperture and iView 2.0b4 hex screenshots, iView’s has multiple instances of the People/Contact block whereas Aperture has just one.

If you manually add an additional 1C02 76 ... block in the Aperture JPEG, iView will correctly read the People field.

Now this all is fine and dandy, but it won’t work in Photoshop, since it never looked for that field in the first place! iView Media Pro has a separate pane in Photoshop CS’s File Info window, but it now looks in the XMP area for People/Contacts.

As for me, I’ll separate values for multiple fields using commas when I go from iView to Aperture. Nothing I can right now for Aperture to iView, but hopefully, this information will get passed onto the team at Apple and a fix for the problem will show up in a future version of the OS/Aperture.

In my previous post, I wrote that there was no way in AppleScript to get the original filename of a version. Because Aperture uses SQLite to store information about the Library, however, there is a way to access this information!

There are a number of tables in the Library database, which is normally located at ~/Pictures/Aperture Library.aplibrary/Aperture/aplib/Library.apdb, but the ones that I'll focus on are ZRKMASTER, ZRKVERSION and ZRKFILE. Examining the table schemas reveals a common field, Z_PK. This is the unique id for each master image. AppleScript lets me retrieve the unique id for an image version; with that I can access the original filename for the file. Thanks to Scott, deriving the appropriate SQL code was fast:

SELECT zrkfile.zname FROM zrkfile, zrkmaster, zrkversion WHERE zrkfile.z_pk = zrkmaster.z_pk AND zrkversion.z_pk = zrkmaster.z_pk AND zrkversion.zuuid = "yjjEFvlGRReGkOke+xLXsw";

or

SELECT zrkfile.zname FROM zrkfile join zrkmaster ON zrkfile.z_pk = zrkmaster.z_pk JOIN zrkversion ON zrkversion.z_pk = zrkmaster.z_pk WHERE zrkversion.zuuid = "yjjEFvlGRReGkOke+xLXsw";

Incorporating this into my AppleScripts was equally easy, thanks to the do shell script command:

sqlite3 ~/Pictures/Aperture\ Library.aplibrary/Aperture.aplib/Library.apdb "select zrkfile.zname from zrkfile join zrkmaster on zrkfile.z_pk = zrkmaster.z_pk join zrkversion on zrkversion.z_pk = zrkmaster.z_pk where zrkversion.zuuid = 'yjjEFvlGRReGkOke+xLXsw';"

Where "yjjEFvlGRReGkOke+xLXsw" is the id of the image version.

We're getting closer!

Annotation Copier is the tentative name for this application that I’m now ready to seed to a select group of beta testers. Currently, the app transfers annotations from iView to Aperture. A future version of the program will allow you to go the other way, Aperture to iView.

The target user for this application is the photographer who wants to use both iView and Aperture in their digital photography workflow without having to perform double-entry of metadata.

The user interface has been greatly refined since that ugly initial version I wrote a few days ago. Specify the direction in which you want to copy annotations, choose an iView catalog, check off some preferences, and click Copy Annotations.

• Overwrite existing annotations: Annotation Copier will overwrite any annotation in Aperture with the corresponding annotation in iView.
• Skip empty fields: If a field is empty in iView, don’t copy the annotation over to Aperture. This means fields you add in Aperture but not iView will remain the same.
• Confirm changes: Before running, the application will ask you if you want to perform the operation. This is useful if you change your mind since you can’t undo the process.

Here are some interesting tidbits that I came across during the development of this app:

• Annotation Copier matches media items in iView with image versions in Aperture with the same filename and version name respectively. It’s too bad that Aperture doesn’t expose a file name property for an image version, because that would be the ideal way to keep track of a file between the two applications. For instance, if you change the name of an image version in Aperture from “original_filename – Version 1″ to “my new photo”, Annotation Copier won’t be able to transfer annotations back and worth.
• Aperture handles two types of keywords, IPTC and its own flavor. For the time being, Annotation Copier transfers iView keywords only to IPTC keywords in Aperture. It appears that Aperture writers to both their own keywords fields and to IPTC fields. If you update the IPTC fields using AppleScript, however, the Aperture-specific keyword fields are not automatically updated.
• You can copy an image from one project into an album of another project without it appearing in the album’s project. Furthermore, if you place one image version into multiple albums, there doesn’t appear to be a way in AppleScript to detect that the album image is the same image that you annotated one level up. A workaround that I came up with involves creating a custom tag with a unique identifier for each annotation session. If an image has already been annotated, we skip it, greatly speeding up the process.

Here are some screenshots of the application in action. If you are interested in beta testing this product, please leave a comment in the form below with some details about yourself and your current iView/Aperture workflow. There will be a closed beta of about five to ten photographers before I open up the application to the rest of the photography community. Thanks!

Still slaving away on this application to transfer annotations between iView MediaPro and Aperture. I am still running version 2.6.4 of iView, having decided to hold off on the upgrade to iView 3.0 for the moment. I discovered today that the AppleScript annotation records suite between the two applications has changed dramatically. Several property names have changed and more have been added in iView 3.0. For instance, the caption property is now named description. Annotation writer is now description writer. The list goes on. This throws a wrench in my AppleScripts, since you can’t easily reference non-existent properties in an application’s dictionary. Since people might have both versions of iView installed on a single computer, this may cause problems while running my app.

Update: Here’s what you get for not keeping up with updates! Yesterday, iView released an update to version 3.0.1. They added aliases back to the dictionary terms from iView 2.6.4. I still think I need the workaround to handle the case for the properties that exist in 3.0 but don’t exist in 2.6.4, such as creator address, creator URL, etc. So, I guess all the work below wasn’t for naught.

Update #2: HoloCore’s Jacob tells of a way to deal with dictionary classes by using the raw 4-letter code for specifying classes. Is there a way to see any hidden classes used by an application? Is it possible to have a AppleScript property that is accesible in scripts but not viewable in the application’s dictionary?

Prior to learning about version 3.0.1 of iView, here’s the hack that I used to work around the problem. AppleScript doesn’t let you reference property names using variable strings. For instance, you can’t do this:

set theAnnotationName to "description"

return theAnnotationName of theAnnotations

You have to explicitly refer to it with

if theAnnotationName is "description" then
	return description of theAnnotations
end if

Now you can see how having two different names for a property can cause problems. The workaround is to create a run-time script:

using terms from application "iView MediaPro"
	set s to "on run {r}" & return
	set s to s & "get " & theAnnotationName & " of r" & return
	set s to s & "end"
			
	try
		set theAnnotation to run script s with parameters {theAnnotations}
			
		return theAnnotation
	on error
		return false
	end try
end using terms from

I found this workaround in Matt Neuberg’s excellent book AppleScript: The Definitive Guide. It replaced Danny Goodman’s good AppleScript book, which I had for over a decade.

The problem with this workaround is performance. Doing lookups of this nature takes far longer than simply specifying the property name. For the time being, however, I’m going to stick with the workaround. If anyone knows how to deal with dueling application dictionaries, let me know!

Some assorted Aperture tidbits:

• The Library entry in the Projects Pane is really a folder called ” Built-in Smart Albums”. Adding a new folder with a name ahead of this entry, such as ” An Album Ahead” does not place it above in Projects, however.
• The Light Table feature is a little buggy. I arranged my portfolio images in the same manner as we did in Paperture. It is easy to accidentally rearrange the icons in the light table in an unwanted manner, from which you cannot undo. For instance, to better organize my piles, I placed the icons in the Light Table into stacks. This caused the book that I was preparing to freak out, since the pick of a stack is used for each photo in a book. Since the photos in the book were originally not in stacks, each book image was replaced by the pick! Thus, instead of a book with 81 different images, I had a book with 81 images of the nine stack picks! When I unstacked the images to fix the book, the images on the light table were unstacked right on top of each order, losing my making my carefully ordered piles disappear. In the end, I rearranged my wedding picks three times before I gave up using the Light Table. As I learn more about, I’m eager to learn how to lock the photos in the light table so they don’t move.
• Versions are great. For my portfolio, we created small square thumbnails for each image. Versions make it easy to consolidate all the different changes and permutations for an image. If you set versions opened in external editors to be in PSD format, you can even saved layered images with Aperture. Of course, you can’t modify the RAW file after the fact, but at least you can have your projects files consolidated into one place.
• Lift and Stamp. There are times when I want to lift and stamp certain adjustments made to an image. For example, noise reduction but not white balance or exposure. It does not appear that you can uncheck individual entries under adjustments. I expect this to be fixed in the next point release for Aperture. Update: Looks like you are able to do this in Aperture. See the comments by Kev below.
• Adjustment sliders. I find that the adjustment sliders are really easy to adjust in fine increments. This might sound good for the marketing people (high-precision float architecture), but in practice it’s a little cumbersome. I typically want to adjust exposure in tenths of a stop. Having jump-to spots in half stop increments for the sliders would be very useful.
• Aperture also has a non-standard text field if you want to edit the value. When you hover the mouse over the field, the cursor changes to this strange insert text icon. Click and you can change the value. However, tabbing, which works in Camera RAW and Capture One switches panes and does not go to the next adjustment (i.e. Exposure to Saturation to Brightness). To adjust those values using the keyboard, you have to hover the mouse over the text field, click, and start typing. You have to be careful using the minus key, because that’s used to rate images; it’s easy to accidently mark an item as a reject and have it disappear from your workspace!
• The crop tool does not automatically check the contstrain proportions checkbox. You have to check it for each and every image. Since I typically maintain the 3:2 aspect ratio on my images, this is very time consuming.
• A possible way to span your Library across multiple disk volumes
• Dust and Patch tool need work. Unless the dust spot you’re removing is on a featureless background, it’s not very accurate. It’s takes a lot of fiddling with the settings to use the tool effectively. It might be easier to set everything the way you like it, open the image in Photoshop, and resave the processed version back into Aperture.
• Description of image Masters, Versions, and Aliases

At first glance, I think NoiseNinja will remain in my toolbox. The results from Aperture’s noise reduction tools are like butter knives compared to the razor-sharp blades that PictureCode’s software uses to carve up noise. Photoshop CS and CaptureOne all produce better results at noise reduction than Aperture.

There are two controls in Aperture, radius and edge detail, as shown below in the following screenshot.

The default settings are 0.10 for radius and 1.50 for edge detail. At 100%, frankly I don’t see much change in my images unless I start increasing the radius. There’s do not seem to be separate controls for managing luminance noise and color noise, as there are in the other RAW convertors and noise reduction applications. I do so much high ISO photography that reducing color noise is my number one task for NoiseNinja.

Compare this image above with what NoiseNinja produced from a CaptureOne RAW conversion.

And for a final comparison, Photoshop CS’s noise reduction abilities. I have never found Photoshop’s handling of high ISO noise and shadow noise to be all that good. Has anything changed in CS2 that might change this?

Disregard the white balance differences for a moment. You can see that NoiseNinja’s noise reduction abilities are superior to Aperture’s. I really hope that Apple adds a plug-in interface so third-parties can enhance Aperture’s capabilities. It’s beneficial for everyone in the long-run!

Here’s an example of NoiseNinja running on an Aperture processed image (made some color and contrasts adjustments as well) . Not bad! What is unforunate is that you can’t modify the resulting file using Aperture’s non-destructive editing tools. Final Cut Pro has good plug-in support… let’s hope Aperture will too in the next version!

I just created a category to hold all my Aperture-related thoughts. Keep your bookmarks and newsreaders point there for my latest news on Apple’s pro digital photography tool!

Some other resources:

• Aperture Discussion Forum at Apple

Aperture arrived today. Good thing my replacement 4GB RAM modules also arrived today from OWC.

The first thing that Rae and I did after installing the software was to watch the Aperture DVD Tutorial. This was a great introduction to the features and functionality of the program. Some of the material was lifted from the web tutorials on the Aperture web page, including the guy with the British accent! Alas, he did not pop up ala Microsoft Bob to highlight the features of Aperture during the DVD.

I am writing an AppleScript that transfers annotations from my iView catalogs into Aperture image versions. My file structure for my annotated RAW images has been well-documented, and it will make writing this script relatively straightforward — if anything in AppleScript can be straightforward! A tricky part was mapping iView’s annotation field names to Aperture’s. Fortunately, I found the IPTC Rosetta Stone. Since Aperture’s IPTC field names are identical to IPTC, it was a snap to map iView’s field names over. There were some strange mappings, like Event and People in iView to FixtureIdentifier and Contact in Aperture/IPTC!

To your right is a list of field mappings from iView to IPTC/Aperture:

Now, I would love to finish this script, but I’ve run into a significant roadblock. AppleScript throws an error when you try to edit an IPTC tag that does not yet exist in an image version in Aperture. I have the following check in my script:

if not (exists IPTC tag “Contact” of theImage) then

make new IPTC tag “Contact” at end of IPTC tags of theImage with properties {value: “Adam Tow”}

make new IPTC tag “Contact” at IPTC tags of theImage with properties {value: “Adam Tow”}

make new IPTC tag at end of IPTC tags of theImage with properties {name: “Contact”, value: “Adam Tow”}

end if

None of the three lines work, with lovely and familiar AppleScript errors like:

• Aperture got an error: Can’t make IPTC tag “Contact” into type type class.
• Aperture got an error: NSInternalScriptError
• Aperture got an error: NSContainerSpecifierError

I really hate playing AppleScript syntax gymnastics! How in the world do you add a new IPTC tag class object to the IPTC Tags property of an image version?!? There’s an Automator action called Set IPTC Tags which does exactly what I want it to do, but the clever folks at Apple made the script read-only. I can’t see how they deal with the case when the IPTC Tag is not already in the image file!

Are there any crack AppleScript gurus who can help me debug this situation?

It’s 4:21 am right now. When everyone in the US is asleep, people in Europe and Asia are awake to help me! Thanks to Paul Guyot, I’ve been able to track down the correct syntax to use. Looking at the dictionaries, script suites, and script terminologies for Aperture, we discovered that you need to tell the image itself to make a new IPTC tag entry!

tell theImage
make new IPTC tag with properties {name:”Contact”, value:”Adam Tow”}
end tell

AppleScript and Cocoa make it so hard and yet so easy sometimes!

iView2Aperture

Now the next problem is determining what is the currently selected album, image, project etc. There is a selection object available, but I can’t yet determine the properties. There does not appear to be any current or selected keyword in Aperture.

Workaround time. I created a root-level folder called iView2Aperture, in which I could place Projects, Folders, and Albums. My script, now and AppleScript Studio Application, performs the following task:

1. Iterate through every photo contained in the folder
2. Opens the appropriate iView catalog
3. Copies all annotations from the iView media item into the Aperture image version

The program does a complete replace of the data from iView to Aperture. There’s no synchronization going on.

My script relies heavily on the way I have organized my iView catalogs. As I wrote in my article on my photo workflow, I separate my iView MediaPro catalogs by Year-Month. The filename is the master key which stays the same between Aperture and iView. Based on the shooting date and time, the filename is parsed by AppleScript to determine the appropriate iView catalog to open. Once that’s done, it’s easy to copy the annotations from iView over to Aperture — as easy as AppleScript makes it, of course!

Click on the image above to see how all the annotations have been copied from iView to Aperture!

This is one of the ugliest apps I’ve ever written, but hey, what can you expect at 6:00 in the morning :) I’ll eventually get around to cleaning up the interface and releasing this to the world. One stumbling block for potential users is the way that I’ve hardcoded the way I organize my files into the application. The hardest part to generalize the program would be in finding the right iView catalog for each image in Aperture.

Treating RAW as RAW?

In general, I don’t sync my annotations to the original files using iView. I read that iView 3 handles annotations better than in previous versions of the application. All that said, it doesn’t seem to matter if the annotations have been written into the RAW file or not, because Aperture doesn’t read them!

Photoshop CS is able to read the IPTC annotations that I have added to the RAW file under File Info. Frankly, I’m surprised that Aperture doesn’t do the same. I guess they really just want to read the RAW data from the image and nothing else!

The way the program is set up, it really forces you to use their system to the exclusion of everyone else’s. For a variety of reasons that I will cover in a future article, I’m not ready to import all of my photos into Aperture. It’s my hope that more programs like iView2Aperture will be available to welcome Aperture into the digital toolbox of photographers.

Aperture Checker determines whether or not your computer has the necessary horsepower, RAM, and graphics ability to run Aperture.

On my 867MHz Quicksilver, it said:

Aperture cannot be installed on this computer.

• Aperture requires at least a 1.8 GHz Power Mac G5, a 1.8 GHz iMac G5, or a 1.25 GHz PowerBook G4.
• Your graphics card does not meet the minimum requirement for Aperture.

It’s too bad there are stiff system requirements. Since PowerBooks and iMacs have their graphics chip soldered onto the motherboard, they are out of luck unless they bought the most recent revisions. Many photographers like the 12-inch PowerBook since it’s more portable than its 15 and 17-inch siblings. Unfortunately, the NVIDIA GeForce FX Go5200 chip it uses isn’t on Aperture’s list of supported video cards.

I just launched the revision to my online portfolio. The layout has been refreshed and I updated — thanks to Paperture — the wedding photos. I also added our custom designed wedding invitations and consolidated the People/Portrait, Music/Performance, and Nature/Places sections. Besides the wedding images, everything dates back to 2003, so I have some updating to do! It takes a long time to go through 70,000+ images looking for those select few to highlight!

That said, it will certainly be easier to update the site on an ongoing basis. Using WordPress, a few plug-ins, and some custom templates, all I need to do now is upload the photos and thumbnails!

I have noticed a strange display bug with the thumbnails. I’m avoiding using HTML tables in the site, but at times the DIV’s around the thumbnails are not floating properly. Can any crack CSS gurus help me figure it out? Aligning things in XHTML/CSS can be such a pain at times!

There’s an article on Rob Galbraith’s that has more information about Aperture. Some key points:

• Aperture’s RAW converter is based on the Mac OS X RAW converter (see iPhoto)
• Aperture’s Library is really a Mac OS X Package
• One Aperture Library at a time
• Aperture is designed for a single user
• The Library cannot span multiple hard drives
• Files that you “import” into the Library are copied to the Library package
• Exporting a RAW image does not export metadata

My image collection is currently at 313GB on a 1TB NAS box running RAID 5. That’s a limitation that I hope will get worked around in the future. I figured that Aperture would let you store your original images wherever you wanted, instead of placing them into a duplicate and separate location, ala iPhoto.

Aperture is a 1.0 product, and some of these points make it very clear. I’m sure that they’re iron them out in a year and a half when Aperture 2.0 is released. Until then, it’s up to the early adopters to suffer the growing pains of being on the leading edge.

Update: PDN has another good article on Aperture.

Many people have come up to me asking about my photo workflow. I’ve given presentations on the subject at COBA meetings in the past and in informal emails, but here’s my first stab at it on the Web. With the upcoming release of Aperture and iView Media Pro 3, it’s possible that my workflow will change dramatically in the coming months.

My current workflow for managing my images can be broken down into 5 components:

1. Transfer
2. Rename
3. Annotate
4. Select
5. Process

Transfer

The first thing I do is copy the images from my memory card to my computer. Ideally, I would have this step automated, perhaps using Apple’s Image Capture. Sadly, I have had a number of bad experiences using IC to transfer images from memory card to computer. For the longest time, it seemed every new system software update from Apple “upgraded” Image Capture. The upgrade used to reset my finely tuned preferences for Image Capture. For instance, Image Capture lets you embed ColorSync profiles to your images during transfer. An older version of the software didn’t handle Canon EOS-1D RAW files properly; when embedding a color profile to the image, it stripped out all of the RAW image information! My preferences for Image Capture are not to do anything other than transfer the files. Later versions of Image Capture are better, but I still am wary about using that application.

So, long story short, I manually copy images to the “Inbox” folder on my ReadyNAS 600 box over Gigabit Ethernet.

Rename

I use ExifRenamer to rename my files to the format: YYYY-MM-DD_hh-mm-ss_WXYZ, where WXYZ is the four digit unique number assigned to the image by the camera. I add the unique identifier because I have multiple cameras and want to avoid any naming conflicts.

I then move the images into my photos filesystem, which is organized into Year, Year-Month, Year-Month-Day folders. I have written an AppleScript that moves images into the proper directories, creating new folders if necessary. This works great, except for the fact that the script sometimes crashes the Finder. No files are lost, but it is very annoying to have to wait for the Finder the relaunch and run the script again. I’ve tried witing an Automator script that does the same thing, but it runs unacceptably slow.

Annotate

I currently use iView Media Pro to catalog and annotate my images. I have found that iView doesn’t run very well with large catalogs, so I create Year-Month catalogs for all of my images. The largest image catalog contains something on the order of 4000 images, but most contain about 1000 images each.

After importing my newly added photos to the appropriate iView catalog, I begin annotating the images. iView supports IPTC, the industry standard for annotating images. First, I batch add default annotations to all of the images:

• Event Date
• Author
• Title
• Credit
• Copyright Notice
• Source
• Country
• State
• Writer

I then go through each image, filling in the following annotation fields:

• Event
• City
• Location
• People
• Keywords

iView lets you select multiple images and batch annotate. The most time consuming portion of this process is annotating the People section. I currently identify as many people as possible in each image. You can imagine how long it will take to type in everybody’s name! iView offers auto-complete text input in all of its fields, which helps to speed up things, but it can still be tedious and slow at times. I have modified an AppleScript that I found on a DPReview forum post that speeds up annotating people. While it doesn’t offer auto-complete and doens’t (yet) work with names that contain quotation marks, it seems like it’s faster than my current approach.

At the beginning of this year, I completed annotating nearly all of my 70,000+ image collection. It took over a year to finish, but the end result is worth it.

iView can search through multiple image catalogs for files matching a search criteria, but the process is very slow. To solve this problem, I exported all image information into a MySQL database. I then created a web application that could search through this database using a variety of search criteria. With Spotlight and Aperture, I think I’ll be using that application to conduct powerful searches through my image catalog. My hope is that I will be able to easily export and import my annotations from iView into Aperture.

Select

I now select the images that I wish to process or upload to the Internet. Using iView, I tag images using the 0-9 keys on the keyboard. Each tag is associated with a different color, so it makes identifying good and bad images easily. I’ll delete the obviously bad photos from the hard drive. I probably should be better about culling my photos, since I could easily recover several gigabytes of storage. That said, I guess I’m a packrat for my photos!

Process

I can now process the selected RAW images using Capture One, DPP, or Photoshop CS. If I’m lazy, I’ll just export web-sized images using iView itself. Most of my RAW images contain large JPEG’s used for previewing purposes. These JPEG’s are sufficient for web-posting, I have found.

For most of my photography projects, I use Capture One as my primary RAW convertor. Converting RAW images on a 4.5 year old Macintosh is not fun, and on Capture One the process can be very agonizing. I am eagerly awaiting the release of Aperture and the Quad G5 PowerMac.

I find that Capture One’s noise reduction algorithms to be pretty bad, so I use Noise Ninja
to handle all of my noise reduction needs. I will perform some light sharpening in Capture One, followed by some additional sharpening in Noise Ninja. My goal throughout the RAW conversion process is to avoid having to use Photoshop. Photoshop is powerful, indeed, but it is not well-suited for modifying multiple files at a time. This is another reason why I’m salivating at the thought of Aperture. That application could conceivably replace iView Media Pro, Capture One, Photoshop CS, and Noise Ninja all at once. I do wish that Apple has a plug-in interface so third-party applications can enhance Aperture’s image processing routines, should they be discovered to be inferior compared to other solutions (I’m thinking about noise reduction and Noise Ninja here).

Conclusion

So that’s my photo workflow! This workflow has been developed over the past several years, and it works for me. Your mileage may vary. If you have any questions, please use the comments form below.

Appendix

Links to the various software packages that I use for my photo workflow:

• iView Media Pro
• ExifRenamer
• Capture One
• Adobe Photoshop CS
• ReadyNAS 600 1TB Network Attached Storage Box
• Noise Ninja

iView Media Pro 3.0 was announced today. The timing of all these photo announcements is not strange, since the Photo Expo is going on this week in New York. Nevertheless, it’s always possible that they rushed their announcement following Aperture’s debut. Aside from the press release, there’s little additional information on the website detailing the refined user interface, the lightbox feature, etc.

The price of iView has been creeping up over the years. I seem to recall the price of the digital asset management application being under $100 when I first purchased it. Since then, the price has increased to its current $199 point. iView Media Pro does handle a whole range of media formats. It’s undetermined right now how Aperture deals, if at all, with video, text, or other medial files aside from TIFF, PSD, JPEG, or RAW.

I’ve used iView Media Pro to catalog and annotate my entire image collection of 70,000+ images. Despite that, I’m not wedding to using iView in the future. My current plan is to test out Aperture to see if it can replace iView and CaptureOne as my day-to-day image catalog and RAW processor. If that’s the case, we’ll be seeing an updated workflow post from me in the near future!

An article in MacCentral points to more details about Aperture. Some highlights include:

• By the way, there’s no Save command in Aperture. As you make changes, those changes are recorded in a SQL database.
• One note about the movement between the two apps: When you move to Photoshop, Aperture exports a version of the image with all of your current effects applied. If you reimport the Photoshop-edited file back into Aperture, it’s like starting from scratch. The program creates a new digital negative and works from there. You can’t jump back and change any Aperture settings you made before going Photoshop without also losing any of the changes you made in Photoshop. So you lose some of the benefit of the non-destructive editing every time you make the leap.
• It sounds as though Aperture will resemble its distant iPhoto cousin in at least one way: how you manage your files—or rather don’t manage them. Like iPhoto, Aperture organizes and tracks your files for you. I haven’t seen what the file system looks like at the back end (iPhoto annoyingly sorts its files by date). But Aperture’s interface appears to group files into projects that you define.

For the longest time, Apple has been neglecting the professional photography market segment, but no longer. Aperture is to digital photography what Final Cut Pro is to digital video.

It’s the biggest, most taxing job you have as a photographer. You’ve finished your shoot. You’ve taken thousands of photographs. Now you need to quickly edit the shoot, reviewing all of your photos and identifying your very best. Aperture helps you accomplish this with powerful and flexible tools designed specifically to address the needs of the professional photographer.

I am excited to see this application first-hand, as it appears to be tailored specifically for the working photographer. Features that I’m especially excited about include:

• Deep metadata support
• Preserves existing file structure of photos (unlike iPhoto)
• RAW processing using CoreImage
• Version control over Master and derivative images
• Automatic backup using Vault

Although I have a fairly well-thought out workflow for my photos, I struggle with the lack of coordination between the various apps that I’m using: iView Media Pro, CaptureOne, Noise Ninja, and Photoshop. Aperture looks like it can replace iView and CaptureOne, and I’m looking forward to seeing how it can integrate with Noise Ninja, my preferred noise reduction program. Checking the feature list, Aperture comes with a noise reduction tool, along with spot and patch healing tools. Perhaps Aperture can replace all of my image editing tools after all!

Eric Cheng and I were talking the other day about the difficulty in maintaining version control with our images. I annotate the RAW images, while Eric annotates the processed versions of his RAW files. Aperture maintains all derivative versions using a concept called Stacks. And, each new version apparently takes up no more additional storage space. Eric might want to Switch soon himself!

I’d venture to say that Aperture is more exciting than their new PowerMacs. Of couse, I’d need one of their new PowerMacs just to run Aperture at a reasonable speed! Looks like I’ll be upgrading soon.