some questions about digikam metadata, DB and simultaneous use

[M. Fioretti]

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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

Hi Marco,

On Sat, 16 Feb 2013, 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?

It's correct for the images collections pathnames, albums/folders and
albumsroots. But tags are saved into images, or sidecar files, under
a XMP format specific to Digikam (plus a compatible Adobe Lightroom
export).

> 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?

Digikam uses the libexiv2 library for metadata handling. So, supported
files types are/should be the types supported by exiv2.
Depending on the file type, metadata can be read from file but not
always saved back to file.
You can find the complete info here (what is possible for which file
format) :
    http://dev.exiv2.org/wiki/exiv2/Supported_image_formats

> 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?

An application using a database has two modes of behaviour :
- a session mode, the application opens/locks the database at startup
and release upon exit.
- a transaction mode, the application opens/read or write data/closes
upon each DB access need.

In transaction mode, multiples occurences of application can run in the
same time, concurrent access control is provided by the DB engine, here
the Mysql daemon.
From what you describe, it looks like a session mode for Digikam.
But you can test easily by starting a DK session on one machine, then
starting on another machine and try to update something and see if you
get a read-only error or not.

>   If not, will Bad Things happen even if there is NO access to the same
>   records?

Should not. Concurrent access is one of the guts of a database management
system, and MySQL does, as do PostgreSQL, Oracle, etc.
(But SQLite3 doesn't, it's not a database manager, just a file manager
with a SQL like interface.)
A DB manager that can't accept concurrent access should be garbaged.

>   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.

Probably the best way is to make a copy (and backup) of some of your
images folders (and a backup of your DB, sqldump or so), and try to work
on two different folders from two sessions. You will check your workflow
and see if the results are what you expect.

Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[M. Fioretti]

On Sat, Feb 16, 2013 22:53:40 PM +0100, Jean-François Rabasse wrote:

Thanks Jean-Francois for your explanations. With respect to this:

> Probably the best way is to make a copy (and backup) of some of your
> images folders (and a backup of your DB, sqldump or so), and try to
> work on two different folders from two sessions. You will check your
> workflow and see if the results are what you expect.

yes, of course that's the best way. I **had** planned to do those very
tests myself next week when I'll have the time. The main reason of my
message was, since I couldn't do work on this anyway before a few
days, if at least in theory this stuff can work or not.

I will check myself tuesday or wednesday anyway. If, before that
moment, somebody tells me "no, this cannot work" or "it worked for me"
I'll have a reference to go on.

Marco
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[M. Fioretti]

On Sat, Feb 16, 2013 12:24:33 PM +0100, Marco Fioretti wrote:

>    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?).

still thinking to this, I realized that users may also want to have
**private** albums, not just the common one:

as far as picture storage is concerned, this is no problem:


chmod 700 user_1 /pictures/private_pics_of_user_1
chmod 700 user_2 /pictures/private_pics_of_user_2
chmod 770 user_1 /common_pics_of_user_1_and_user_2

where user_1 and user_2 both belong to the digikam_users_group

The problem, of course, is with the database.

I know how to set up digikam for the two users to point to the same
MySql database. The point is, is it possible to set that up that
database so that, when accessed as user 2, does not show anything
about private_pics_of_user_1 and vice versa?

TIA,
Marco
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Willem Ferguson]

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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[M. Fioretti]

Willem,

thanks for your answer. I must really leave in 30 seconds, but here's
one question to keep the discussion going, I'll read the whole message
again and send a more detailed reply later if needed.

On Mon, Feb 18, 2013 13:47:57 PM +0200, Willem Ferguson wrote:

> 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.

I know. My questions at this point are:

1) would it work with digiKam as is today, if the two users were
working side by sidem, that is aware of what they are doing, paying
close attention to NEVER touch the same folder, never mind picture, at
the same time? Yes, I'll test it myself anyway, but any feedback is
welcome

2) real question: the mysql database is one, but technically I could:

   a) set only one MYSQL user for it, and have both the two linux
   users use its name and password in their digikam/mysql
   configuration, or

   b) set TWO separate MySql users, one per Linux/digiKam user with
   full access to the same digikam mysql database,

with the current digiKam (say version 2.9 or later) would the two
cases above behave differently?

Thanks and Later,
Marco

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[M. Fioretti]

First of all, thanks again to the DK developers for the software, and
to the list members for all their answers to my previous messages on
the same general theme.

I know I am going at this in a somehow confused way, but discussions
here help me just to get rid of that confusion. Or closer to that
point, at least.

What I am looking at now is THE format in which to save the
photographs.

Last week, Jean-Francois answered as follows to a question of mine:

On Sat, Feb 16, 2013 22:53:40 PM +0100, Jean-François Rabasse wrote:

> Marco:
> >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?
>
> Digikam uses the libexiv2 library for metadata handling. So,
> supported files types are/should be the types supported by exiv2.
> ... the complete info here (what is possible for which file format):
> http://dev.exiv2.org/wiki/exiv2/Supported_image_formats

According to that page for exiv2, hence for digiKam, Jpg and PNG are
perfectly equivalent when it comes to both read and write any of the
three metadata formats. At the same time, the digiKam handbook
recommends PNG before JPG because, of course, only the first is
lossless.

Combining these two informations, what I understand is that:

- I should save all my pictures in PNG format, so I'll still have all
  the metadata read/write/export capabilities as if they were JPG, but
  I'll be able to edit metadata, geotag, remove red eyes, rotate or do
  any other image processing I forgot to do before converting to PNG,
  without degrading the pictures

- and the ONLY thing I'd lose is that a backup DVD of those pictures
  would not be readable by today's living-room DVD players, that only
  read jpg. So if Aunt Mary ever asks for a copy of the pictures to
  see on her TV, I'd have to make a second DVD with the jpg versions

Does all this make sense? Did I miss something?

TIA,
Marco

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Elle Stone]

If your original images are jpegs to begin with (they came from the
camera as jpegs or entered your image collection some other way as
jpegs), then as long as you don't modify the original jpeg in any way
(except for adding metadata if you trust digiKam to write metadata to
the image - some people don't, some people do), then there is no
reason to convert the image to png, as png will take up more storage
space. Of course if you don't mind the extra storage requirements,
then that's not a problem.

I mark all my original jpegs as read-only and never, ever modify them.
My originals are all marked "read-only", but I'm not sure if or to
what extent digiKam actually respects "read-only".

When I want to edit an original jpeg, then I save it as a png and edit
the png, but I don't delete the original jpeg. That way, if I totally
mess up the png, I can go back and start over with an untouched image.

Wrt your proposed workflow, I would suggest saving your original jpegs
as pngs before you start removing red eye, doing any rotations or
other image processing.

Unless you use digiKam's ability to remember all versions of an image?
I don't use that functionality, but perhaps that would allow you to go
back to the original, unedited jpeg, in which case I'm not sure what
the advantage of the increased png storage requirements would be.

Kind regards,
Elle

On 2/20/13, M. Fioretti <[hidden email]> wrote:

> First of all, thanks again to the DK developers for the software, and
> to the list members for all their answers to my previous messages on
> the same general theme.
>
> I know I am going at this in a somehow confused way, but discussions
> here help me just to get rid of that confusion. Or closer to that
> point, at least.
>
> What I am looking at now is THE format in which to save the
> photographs.
>
> Last week, Jean-Francois answered as follows to a question of mine:
>
> On Sat, Feb 16, 2013 22:53:40 PM +0100, Jean-François Rabasse wrote:
>
>> Marco:
>> >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?
>>
>> Digikam uses the libexiv2 library for metadata handling. So,
>> supported files types are/should be the types supported by exiv2.
>> ... the complete info here (what is possible for which file format):
>> http://dev.exiv2.org/wiki/exiv2/Supported_image_formats
>
> According to that page for exiv2, hence for digiKam, Jpg and PNG are
> perfectly equivalent when it comes to both read and write any of the
> three metadata formats. At the same time, the digiKam handbook
> recommends PNG before JPG because, of course, only the first is
> lossless.
>
> Combining these two informations, what I understand is that:
>
> - I should save all my pictures in PNG format, so I'll still have all
>   the metadata read/write/export capabilities as if they were JPG, but
>   I'll be able to edit metadata, geotag, remove red eyes, rotate or do
>   any other image processing I forgot to do before converting to PNG,
>   without degrading the pictures
>
> - and the ONLY thing I'd lose is that a backup DVD of those pictures
>   would not be readable by today's living-room DVD players, that only
>   read jpg. So if Aunt Mary ever asks for a copy of the pictures to
>   see on her TV, I'd have to make a second DVD with the jpg versions
>
> Does all this make sense? Did I miss something?
>
> TIA,
> Marco
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

--
http://ninedegreesbelow.com - articles on open source digital photography
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse]

Hi Marco,

On Wed, 20 Feb 2013, M. Fioretti wrote:

>> Digikam uses the libexiv2 library for metadata handling. So,
>> supported files types are/should be the types supported by exiv2.
>> ... the complete info here (what is possible for which file format):
>> http://dev.exiv2.org/wiki/exiv2/Supported_image_formats
>
> According to that page for exiv2, hence for digiKam, Jpg and PNG are
> perfectly equivalent when it comes to both read and write any of the
> three metadata formats. At the same time, the digiKam handbook
> recommends PNG before JPG because, of course, only the first is
> lossless.

There are two differents things.

The exiv2 page I mentionned relates to files formats that support
embedding metadata in the file itself. For some formats it's very
well implemented and trustable, for some other (specialy some RAW
formats) it's a bit more hazardous or experimental.
(From my point of view, concerning an original RAW file, experimental
means « Don't use ! » :-)

And this is different from discussing about which format to use for
images edition, JPEG, PNG, TIFF or other.
(Some users use as working format the native format of the image
editor. As for me, I'm a Gimp user and my intermediate working
format is Gimp .xcf)

> Combining these two informations, what I understand is that:
>
> - I should save all my pictures in PNG format, so I'll still have all
>  the metadata read/write/export capabilities as if they were JPG, but
>  I'll be able to edit metadata, geotag, remove red eyes, rotate or do
>  any other image processing I forgot to do before converting to PNG,
>  without degrading the pictures
>
> - and the ONLY thing I'd lose is that a backup DVD of those pictures
>  would not be readable by today's living-room DVD players, that only
>  read jpg. So if Aunt Mary ever asks for a copy of the pictures to
>  see on her TV, I'd have to make a second DVD with the jpg versions
>
> Does all this make sense? Did I miss something?

Perfectly right. Choose your storing/archiving images format on technical
considerations, PNG could be a good candidate.
And be prepared to produce copies of images, depending on the desired
usage. Desired usage will imply final format and also dimensions.

- If you want to put some images on web pages, with a 600 or 700 pixels
width, build JPEGs with that size. Uploading to a web hoster PNG images
with 4500 or more pixels width will just waste storage space and bandwith.
And the visitor of your pages will see a 600 pixel width image :-)

- If you want to give a CD to Aunt Mary, God bless her, generate JPEGs
with some width between 1200 and 1600 pixels, enough for a TV screen.

- If you want to order paper prints, say in 4x5" format, and your print
service works in 300 dpi mode, the width in 5" will be 1500 pixels.
Multiply by two if you want to respect Shannon's sampling theorem and
upload to your print service images with 3000 pixels max. You won't
see any the difference on your paper prints.

The conclusion : keep your archives at best quality, keep your original
files (I 100% agree with what Elle Stone said), and rebuild images on
demand for each usage.
Programs such as ImageMagick convert can do that automatically, e.g. :
  convert Original.png -resize '1280x1280>' -quality 95 AuntMary.jpg

Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users