Exchanging tags between Photomechanic and Darktable

Software darktable
18

Sorry, but collections in digikam correspond to directory trees. You’ll still need keywords to create a virtual collection

As I rarely change keywords in darktable, I don’t know about that. I do know that adding tags to an image that has none in darktable carries over to digikam.
This might have something to do with the order in which digikam processes the keyword XMP tags, combined with the XMP tags darktable uses to store keywords. That order in digikam can be changed.

Color labels won’t sync, as the way they are used is fundamentally different between digikam and darktable:
in digikam you can assign only one color label to an image, in darktable you can assign as many as you want to one image (within the choices provided of course).
Star ratings work similarly between the two programs, so they can be synchronised.

And yes, integration is difficult. That is because you deal with two programs developed by different teams, where interoperation with other programs was not the first priority. That said, both have made efforts to play nice with other FOSS programs, less so with commercial programs.
And there are some areas where interoperability is illusionary: there’s no way one program can take the editing instructions from another program without copying the algorithms used by that other program (of course, there are some exceptions, like cropping).

19

Yes, I realise there are problems but tags are supposed to be standardised are they?
I don’t think I’ll be using digikam, seems more trouble than it is worth…

20

keyword “supposed”…
If I look at my XMP files, I see five tags dealing with keywords, only one of which is in the digikam namespace…
(and three tags for the caption as well)

21

Some are standard, but many are not. XMP is the eXtendable Metadata Platform. So darktable has its own namespace in the XMP, as does digiKam, lightroom, etc etc.

22

Does any software write metadata to software specific namespaces? Not talking about edits of course as they are of no interest for exchange between software.

Iptc, xmp and exif metadata are pretty well standardized are they not? (Makertags ignored)

23

Not that I’m aware of. The issue is that application specific metadata often don’t have UIs that are compatible between applications. Color Labels and keywords are good examples of that.

Probably not that hard to write a script that would sync app specific metadata, but the script would likely be specific to your workflow.

24

Just looking at my Digikam/darktable sidecars, I see the folowing namespaces being used:

Unless you mean something else, looks to me there are 8 or 9 software-specific namespaces in there…
Most are used for storing versions of title, caption or keywords.

But as @paperdigits said, XMP is extendable. The extension is done through namespaces, with a namespace definition of the form xmlns:<name>="<URI>". The URI’s aren’t looked up by the parser, they are just there to create a unique name.

Those sidecars are xml files btw, so XSLT would be a possible way to transform the sidecars. And if you are careful, the resulting sidecar would be usable by others (unknown tags are supposed to be ignored, and not treated as an error)

25

Nicolas, I have almost identical interests to yourself on this topic. I posted a new Support Ticket on the Camera Bits webs-site this morning, only to immediately learn that you used the correct mechanism ("Feature Request’) yesterday. I saw Kirk’s reply, which I consider to be too blunt and have told him so. I would be grateful if you would inform me of any ‘work-arounds’ which become known to you which are not referenced on this forum.

26

Thanks Kirk, blunt is an understatement. I would call the answer arrogant!

27

Funny I should end up here in this thread.

I went looking for DT<->PM integration info on the PM site and stumbled across the thread you mentioned above, now, almost a year later. I ended up engaging with Dennis, the founder/president of Camerabits. He actually seems inclined to try and support the filename.ext.xmp naming convention as an option, but I’m not holding my breath.

Kirk replied to me in a somewhat less arrogant manner, perhaps he was just having a bad day last year.

At any rate, the easiest work-around I’ve come up with for dealing with the incompatible naming convention when using PM is to simply create symlinks to all the XMP files created by PM. I have yet to try it, so I don’t know if it’s a real solution yet or not.

Anyway, just thought I’d drop my update here.

–
Paul

2 Likes
28

Here’s the thread if anyone is curious: Exchanging with darktable

29

Ah so someone actually found it spelled out in the spec that xmp should replace the original extension. It was always obvious, if not from the existing implementations, but literal minded people on this board insisted that it was unclear. (As if it matters what the spec says when the world has settled on a de facto standard).

I doubt dt will change though.

30

dt won’t change. PhotoMechanic is considering it, as written in the post above.

Not sure where you’re getting this from. People here said the spec was a bad decision in this regard.

31

It is spelled out, but buried in a completely non-intuitive place in the “spec”. The first location where the file name convention is discussed (which is where it should be spelled out) is incredibly ambiguous, leaving it up to the reader what is meant by “filename”.

I wouldn’t go so far as to say “literal minded people” thought it was unclear. In a filesystem, every file must have a unique name. The canonical path to the unique file being itself unique, such that:

  • /path/to/some/file.ext

is unique and different than:

  • /path/to/other/file.ext

despite both files being named “file.ext”. Within a particular directory path, however, one can not have two “file.ext”, therefore, saying “the filename with an extension of .xmp” is ambiguous if you have both “file.ext1” and “file.ext2”. As many here have pointed out, if you have to files with the same name but in different formats, this scenario is a possibility. However, the argument that those two files consist of one RAW and one JPG is invalid, since JPEGs store XMP data internal to the image file itself whereas RAWs do not.

A more convincing argument would be what if I had both IMG_1234.CR2 and IMG_1234.NEF. The probability is small, but not zero.

It would make perfect sense on the part of (all) application developers dealing with XMP data and reading/writing XMP data to provide a user configurable file name format option with a reasonable default.

Most applications would likely default to .xmp, but could provide the option letting the user set it to ..xmp. And if DT wants to be the odd-ball in the industry because DT knows better than everyone else, they could default to the latter, but appease those who care by allowing them to change it to the former.

If PM comes through and supports this request, but DT remains obstinate, I will think far more highly of PM as a result. One thing I’ve learned in my 30+ years involvement with the open source world is that they can at times be incredibly arrogant and stubborn, since they have no paying customers to make happy. Say what you will about proprietary software, but they will usually give the customer what they ask for if there’s money to be made by doing it.

IMO, there is no reason NOT to support the standard, even if you think it’s a stupid standard. Support the existing standard, at least with configurable options, and then show the rest of the world the better way by defaulting to what you think is right.

–
Paul - Not really holding his breath for either side to give in on this :-/

32

I’m curious would this not have been done so that if someone read in a folder with nice LR or other software generated xmp files that they could then not somehow get overwritten/corrupted by DT if it also used xmp files… I have never owned lightroom so I have no idea how much of an issue this might be… is that much that is useful that you can get from LR or other xmp … I guess maybe the tags and ratings will flow into DT without too much of a problem…

Is the problem that DT might as well have used a totally different identifier but since they used xmp it should be done as other software has decided to do it??

33

As a linux users, I’m not overly concerned what Photomechanic, Photoshop and similar decide to use as “standard” :stuck_out_tongue: (the cited programs don’t exist in a Linux version so far).

Because there’s another issue: many of the “commercial” players aren’t interested in providing for Linux (that includes drivers for hardware), where they do provide for MacOS (which has/had a similar part of the “official” desktop installations).

34

A program doesn’t have to understand all the tags in an XMP (XML) file; as long as it doesn’t modify the ones it doesn’t understand, everything is fine. The XML standards actually provide for that situation, as the aim of XML is data exchange between programs…

35

THX …sounds good in a perfect world. :blush:

36

As far as I know dt is the only imperfection in this xmp world.

Do note that reading edits from other software is of no interest. It’s the medadata such as tags that should work across software.

37

For years it was proprietary software that refused to follow standards and made spurious exceptions to ensure lock in. Can’t see how following those same footsteps is a dignified revenge.