I decided to revisit an old bug that I logged about a problem I have with f-spot handling of exif headers. Now I’m more confused than ever. I can see what’s happening, but not how or why.
The problem I’m having is that when I upload some photos to gallery websites the handling of exif data doesn’t appear consistent. For example, have a look at this photo. If you look at the right hand side of the screen where the photo title is shown it also shows the caption. It looks like this:

Now have a look at the same photo uploaded to picasaweb (the sizes are slightly different – I think picasaweb changed them on the fly when I uploaded via google plus). In this case there is no garbled text and picasaweb has used the exif description field for the photo caption. i.e:

So what’s happening here? Well, here’s what I think is happening. Picasaweb is extracting the caption from the exif field Description
, and Zenfolio is extracting the caption from the field UserComment
. Here’s what I get if I run exiftool on the image file (you might need to click on the image to see it properly):

As you can see the UserComment field contains garbled characters.
A lot of my photos have this and the inconsistencies can cause me headaches. I decided on a brute-force scan of my photo collection to address the issue. I thought, why not just duplicate the Description field into the UserComment field? That way, whatever package or gallery reads the image file will probably get the caption. So here’s the script I used:
#!/bin/bash
#
# Process all jpegs and overwrite UserComment field with Description
# field where they differ.
#
find /jpegs -type f -iname '*.jpg' | while read fname
do
field_usercomment=$(exiftool -UserComment "${fname}" | sed 's/^.*: //')
field_description=$(exiftool -Description "${fname}" | sed 's/^.*: //')
if [[ "${field_usercomment}" != "${field_description}" ]] ; then
echo "$fname"
echo "User Comment: ${field_usercomment}"
echo "Description: ${field_description}"
echo
echo "${fname}"
exiftool -overwrite_original -UserComment="${field_description}" "${fname}"
echo
fi
done
After a satisfying hour or two my photos all looked a bit tidier. So now I have a cludge – something that will get round the problem. But I’d really like to treat the cause, and not the symptom. So what’s the cause?
My first guess has always been the camera. I have a knackered old Nikon Coolpix that gives me problems. But I see this problem with other cameras too, my Canon DSLR and compact camera have acquired the garbled field in some pictures too.
So I turn to f-spot, the photo-management software I use in Linux Mint. I checked the exiftool output from a test file, then imported it into f-spot. I then added a tag so that f-spot would write out the exif data (I have f-spot configured to Store Tags and Description inside image files where possible) then had a look at the image file. Here’s what I got:

The output from the first invocation of exiftool is on the jpeg before importing into f-spot. The second example shows the output of exiftool run on the file after it has been imported into f-spot. It looks like f-spot does something to the image that mangles the UserComment
field.
At this point I assumed (erroneously I think) that f-spot must be storing the UserComment
and Description
fields in its sqlite database. Using sqlite3 on the command line I had a look at the structure of the photos table:
dougie@phoenix ~ $ echo '.schema photos' | sqlite3 .config/f-spot/photos.db
CREATE TABLE photos (
id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
time INTEGER NOT NULL,
base_uri STRING NOT NULL,
filename STRING NOT NULL,
description TEXT NOT NULL,
roll_id INTEGER NOT NULL,
default_version_id INTEGER NOT NULL,
rating INTEGER NULL
);
dougie@phoenix ~ $
There’s the description
field, but no UserComment
field. But it looks to me that f-spot is certainly writing to the UserComment
field when it updates an image file. Perhaps it’s dependent on the type of contents of the Description
field. It doesn’t, however, make any difference as far as I can tell what the contents of the Description
field are. In this example the text ends with an exclamation mark, but I can’t detect any pattern in the text I put in Description
fields that might provide a clue.
So if f-spot isn’t storing the UserComment
field directly what, when, and why is it writing to the field in the image file? It seems that here we enter the murky world of XMP and I rapidly lose the tenuous grasp I had on the underlying technology up to this point.
Back in 2008 there was a discussion on the f-spot mailing list about how f-spot stores its data in the image file. Re-reading that thread it sounds as if f-spot writes its tags to the XMP metadata and not all utilities are able to read that. This was 2008 mind, and f-spot has jumped a few versions since then.
Out of the same thread came a hint on using exiv2. This is a tool I use a lot, especially for adjusting ‘date taken’ timestamps, but hadn’t found it any use for extracting the UserComment
field. It turns out I hadn’t RTFM properly and it is possible if you tell exiv2 to look at XMP data. This leads to some interesting output. Here is the example file again, using both exiv2 and exiftool to examine the field contents:
dougie@phoenix ~ $
dougie@phoenix ~ $ exiftool -UserComment -Description /jpegs/2011/07/17/test1.jpg
User Comment : 桷⁹畲污湯桴敢捡桷湥礠畯挠湡挠瑵琠敨挠牯敮ⅲ††††††††††††
Description : why run along the beach when you can cut the corner!
dougie@phoenix ~ $
dougie@phoenix ~ $ exiv2 -p a /jpegs/2011/07/17/test1.jpg
Exif.Image.ImageDescription Ascii 77 why run along the beach when you can cut the corner!
Exif.Image.Software Ascii 21 f-spot version 0.8.0
Exif.Image.ExifTag Long 1 162
Exif.Photo.DateTimeOriginal Ascii 20 2011:07:17 09:37:13
Exif.Photo.UserComment Undefined 84 why run along the beach when you can cut the corner!
Exif.Image.GPSTag Long 1 296
Exif.GPSInfo.GPSVersionID Byte 4 2.0.0.0
Exif.GPSInfo.GPSLatitudeRef Ascii 2 North
Exif.GPSInfo.GPSLatitude Rational 3 55deg 32' 25.410"
Exif.GPSInfo.GPSLongitudeRef Ascii 2 West
Exif.GPSInfo.GPSLongitude Rational 3 1deg 37' 58.960"
Exif.GPSInfo.GPSAltitudeRef Byte 1 Above sea level
Exif.GPSInfo.GPSAltitude Rational 1 9.5 m
Exif.GPSInfo.GPSTimeStamp SRational 3 09:37:13
Exif.GPSInfo.GPSMapDatum Ascii 7 WGS-84
Exif.GPSInfo.GPSDateStamp Ascii 11 2011:07:17
Xmp.xmp.CreateDate XmpText 19 17/07/2011 09:37:13
Xmp.xmp.Rating XmpText 1 0
Xmp.xmp.CreatorTool XmpText 20 f-spot version 0.8.0
Xmp.dc.description LangAlt 1 lang="x-default" why run along the beach when you can cut the corner!
Xmp.dc.subject XmpBag 2 Dougie Nisbet, Coastal Run - 2011
Xmp.exif.UserComment LangAlt 1 lang="x-default" why run along the beach when you can cut the corner!
dougie@phoenix ~ $
Interestingly, exiv2
is displaying the UserComment
data in clear text, in two places, which I’m guessing must be something to do with the different types of metadata – XMP and EXIF.
So does this mean this has nothing to do with f-spot at all? If exiv2 is able to read the text, perhaps it’s something to do with the utility used to examine the image file? If I have a look at the file using geeqie and open up the EXIF window geeqie
seems to understand the text too:

Perhaps this is an unrelated setting I need to have a look at. Language, Locale, who knows. The issue seems to crop up in different places so it may very well be unrelated to f-spot. For the time being I have a fairly straightforward work-around, I just need to remember to run a script to copy the description field into the UserComment
field for any images I update in f-spot. It’s a bit of a nuisance but fairly easy to automate, and a lot less time-consuming than trying to get to the bottom of the mystery!