Bugs, Bugs, Bugs!

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!