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.
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
- f-spot has a problem with the metadata in the jpeg.
- 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:
- Import jpegs into f-spot
- With f-spot running, change to destination directory where jpegs were imported to
- Run
exiftool -all= *
- 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.
If you don’t want to lose all the other information, you can use exiftool to copy the exif data to an xmp file, clear all exif-data and afterwards restore the exif data from the xmp file. This creates proper exifdata. Here is a simple shell script:
#!/bin/bash
for arg in $@
do
exiftool -Tagsfromfile “$arg” “$arg”.xmp
exiftool -overwrite_original_in_place -all= “$arg”
exiftool -overwrite_original_in_place -Tagsfromfile “$arg”.xmp “$arg”
rm “$arg”.xmp
done
Thanks Michael. That looks a useful script.