How to deal with exif stuff in Coolpix images that f-spot doesn’t like

I have a battered and knackered old Nikon Coolpix S600 camera. The zoom no longer works and it can be quite cranky. It’s not surprising as it has a tough time. It often gets carried on fell races and road races in, er, ‘hostile’ conditions. Its compact size and ‘sports’ setting makes it handy for … Continue reading “How to deal with exif stuff in Coolpix images that f-spot doesn’t like”

I have a battered and knackered old Nikon Coolpix S600 camera. The zoom no longer works and it can be quite cranky. It’s not surprising as it has a tough time. It often gets carried on fell races and road races in, er, ‘hostile’ conditions. Its compact size and ‘sports’ setting makes it handy for firing and forgetting. I have a Canon compact that gets similar treatment but on the whole the Canon can’t take the punishment that the Nikon can.

The problem I have with the Nikon is that there seems to be issues with the exif data. Whether it’s the camera, the camera’s firmware, or the software I use on the PC to process images, I don’t know. The upshot is the same, though, I have problems writing exif data back to the jpegs from the photo management software f-spot.

I always start f-spot on the command line in debug mode and save the output to a file. This way I can get a better idea of what’s going on. i.e.

f-spot --debug 2>&1 | tee /home/dougie/f-spot.out

(there’s a wrapper script involved too that takes a backup of the old database first).

Once I have the images in f-spot I start applying tags. I have f-spot configured so that it writes tags to the image file itself as this gives me greater flexibility if I start copying photos around the place or into other packages. This setting is in f-spot under Edit / Preferences. i.e.

write image data to file

So now I have my photos and I’ve applied some tags to them. But if I have a look at the terminal session where I started f-spot, I can see there are problems. The messages will typically look something like this:

[4 Debug 21:39:15.516] open uri = file:///jpegs/2011/06/11/DSCN5936.JPG
[4 Debug 21:39:15.940] Invalid thumbnail, reloading: file:///jpegs/2011/06/11/DSCN5934.JPG
[4 Debug 21:39:15.942] open uri = file:///jpegs/2011/06/11/DSCN5934.JPG
[14 Debug 21:39:15.968] Syncing metadata to file (file:///jpegs/2011/06/11/DSCN5928.JPG)...
[14 Warn 21:39:15.970] Metadata of file file:///jpegs/2011/06/11/DSCN5928.JPG may be corrupt, refusing to write to it, falling back to XMP sidecar.
[4 Debug 21:39:16.359] Invalid thumbnail, reloading: file:///jpegs/2011/06/11/DSCN5931.JPG
[4 Debug 21:39:16.360] open uri = file:///jpegs/2011/06/11/DSCN5931.JPG
[14 Debug 21:39:16.569] Syncing metadata to file (file:///jpegs/2011/06/11/DSCN5924.JPG)...
[14 Warn 21:39:16.571] Metadata of file file:///jpegs/2011/06/11/DSCN5924.JPG may be corrupt, refusing to write to it, falling back to XMP sidecar.
[4 Debug 21:39:16.786] Invalid thumbnail, reloading: file:///jpegs/2011/06/11/DSCN5928.JPG
[4 Debug 21:39:16.787] open uri = file:///jpegs/2011/06/11/DSCN5928.JPG
[14 Debug 21:39:17.153] Syncing metadata to file (file:///jpegs/2011/06/11/DSCN5914.JPG)...
[14 Warn 21:39:17.154] Metadata of file file:///jpegs/2011/06/11/DSCN5914.JPG may be corrupt, refusing to write to it, falling back to XMP sidecar.

The problem for me is two-fold

  1. f-spot has a problem with the metadata in the jpeg.
  2. It’s creating extra .xmp files that I don’t want.

I’ve tried several avenues to resolve this and I thought the following would do the trick:

jhead -purejpg

This uses the Linux utility jhead to rewrite the image header with a standard one. Unfortunately the problem persists. So I took a more brutal approach. I used the linux utility exiftool to obliterate all meta data from the image.

At first I’d copy all the images from the memory card into a directory and then run exiftool on all the files there. i.e.

exiftool -all= *

(Note that syntax; there’s a space between the equal sign and asterix)

This is fine but unfortunately it pretty much destroys any useful or interesting extra information. Most I can live without, except the date and time that the photo was taken. It automatically inherits the file modification time instead.

The solution is to first read the jpegs into f-spot, then, while f-spot is still running, go to the directory where the images have been imported to, then run the exiftool command there. In my setup, I have f-spot configured to copy all imported jpegs to /jpegs where they are automatically arranged in directories according to date and time. So the procedure for me is as follows:

  1. Import jpegs into f-spot
  2. With f-spot running, change to destination directory where jpegs were imported to
  3. Run exiftool -all= *
  4. carry out tagging operations in f-spot

The advantage of this is that despite obliterating the meta data in the files using exiftool, f-spot still knows the data and times of these photos in its own database. So the next time you write to them with f-spot, by adding a tag for instance, they will get the date and time from f-spot. You lose pretty much everything else, which is a shame, but the date and time are what’s most important for me.

Typically what I tend to do is read all the photos from the memory card into a temporary folder, e.g. ~dougie/in, where I can carry out a quick pass using something like geeqie to delete any truly terrible photos. Then I import the photos into f-spot. Once that’s done I change to the destination directory where f-spot has copied the photos and run exifool. e.g.

dougie@phoenix /jpegs/2011/06/11 $ exiftool -all= *
60 image files updated
dougie@phoenix /jpegs/2011/06/11 $

Note the syntax for the exiftool command. That’s a space after the equal sign and before the asterix. It’s a powerful command so it’s best to check the man page first to ensure that you know what it’s going to do.