[Digikam-users] some questions about digikam metadata, DB and simultaneous use

Willem Ferguson willemferguson at zoology.up.ac.za
Mon Feb 18 11:47:57 GMT 2013

Marco, I have not followed the discussion on this topic, but in general 
the answer is not very positive.

One needs to provide for the possibility that two people cannot edit the 
same picture at the same moment. In order to deal with simultaneous 
access, some sophisticated software is required an I am not sure whether 
this is high on the Digikam agenda at the moment. I know of no 
photographic editing software that allows this at present. In general, 
when a database is used by a user, it is locked for other users. This is 
very important to avoid corruption of the data in the database. The 
changes that are required for simultaneous access are not trivial, 
especially with a complex program such as Digikam, because the dangers 
of corruption of the folders and images are so immense. It is much 
better to be careful and safe than to lose information because you 
edited data in opposition to another user accessing the same files at 
the same time. So the fast solution is, let your wife do her editing 
after you have completed yours.

Normally, not all data can be sived in the EXIF block inside an image. 
The EXIF spec makes provision only for certain types of information to 
be saved. Additional informaion, outside of EXIF data, are normally 
stored in sidecar files in XMP or similar format. Departing from the 
EXIF standard and including other data within the image will make it 
impossible for photographic software to read the EXIF data from your 
images. In Linux, look at the program exiv2 to see what is possible 
within the EXIF spec.

Kind regards,
Willem Ferguson

On 16/02/2013 13:24, M. Fioretti wrote:
> Hi,
> I have a few interrelated questions on these topics. The connection
> among them is how to use digikam as a grou├Ęp, that is 2 or more people
> that want to build, manage, tag, rate, comment, geotag... the same set
> of pictures collaboratively.
> 1) what parts, exactly, of the digikam database can NOT be saved into
>     the pictures? I tried to search online a database description,
>     without success but the google cache version of
>     http://fossies.org/linux/misc/digikam-2.9.0.tar.gz:a/digikam-2.9.0/core/project/documents/DBSCHEMA.ODS
>     from that table, I understand that "only" the album, albumroots and
>     tag trees table remain (rightly) outside the pictures. Is this
>     correct?
> 2) wrt to metadata saved inside pictures, I have the feeling I read
>     somewhere that digikam can save in XMP, ITPC and EXIF format, but
>     only to jpg and tiff files. Am I wrong?
> 3) I have not clear, when it comes to the CURRENT versions of digikam,
>     what the situation is when it comes to simultaneous use of the same
>     digikam album/database. More exactly:
>     user A and user B have two Linux computers, with the same version
>     of digikam, on the same LAN. The pictures are on a NFS shared
>     folder, say /pictures, and their two copies of digikam both point
>     to the same database (which with such a setup could ONLY be mysql,
>     right?). Is it still true, as I read in the archives of this list,
>     that if both A and B have digikam open simultaneously, only the
>     user who started it first will have write access to the database?
>     If not, will Bad Things happen even if there is NO access to the same
>     records?
>     Basically, I want to know if there's any way for me and my wife to
>     sit down together, each with a laptop, fire up digikam on the two
>     laptops, and say "OK, now I tag this month's pictures, you tag the
>     previous month, then each of us also saves all the metadata he
>     generated to the corresponding picture files", on the SAME set of
>     pictures, and the SAME database.
> TIA,
> Marco
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users

More information about the Digikam-users mailing list