Linux applications and their non-standard XMP sidecar naming convention

I finally got hands on the ISO xmp standards and what a bummer, they do not discuss storage of the xmp data, they even explicitly exclude it from their scope. Adobes specs part 3 that talks about storage of xmp only has the one paragraph you quoted above, but does not define the situation of multiple files with the same basename at all. So I am still wondering: If one were to conform with Adobe’s specs, how would one correctly deal with metadata from multiple files? Did I miss that somewhere?

Files can embed the XMP metadata inside them, like is already done for IPTC metadata, or create a sidecar. That’s how every program outside of the darktable / digiKam / Geeqie triumvirate does it (although there are bound to be exceptions I don’t know about I suppose).

Maybe some other developers privately think the standard is “stupid” too. Who knows? But it doesn’t matter because the standard exists and is widely adhered too, just like the TIFF standard exists and is widely adhered too. Incidentally the TIFF standard itself comes from Aldus / Adobe, as does PDF.

1 Like

Just because you can pick the hammer and smash your fingers with it, does not mean it is the smart thing to do. (see: exiftool/digikam breaking raw files by doing exactly what you are suggesting to do, embedding sidecars.)

1 Like

I know you can and should embed xmp data in the file, but there are circumstances where this is not possible (even if just due to implementation) or not preferable, e.g. for ease of transfer/backup. So simply saying this scenario should not happen is not a solution. Adobe’s specs agree with that: “It is occasionally appropriate to store metadata separately from the file it describes;”. So there must be some way to handle the situation of more than one file with the same basename, which I still haven’t read how to do at all, let alone in a standardized way. I don’t want to argue about better/worse, I would just like to know how to do it without using the extension at all.

IIRC there is the possibility to add the metadata of several files into one xmp. But I agree to the darktable/dikikam/whatever folks that think this is a stupid solution. It makes moving files around a mess, e.g. if you have shot raw+jpeg, have xmps with metadata for both, moving just the jpegs means you have to copy the xmp files and you have doubled the metadata in either folder. Plus, it is something you would not do at the end of a work day, since it is too complex. Having one or more metadata sidecars for every single file makes sense since moving files around becomes very simple. Another example would be sharing metadata files, e.g. here on pixls.us. If you want to share only one of your edits of a raw file, you would first have to “export” to a new xmp that contains only this single edit, given that such an export exists.

Ouch, just started using digikam and was worried about what helpful things it might do in the background.

Can someone expand on the usefulness of having files with the same basename with differing metadata? I’m interested in case I’m missing a good way of organising files. Personally so far I’d much prefer to capture all files with one xmp. I like Geeqies grouping feature and wish all software could treat files with the same basename as the same content in different containers.

I guess I’m sort of url:ified with my paths/filenames. A path basename should point to content, files with the same basename should have the same semantic content just stored in different formats for different media etc.

As I’ve mentioned before I’d prefer (I understand this is unlikely to happen) the xmp to contain only capture metadata and human readable metadata such as tagging, titles, captions, ratings etc. It becomes conceptually and presumably programming wise complicated when the raw software history becomes mixed in with the content metadata. The software parameters could be saved in .dt sidecars.

I also like Geeqies option to embed or sidecar the metadata depending on filetype. I really don’t want to embed in raw files but really wan’t to embed(content metadata) in all other files as they should be portable.

I tag caption, retag, recaption refine my metadata and it’s a bit frustrating as is.

For me, I’d use a tag or note field to state the intent of the file, a jpeg for web will be sRGB, a tiff I print at home will be adobeRBG, while printing from a lab will be something else according to their spec. If all files share the same xmp sidecar, denoting the differences becomes more difficult.

Almost all RAW file formats are proprietary. I never suggested that XMP metadata be stored in RAW files. I don’t think anyone has during this conversation – where did you get that idea from? I wouldn’t do that myself, just like I wouldn’t embed IPTC metadata in the RAW. That’s just dumb. That’s why there is the option for XMP sidecar files. However, XMP metadata can be stored in jpeg, tiff, and other standard formats, precisely because they are standards. It’s pretty simple really.

Like I say, follow your own star if you want – ignore whatever standards you think are beneath you. Just make sure to do the responsible thing and make it easy for your users to use their files outside of your projects. Please don’t leave it up to others to do so.

1 Like

digiKam devs turn that exiv2’s feature off when compiling the official appimage. And yeah, no one should modify RAW files

1 Like