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.
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)
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.
Just looking at my Digikam/darktable sidecars, I see the folowing namespaces being used:
- xmlns:MicrosoftPhoto=āhttp://ns.microsoft.com/photo/1.0/ā
- xmlns:acdsee=āhttp://ns.acdsee.com/iptc/1.0/ā
- xmlns:digiKam=āhttp://www.digikam.org/ns/1.0/ā
- xmlns:exif=āhttp://ns.adobe.com/exif/1.0/ā
- xmlns:mediapro=āhttp://ns.iview-multimedia.com/mediapro/1.0/ā
- xmlns:photoshop=āhttp://ns.adobe.com/photoshop/1.0/ā
- xmlns:tiff=āhttp://ns.adobe.com/tiff/1.0/ā
- xmlns:xmp=āhttp://ns.adobe.com/xap/1.0/ā
- xmlns:xmpMM=āhttp://ns.adobe.com/xap/1.0/mm/ā
- xmlns:darktable=āhttp://darktable.sf.net/ā
- xmlns:dc=āDCMI: DCMI Metadata Termsā
- xmlns:lr=āhttp://ns.adobe.com/lightroom/1.0/ā
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)
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.
Thanks Kirk, blunt is an understatement. I would call the answer arrogant!
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
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.
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.
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 :-/
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??
As a linux users, Iām not overly concerned what Photomechanic, Photoshop and similar decide to use as āstandardā 
(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).
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ā¦
THX ā¦sounds good in a perfect world. 
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.
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.
But there it was about official (ISO) standards. Here we are dealing with a apparently poorly worded document from a proprietary software company.
Also, I know about at least one other program (digikam) that uses the same convention as darktable, and for pretty much the same reason. The main thing is not so much to distinguish between file types, but between versions. If you stick to simple .xmp you cannot distinguish between different versions (think of a way to use such sidecars in e.g. the playraws).
Different versions have the same capture metadata and usually the same content. When it no longer has the same content (cropping people out) as the parent raw file it makes sense to rename it (append versioning to the file name).
The issue has no bearing what so ever on playraws because tagging and metadata has never (in my time on pixls) been a topic of playraws. It would make for a very boring playraw 
Again the issue of saving edits can be solved in lots of different ways. Itās just important that the xmp standard isnāt mangled to achieve it. Storing edits in xmp is at best a secondary function of the standard and one whoās utility is very limited.
xmp is part of the whole xml metadata initiative such as dublin core and xhtml (back in the day). Abusing it to make it fit some niche editor use case makes no sense.
The iso standard was written by Adobe and if I remember correctly Digikam and Geeqie optionally use the filename.ext.xmp pattern only to work with dt?