read/write XMP compatible with digiKam/darktable, e.g. "image.ext.xmp"

I'm new to RAW processing in general and I need to rework my image management workflow due to the speed and quality of viewing RAW files. One part is culling and FastRawViewer seems to be a good solution here.
I'm using digiKam/darktable on windows and I have a problem with FRV and XMP sidecar files. digiKam and darktable store XMP data preferably in a file named:
e.g. DSC_1723.NEF.xmp
digiKam will search for XMP files in order:
> image.ext.xmp
> image.xmp
and then will use the found file.
darktable on the other hand, will also read the "image.xmp" upon first import but then switches to "image.ext.xmp".
FRV seems to only read/write the "image.XMP" version of the sidecar file. So this will break the compatibility between the two set of programs. I can currently not open a folder that was already processed by digiKam/darktable without losing the grading, title and description.
Is there any way to change the behaviour in FPV to use "image.ext.XMP"?
Thanks a lot

P.S.: there is no search option in the forum. SO sorry, if this question was already answered.

XMP (including file naming scheme) is an ISO Standard (16684-1), so there is no room for flexibility. Yes, it could result into file naming conflict if you have, for example, filename.CR2 and filename.TIF in same folder and want to use sidecar files for both files. To specify exact extension, XMP uses special photoshop:SidecarForExtension tag. This is not perfect way, but prescribed by the standard.

Thus, digiKam breaks the (ISO) standard at least in file naming scheme.

Changing XMP naming scheme in FRV is not as easy as it looks because of lot of (complex) code that detects (possible) XMP naming conflicts and deals with it. It is very unlikely we'll do this change (to support standard break), sorry.

Hello lexa,
thank you for the answer. Even if it is frustrating from a users perspective, I accept your decision. It is your product and you decide what to implement and what not.
Beside from this, I don't buy the argument that the naming convention is a normative definition in the ISO standard, a definition that have to followed without room for flexibility. I think, it was a company decision (Adobe) to do it like this, and that slipped into the paper in a few words and is still common practice in the Adobe products. Since Adobe is ruling the digital photographic world, you can call it a quasi standard: "If it doesn't work in Adobe photoshop/lightroom, it is broken by design".
I searched the internet for "the" standardization of the naming scheme. I actually couldn't really find it. All I could find, is that Adobe is doing it like this. And that this is primarily a fight between the OpenSource and the closed source world:
At least digiKam seem to have an option for the "standard" way: ""
But I see some valid points for the darktable decisions.
Maybe, I take the chance to shortly present my use case:
I'm a hobby photographer, collecting my pictures from various cameras, mobiles and friends in folders sorted by "YYYY\YYMM-Event". I collect these images at various locations, on my laptop, from my desktop computer, from other people computers, via the cloud or mobile uploads or directly via a network share when I'm at home. I use my time for this esp. when offline. So I have various stages of my work at various places.
In the end my goal is to have all pictures together with their sidecar files at one central location and not to loose any pictures in this process. And I strongly follow "last modification" wins :-)
I was never an Adobe Lightroom user and for many reasons I found a very good alternative with darktable and digiKam. Only the speed of working through my RAW images is too slow for sorting, grading and culling.
All what is missing now, is a fast raw viewer that fits into this tooling, and FRV is perfect for this, except...
... that I'm not able to interchangeably use FRV, darktable and digiKam.
I don't care if darktable is right or wrong, I don't care if Adobe is right or wrong. I care about the little pieces of metadata I have added to the pictures. And this already has a very limited interoperatibility scope... regardless of the ISO specification.
So if you want to have a user vote, my vote goes for an option to allow for customizeable names for sidercar files. There are more options than Adobe out there.
Thanks for listening.

AFAIK, darktable uses own sidecar files, not XMP, right?

To my knowledge it is standard XMP with darktable extensions, see:
I just did some tests with an XMP generated in FRV -> darktable -> (remove additional image file extension from sidecar file) -> FRV -> (add iamge file extension to sidecar file) -> darktable.
Everytime I increased the rating and the change were reflected in the next step.

Thanks (looks like I've missed with RawTherapee).

We'll discuss this internally. It is possible (but not guaranteed) that we'll implement alternate XMP naming scheme in next intermediate update together w/ turning off XMP name conflict checks.

Hello lexa,
thank you for looking into this.

I too am a darktable user who would like to have this XMP name change completed.  It doesn't have to be the default, but a preference item that would change FRV's XMP writeout to filename.ext.xmp vs filename.xmp would be the missing component to include FRV in my standard workflow.

More flexible XMP naming is released in FastRawViewer 1.6, now in beta:

To change naming scheme use: Preferences - XMP - XMP naming scheme drop-down

Add new comment