Around the time of Vista’s release, a somewhat overexcited blog post by the tech journalist Ed Bott proclaimed the first of the then-new OS’ three ‘killer features’ was its read/write support for XMP metadata in JPEG and TIFF files. Given I want the writing side of my Exif code to work nicely with recent versions of Windows Explorer, I’ve been investigating what the latter’s shiny tagging UI actually does — and to be frank, I don’t find it especially pretty, even if it’s nowhere near as bad as what MS is capable of (the OLE document storage format anyone…?)
The first discovery was that Explorer (and indeed Windows Photo Gallery in both standard and ‘Live’ forms) always writes XMP data, even if none existed before whilst an Exif segment (including the particular tag you are editing) had. Any Exif editor that is Vista/Windows 7 friendly, then, needs to deal with XMP, if only ‘destructively’ in the sense that any existing XMP segment is removed so as not to cause data inconsistencies.
So, what of the XMP format itself? Well, in short, this is an XML-based affair, which immediately baits my general dislike of XML in all its textual and verbose yet typically human unreadable ‘glory’. This dislike is then quickly aggravated by how XMP itself has the primary aim of simply duplicating metadata found elsewhere: specifically, each type of pre-XMP metadata that XMP ‘supports’ has its own XMP schema; when writing XMP, the idea is to then copy (not replace!) the data from the ‘legacy’ format (be it Exif or whatever) into its own XMP section.
The rationale of this is that it allows apps unaware of XMP metadata to still read the ‘legacy’ format whilst apps drunk on the Adobe kool aid can ‘just’ read the XMP. There is, however, a slight flaw in this reasoning, since given each ‘legacy’ format has its own schema, you still need to know what the specific section and tag names are for each particular format. ‘Ah’, the XMP defender might say, ‘but you don’t have to write your own parser, since you can just use your usual XML parser of choice!’ While there is some truth in this, tag data formats — notwithstanding their all being string values of some sort — are still liable to be schema-specific, so you don’t gain that much. Moreover, writing a parser for a reasonably simple binary format like Exif isn’t that hard really…
That said, any deficiencies XMP has cannot be laid at MS’s door, since the format was created (and is still controlled) by Adobe. What do MS add to the mix then? Aside from both incompleteness (GPS Exif sections, I have found, do not have their data copied across to the XMP segment) and a certain general sloppiness in implementation, the thought that XMP isn’t wasteful enough, since the end of the XMP segment Explorer writes out is padded with a decent paragraph’s worth of space characters. Compounding this, the Exif segment itself then gains two tags of 2024 bytes each that ends with 2020 nulls — this is testing with a blank JPEG that I then set its comment to ‘This is a test’ in Windows Explorer. To top it all, these extraneous bytes have apparently been patented! Sure, even added together, all these superfluous bytes amount to not very much compared to the total size of a typical JPEG’ed photograph — but why write them at all? I guess the idea was to allow for tag expansion without mucking up MakerNote offsets, yet this is rather undermined but how padding is not just added to JPEG files that didn’t have any metadata before the Explorer or Photo Gallery UI got its fingerprints on them, but any JPEG file that happens to have even a single tag edited. The rationale that all the extra padding lessens the chance of data corruption is thus invalid, since adding the padding in the first place does itself potentially cause data corruption!