On Tuesday, December 03, 2013 01:04:50 AM Tobias Ellinghaus wrote: > Am Montag, 2. Dezember 2013, 22:57:51 schrieb Simon Spannagel: > > I actually thought darktable would write into the same XMP file using its > > own name space. Therefore the two sets of information shouldn't interfere > > beside the things like rating that are stored in the common namespace. > > Basically you are right, darktable has its own XML namespace for things like > image editing settings. However, there are (as you pointed out) common > fields like rating, color labels, ... In theory these are interchangeable > between different applications, and digiKam is one of them. However, > darktable only writes to XMP files once the image was imported into its > database but never reads the sidecar in again.This is futile if an > external DAM tool has written its data to the XMP file in the meantime. > > This is something that we might tackle in the near future, I already had > expressed some ideas and have written some test code about reading file > modification timestamps. Maybe it will work out, maybe not. Only time will > tell.
This would be great! Wolfgang > > Until then I agree, it's not safe to mix applications and rely on the XMP > files. Unless it's guaranteed that the DAM tool doesn't write to the XMP > while darktable is running, if darktable is forced to read the XMP on each > start and that the external DAM tool reads the XMPs once they have changed, > too. One way to force darktable to read the XMP in on every start would be > to start it with the command line parameter "--library :memory:". That has > other drawbacks, but if you only want the RAW editor darktable offers then > this might be a way to become happy. > > > Correct me when I'm wrong - i haven't used another tool producing XMPs for > > years... > > Me neither. Everything I wrote is coming from theoretical thoughts and > knowing how darktable works. :) > > > However, if you don't like that either i fear there is no way to do that > > currently. The reason for this not being configurable/ changeable is > > mostly > > preventing users from screwing up their own data i guess. > > Ack. You can neither tell darktable to write XMP files somewhere else (and > this won't change ever) nor can you tell it to reimport sidecar files into > an existing database on startup. > > > Cheers, > > Simon > > Tobias > > [...] ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
