Your important metadata lives in two, maybe three, places in your file; which one are you seeing?
Which instance of the IPTC metadata does your favorite application prefer? Inquiring minds want to know.
Let’s step back for a moment for some background. Because all things that should be dead simple usually aren’t, the IPTC metadata – important information like the caption, your byline, and copyright notice – is stored in multiple places in your file.
First, there’s the old-school IPTC/IIM version of the basic info.
(Some people mistakenly think this is all there is to IPTC metadata. Actually, the IPTC specifies what kind of information is stored in its “properties”. Physically storing the data in the file is a separate pile of acronyms.)
Then there are the extended IPTC fields, which live elsewhere in the file, in the newer Adobe XMP format. Copies of the basic fields live in the XMP, too. One day, the IIM format will be phased out and everything will be more or less under one roof in XMP.
It’s up to your metadata authoring application to keep the two copies of IPTC data in sync between the two formats.
Then there’s something in Exif…
On top of that, there are a few “IPTC-ish” fields that can be found in the Exif data, as well. The Exif format stores mostly logging information from your camera, like the camera’s serial number, settings used to make a photo, and GPS coordinates. Modern, upscale, cameras can write your byline and copyright information to fields in Exif.
Generally, while anybody can write Exif information to a file, it’s cameras that do so.
The Exif fields that applications might write to are for copyright notices, the image creator’s name, and the “Image Description” – a caption, in other words. (And time corrections. We’ll ignore those.) Some applications can read your copyright information, for example, and copy it to the relevant IPTC field. Some can copy your IPTC Caption to the Image Description field in Exif. “Can” being the operative word here. Applications can keep all this data in sync if they feel like it. Or not.
For the most part, this synchronization “just works” and you see the metadata that you should see.
On the other hand, sometimes it doesn’t. Denise May Levenick talks about adding metadata to heirloom family photos in this post on her Family Curator blog. “Metadata is a ‘funny’ thing.” she writes, “It doesn’t always ‘stick’ so that it’s visible in other applications.”, Levenick is obviously a conscientious person. But she and her readers were tripped up by some less-than-competent applications that don’t sync their metadata properly. (Some of which are examined later in this post.) So beware! Hazards lie in wait for real-world users.
Synchronization is largely a one-way affair. The application prefers one or another location and reads the data from there. When it comes time to write data, the application simply writes what it has at hand to all the places it can. We should remember that, in most combinations, these programs all “work”, particularly if you stick to the ones I recommend and respect their limitations.
We should remember that, in most combinations, these programs all “work”, particularly if you stick to the ones I recommend and respect their limitations.
Some applications give you some say in the matter. Photo Mechanic, for example, lets you choose which data to prefer, XMP or IIM, and which platforms to write to. Many applications allow you to decide how metadata is to be handled when there is a choice between embedding the data in the file or writing it to an XMP sidecar file. But, generally, applications simply write new data over any out-of-sync data that may exist. I don’t know of any program that alerts you to mismatched data. (But you can see if you look, in XnView or ExifTool.)
You’ve probably not spent a lot of time thinking about this…
Because of all that, and perhaps because you have a life, you’ve probably never stopped to think about what’s up with the multiple copies of your data living in your files.
And it’s worth noting that despite all the inconsistencies, most of the programs you might use for metadata purposes manage somehow to “just work”.
But you’re you and I’m…
When I was writing about how WordPress treats captions, I did stop and wonder.
So, I fired up ExifTool, the wonderful command line program by Phil Harvey that allows you to do pretty much anything you want to a photo’s metadata. I made a file with different captions in each of the possible locations. Then, I made files that each had one or two of the possibilities empty. I could then read and attempt to edit these files in different programs to see which metadata format each preferred and which way they would fall back if their favorite didn’t exist.
Here’s what I found:
WordPress only looks for a caption and a headline. It prefers the IIM version of the IPTC Caption. If that’s absent, it falls back to the Exif Image Description. WordPress doesn’t understand XMP at all. WordPress doesn’t write to embedded metadata, so that doesn’t apply.
A little uncomfortable
Frankly, I’m not at all sure I’m comfortable with this business of relying on Exif data for any long-term purposes, especially since there’s no assurance that every application that has touched the photo makes a copy of its caption in that Exif field. It flies in the face of the concept of “single source of truth”, which is a bulwark of data integrity.
It’s bad enough that there are two copies of the actual IPTC data. But adding yet another player in the mix makes me kind of nervous. Yes, the apps (apart from a few outliers) I’ve tested don’t look to the Exif unless the data doesn’t exist in the normal places, so it’s only a fallback. But in twenty years of working with embedded metadata, I’ve never seen a single instance of an Exif Image Description coming to the rescue.
In the Metadata Working Group’s Guidelines there is considerable emphasis on the notion that some products may only have access to Exif data and it should be accommodated, and even preferred, if at all possible. What products they really had in mind, I Have no idea. Whatever product it was, I’ll bet one of the companies in the Working Group made it. (I wrote this paragraph before I had run the caption test on a second batch of applications. Now, I have a pretty good idea of who it was.)
Next, I looked at what happens when you choose ‘Get Info’ in the Mac’s file manager.
The Mac prefers IIM and falls back to Exif, just like WordPress. (I used OS X Yosemite. If this behavior has changed since, please let me know.) The Mac was not able to read XMP data.
Shockingly, in Photoshop, Adobe’s own metadata format is preferred last. Where there’s a choice, it will only look for XMP if neither IIM nor Exif is available. Go figure.
Photoshop: IIM > Exif > XMP. That finding was unsettling enough to me that I went back and checked. Three times. Yup, IIM > Exif > XMP. Photoshop wrote the test caption to all three platforms.
Reading the same XMP-vs-Exif file as Photoshop, Lightroom chose to read the XMP. So, Lightroom prefers IIM >XMP >Exif. Lightroom wrote to all three platforms.
See the Lightroom How-To here.
Behaved as Lightroom did: IIM > XMP > Exif. Bridge wrote to all three places.
The Adobe products were all able to read and write XMP data. I would hope so. Adobe developed the standard. And they display fields that only exist in XMP just fine. I’m still scratching my head about Photoshop’s behavior, though.
A break for some more background
I guess at this point, I guess I should mention that the Metadata Working Group Standard does actually advise developers to prefer Exif data where it and XMP both exist. There is a rationale offered for this behavior. However, I stand by my advice to webmasters that by the time an asset is ready to publish, the Exif data block is perfectly expendable and can be removed.
Another tidbit from the Working Group standard is that there is a checksum within the metadata that allows an application that feels like it (or conforms to the standard, to put it a bit more formally) to know whether the IPTC/IIM version of the basic IPTC data matches what’s stored in the XMP block. If it doesn’t match, the application is supposed to read the IIM data. If it does match, the application is supposed to read both the IIM and XMP and prefer the XMP version. (If the checksum doesn’t exist at all, the application is supposed to prefer the XMP. This bit seems inconsistent as all get out to me. (If anybody can explain it, please rescue me in the comments.)
The test files I used for this post obviously have mismatched IIM and XMP blocks. That means that the applications that prefer the IIM in my test may well present the XMP version of the data in the more normal case where the data in the two blocks do match. For our purposes, though, it doesn’t matter. If the information is the same, which version we see is irrelevant. (And do remember my guidance that publishers in today’s environment should leave both IIM and XMP data untouched.)
The standards – IPTC, Exif, XMP, and Metadata Working Group are all available here.
Back to the plot…
In its Info Panel, XnView reads and displays simultaneously all three versions of the caption on my test file.
In its metadata editor, it reads the only the XMP caption or the IIM one, whichever you have set the dialog to prefer. Go to the ‘Options” tab in the editor and select “XMP, update or create IPTC-IIM”, or “IPTC-IIM, update or create XMP”. DO NOT click the ‘Write’ button. Just click ‘Cancel’. When you reopen the editor (CMD/CTL+I) it will display whichever version of metadata you selected in the pulldown. In this dialog, XnView doesn’t read the Exif Image Description at all.
It writes to XMP and IIM (assuming you specified that it write to both in the Options tab), but remember it can’t write extended IPTC fields (which only live in XMP) at all.
That’s a bit confusing. But OK.
On its tooltips and slide mount labels, XnView will display either IIM or Exif, according to which variable you assign in Preferences >Browser, or Preferences>Thumbnail>Labels. XMP is not available as a variable.
That means that, if it matters to you, you can set a tooltip or slide mount label to display the IIM caption and the Exif one, and set the Edit IPTC-IIN/XMP dialog to prefer XMP. Then you’ll be able to quickly see if you have caption metadata out of sync. I don’t expect to use it much, but I saved a tooltip for this purpose.
See the XnView How-To here.
The superpower of metadata authoring programs allows considerable customization in its preferences. You can choose whether it prefers XMP over IIM, or vice versa. You have multiple options for RAW and other file types where sidecar files are applicable.
It always writes to XMP (whenever there’s an appropriate XMP field) and it allows you to choose whether or not to also write to IIM. And you should choose to do so!
Photo Mechanic does read from the Exif Copyright and Artist fields, but it doesn’t write to any Exif fields (at this time). Information in the semantically equivalent Exif fields will be written to the corresponding IPTC fields if the information is not changed in the PM interface. But information entered in Photo Mechanic won’t be written back to Exif fields. So, Photo Mechanic effects a one-way sync from Exif to IPTC.
The Photo Mechanic How-To is here.
Apple preview follows the lead of its operating system. It reads all of the basic IPTC fields. It prefers the IIM version of the caption and falls back to the Exif if the former isn’t present. Interestingly, it reads the Rights Usage terms Field, which lives in XMP, but it won’t read an XMP caption, even if the IIM and Exif are not present. (Cue the spooky music.) Preview doesn’t write metadata at all.
In Mac OS Sierra (10.12), Preview has gained the ability to read a useful subset of XMP fields. It still prefers IIM.
The world’s most annoying photo management program prefers IIM and falls back to Exif (like the Mac operating system’s Get Info function). In the caption test, it couldn’t read XMP at all. But it writes to all three formats. (By the way, if anyone knows how to delete or disable this program, please let me know. My efforts have all failed. It keeps coming back like a bad penny.)
By Mac OS Sierra, it appears that Photos has lost all metadata functionality except a limited grasp of Keywords. I can’t say I’m all broken up about that personally since I despise the program. But it really doesn’t seem like a good thing.
The Properties > Details tab in Windows 7 reads the Exif version of the caption and a small sampling of IPTC fields. It doesn’t read either IIM or XMP captions. I guess we found the reason for the Metadata Working Group’s fixation with Exif.
It turns out that Windows’ metadata behavior is more complicated – and flat-out bizarre – than I thought when I wrote this post.
Here’s the scoop: Windows 7 Properties dialog will display the IIM Caption in its “Title” field IF the IIM Object Name field is blank. If the IIM Object Name field has a value in it, then Windows displays the Object Name field’s contents in its “Title” field and will display the Exif caption (if it exists) in Windows’ “Subject” field. But if there’s no Exif caption, then “Subject” is left blank. If there’s an Exif caption, but no value in the IIM Object Name field, then Windows displays the Exif caption in BOTH its “Title” and “Subject” fields.
IIM Caption MIGHT appear in the “Title” field. Exif caption MIGHT appear in the “Subject” field and/or the “Title” field. And IIM Object Name MIGHT appear in either “Title” or “Subject”. Wow.
So, if metadata is written by an application (Photo Mechanic or XnView, for example) that doesn’t write to the three Exif fields that correspond to IPTC ones, Then Windows users will or won’t see the caption in their Properties dialog, according to whether there is or is not a value in the IIM Object Name field.
For the Creator and Copyright fields, the Windows Properties dialog prefers Exif and displays IIM if those fields have no values in the Exif.
If anyone knows a reason (or excuse) for this behavior, please speak up in the comments. Otherwise, I can only advise you not to trust metadata displayed in Windows. (Applications that run on Windows, like Photo Mechanic, or XnView, or members of the Adobe suite, can work just fine, of course.)
Windows appears to ignore XMP data altogether.
Worked the same way as Windows 7. The Properties dialog read the Exif Image Description, which it called “Subject”, but neither IIM nor XMP versions. The contents of the Object Name field appeared to be mapped to a “Title” field in the dialog.
Windows 10 Photos application
This worked the same way as the Properties dialog. Only the Exif version of the caption was revealed.
This means that IF you author your metadata in a product that writes the caption to the Exif Image Description field, it will be visible in the Windows 7 or 10 Properties dialog and Photos app. If you use something else – likely including many of the off-brand programs that are available only for Windows – you’re probably screwed.
This program features separate dialogs for Exif and IPTC/IIM metadata. IrfanView can read the IPTC/IIM caption in its pane and the Exif one in its. It can write to IIM only. It can neither read nor write to XMP.
If you use IrfanView, which is only available for Windows, this means that your captions won’t show up in the Windows ‘Properties’ dialog. And if you edit in IrfanView a caption that was originally written in a program that does copy the caption to the Exif Image Description (like the Adobe products, for example), you’ll end up with different captions in the Exif and IIM data. That’s not good. (XnView doesn’t sync Exif with IIM or XMP either, by the way.)
(On KDE, running on Fedora 25) – gThumb can only read metadata, and only a subset of the IPTC fields. In the caption test, it prefers IIM > XMP > Exif.
(5.4.0 on Fedora 25) – DigiKam is the open source world’s photo asset management application of choice. Think of it as a Lightroom without nondestructive editing. Its metadata capability is good enough to make it a practicable alternative. I use it to keep track of my own family pictures. DigiKam preferred XMP > Exif > IIM in the caption test. It writes to all three.
Linux users note that a Linux version of XnView is available, and is fully functional. But it’s not open source, if that’s a deal breaker for you.
What a bunch of chaos! We should remember that, in most combinations, these programs all “work”, particularly if you stick to the ones I recommend and respect their limitations. Looking under the hood may have been an exercise in frightening ourselves unnecessarily, like learning about an untreatable, but nonfatal, disease. On the other hand, maybe it’s better to know.
And I’ll have many blog post topics to write to try to pressure all those software developers to get their ducks in one row.
If you have an application that I didn’t try in my caption tests and you’d like to check it out, please drop me a line and I’ll send you some test files. As always, please let us know what you think in the comments.