[Digikam-users] Transferring images with XMP sidecar files

[Jean-François Rabasse]

On Sun, 3 Feb 2013, Graham Dicker wrote:

> Following a hard disk failure I have installed OpenSuse 12.2 on
> a new hard drive. This comes with Digikam 2.6.0 and have restored
> from backup a bunch of images used with the Digikam version that
> came with Opensuse 12.1. These images have captions stored in the
> XMP sidecar files but the new Digikam does not display them.
> How do I tell Digikam to use the existing XMP files please?

Dear Graham,

Welcome to the club:-)
I've recently reinstalled my OpenSuse 12.1, shipped with Digikam
2.2, to OpenSuse 12.2, shipped with Digikam 2.6, and of course got
the same issue, previous 2.2 database isn't recognized and DK 2.6
rescans folders from scratch, thus loosing all metadata.

And, as Volker says :

On Sun, 3 Feb 2013, Volker Henn wrote:

> Dear Graham,
> seems to be a bug, doesn't work either on my PC with similar
> configuration.

Re-reading from sidecar files doesn't work. I don't know if this has
been fixed in recent DK versions, I don't know if it's a Digikam
related problem or a problem from the libexiv2 used by DK,
but metadata is lost anyway.

(BTW, we recently had a thread on this list, related to database
troubles and data/metadata integrity. And it's confirmed that this
is an important issue because user data saving (and metadata edition
costs hours of work) accross years, versions changes, etc.,
should be considered an important topic. My personal choice was
to keep metadata in images files, it's the only reliable way as for
today. When rescanning new collections, Digikam imports correctly
XMP data embedded in files.)

Back to your problem. If DK can't read back its sidecar files,
the solution could be to move metadata into the images files.
Phil Harvey's exiftool can do such things but it's not
straightforward at all. Here are some guidelines :

1. I assume you have a full backup of all your collections,
images files, sidecar files et al., just in case:-)

2. Select a test image and do a copy of the associated sidecar file,
say test.xmp

3. Exiftool can rebuild a XMP section from a XMP/RDF xpacket input,
but the sidecar files generated with Digikam (via the libexiv2) are
standard XML files, not xpacket.

4. Open the test.xmp with your favorite text editor. You should get
something like :
<?xml version="1.0" encoding="UTF-8"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
     <rdf:RDF
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
     <rdf:Description rdf:about=""
     xmlns:digiKam="http://www.digikam.org/ns/1.0/"
     xmlns:xmp="http://ns.adobe.com/xap/1.0/"...

5. Remove/delete the first line, <?xml version... etc

6. Replace by the following :
<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>

NB: replace *exactly*, you can copy/paste from this e-mail.

7. Go to the very end of you file (after the </x:xmpmeta> markup)
and add the following line :
<?xpacket end='w'?>

8. Save and quit the editor.

9. Supposing your image file (related to the sidecar file) is
IMAGE.JPG, run the following command line :
     exiftool '-xmp<=test.xmp' IMAGE.JPG

Warning: the quotes '...' are required to prevent the shell to
interpret the '<' symbol as a redirection. It's a redirection, yes,
but for exiftool not for bash.

10. You have now an image file with an embedded XMP metadata
section, containing all what was in your sidecar file. Restart
Digikam, select the image and, from the 'Edit caption/tags' folder,
at the bottom right, click on the 'More' menu and select "Read
metadata from file to database". Your caption should appear...


Sorry if all the above appears to be a dirty hack. I don't know
other ways to recover lost metadata. Of course, if you have
thousands of files, it's not considerable to do hand text editing
for images, one by one. If you have some skills at shell scripting,
writing a few lines script to do this is really simple, rebuild a
xpacket from the sidecar file and issue the exiftool command.
And, after tests, a script accepting one image/sidecar filename as
argument can be used to process all your collection with tools as
find :
     find /collection-base -iname \*.jpg -exec my-script {} \;
etc.
(If you're not script writer, feel free to contact me on my private
e-mail address, I could send you some stuff.)

Hope this (possibly) could help.
Regards,
Jean-François

PS: GIMP WARNING !!!
This is off topic, yes, but I'd like to warn all GIMP users,
occasionnaly or on a regular basis, that have a recent version of
The Gimp. (And OpenSuse 12.2 comes with a recent version, Gimp 2.8.0.)
Theses versions, 2.8.0 and newer 2.8.2 have a totally *broken* XMP
support.
(When I say totally, it's not once among many times, it's always.
The program can't even re-read what it wrote and starts with error
messages saying that the XMP section is corrupted.)

If you are DK users that refuse to write metadata into the files,
and use only sidecar files or nothing (just the database),
forget this warning.

If you save into the images files and you edit your image with Gimp
2.8+, your metadata will be LOST !

The conclusion : no conclusion:-(
My personal opinion id that NO images management software can be
trusted, wrt metadata, because metadata is not seen as an important
issue (compared to graphical and "seenable" features, special
effects, dozens of plugins, etc.)

My personal workaround : as I remain stuck to the « metadata in
files » idea, and as I like Gimp (and need it for some features I
use regularly, e.g. layers, that few edition software offer aside
Photoshop), I've just implemented a somewhat paranoïd strategy,
keeping backups of my XMP data. Again with exiftool :
     exiftool -fast2 -xmp -b the-imagefilename > the-xmpsave-file
And after Gimp edition (and metadata destruction) I can restore with
the proper command (as show above in item 9.).
In that case, the saved file is ready to be use, it's xpacket format,
not xml format.

Life isn't easy for metadata users... :-)