[Digikam-users] Digikam XMP schema ?

[Jean-François Rabasse]

On Sun, 17 Feb 2013, jdd wrote:

>> Probably the good approach is to reorganize from outside Digikam, with
>> some metadata edition tools, then delete all tags in Digikam and
>> re-read metadata from all images. This guarantees the DB will reflect
>> the images content.
>
>
> there is an other way, remove the database entirely and build a new one.
>
> but this implies *all* the metadata are written to the image or the an xml 
> file

Yes :-)
Not all Digikam versions seem to read the sidecar files (mine, 2.6.0, 
doesn't). But it's possible to write metadata (sidecar files content) into
the image file, for Dk to read it.

This has been discussed here recently, cf. :

> Date: Sun, 3 Feb 2013 19:14:17 +0100
> From: Christoph Siedentop <christoph at siedentop.name>
> Subject: Re: [Digikam-users] Transferring images with XMP sidecar files
>
> In response to Jean-François. I also have a workflow on getting meta
> data from the xmp file into the image. I think it simpler.
>
> First, Digikam appends the name .xmp after the .jpg. We'll change
> that. Put the following in a file and run as a script:
>
> for f in *.jpg.xmp; do
>  mv "$f" "${f/.jpg/}"
> done
>
> Secondly, insert the data into the image:
> exiv2 insert -i X *
> So, this does insert (obviously), -i X means, use xmp. * means run on
> all images in the folder.



> write *all* the digikam image data to xml sidecar files, this being the 
> safest way to archive them (can you archive the database?)

I agree. Sidecar files are under a standard XML format and will remain
readable (or translatable) forever. Applications specific databases
formats have no guarantee to be usable in 10 or 20 years from now.
Another argument in favor of archiving metadata as XML files is to have
a protection against buggy applications that corrupt metadata.
(I mentionned some versions of The Gimp). So, sidecar files is both a
long lifetime archiving system and a security backup for images metadata.


> by the way, what is faster, sqllite (old database format) or mysql?

Probably not a software issue but an installation issue. Applications
using databases run faster when the DB server is on a separate machine
connected via a high speed network (Gigabit ethernet or IP on Infiniband)
because the CPU running the application is/are relaxed from the SLQ
request (heavy) processing.
But if your MySQL server runs on the same computer, the difference with
SQLlite will be small. (And in favor of SQLite because it features less
things, so does a lighter processing.)

Regards,
Jean-François