So, basically, the proposal here is to change darktable for one particular usecase (playraw)? Where it’s already easy enough to embed the xmp options in the jpeg…
And where the change has no benefit for the program itself or its function: producing an image from a raw file…
I can speak only for myself but I would find this more useful outside of the play raw use case.
I might export several differently edited jpegs and it would big QoL improvement if the xmp that was used to create that jpeg would be automatically available and easily recognisable.
Duplicate manager or copying xmp files over require manual work. JPEG as sidecar is the closest to optimal solution but would require additional (manual) steps if the metadata should be deleted, plus the disadvantages for the play raw use case mentioned earlier.
This would be semantically opaque and a source of confusion.
darktable reads an XMP with the same basename of an image file as “these are the edits to be applied to this file”.
In this case, the XMP would describe the edits that, applied to some other file, produced this file.
If you were to re-import the exported JPGs in darktable (and maybe other programs as well) they would find the XMP and read it as edits to be applied on top of the JPG.
I feel the use-cases you are describing are not super wide-spread and wouldn’t be too optimistic that you’ll find a dev willing to implement this.
But why not go at it with lua scripting? I think that should be possible. Maybe have some help from AI. Maybe make the whole thing a shortcut, set it to a key and bobs your uncle.
You can already easily export the jpg with darktable. I did not want to replicate that as you already have all the control in the export module. Just export the XMP and the RAW with the lua script into the same dir. If you want to initiate a play raw you need all three of them, if you just want to participate you can ignore the RAW.
I see what you mean but I don’t fully agree. This works fine in Rawtherapee with pp3 files. Only problem I see is with other programs that use xmp sidecars but those programs shouldn’t use Darktable processing metadata?
And the confusion could be solved by naming xmp sidecars with something like _export suffix, at least partially.
Other option would be to create new (unique) duplicates with every export but it comes with it’s own problems.
Well there’s at least few users voicing positive opinions here. But I agree that scripting is probably the way. I’ve somewhat familiar with lua but haven’t looked at Darktable scripting yet.
I am joining back into the conversation after a lot of back and forth, so forgive me if I am asking something that has already been answered.
Other than playraw stuff, the main usecase for this feature is just to be able to have copies of your xmp files next to the exported jpegs, in a location other than your raws right?
If so, would this mainly be for:
Record keeping (almost like external snapshots of edits)?
Sharing with others outside of playraw (like so that other people can see an example of what the xmp edit does, but without access to the raw)?
I think in the first case, I don’t know why you wouldn’t just use the xmp that sits next to the raw (all in one place).
In the second case, if you are not sharing the raw, then it makes very little sense to include the xmp. A more human-readable edit-capture file would be of more use (I am imagining a .md file that clearly lays out the parts of the edit that are not specific to the original raw image).
But on topic, never thought this would stirr up so much. I agree with a simple lua script doing the action. Even if it is just a copy of the XMP without name change
What @Masterpiga mentioned in his original message. XMP and image file should match, e.g. these edits (image.XMP) are meant for this photo (image.ext). With the export XMP this breaks, xmp is not meant for the exported jpeg.
Like I said I understand this logic and the possible confusion, but I also think there’s room for exception for this case.
I can try to share my reasoning. There’s two big reasons why I find this whole feature useful.
Automation. When I export I want to save the edits automatically so that I can reproduce my edits if necessary. XMP written next to exported file is not necessary for this but for me there’s additional advantages if it is.
Backtracking. If the edits are stored next to raw/original file, there needs to be some way to match the exported file to a specific edit, for example store path of the exported file with duplicate. In my opinion this is more complicated and breaks when exported file is moved. I use Digikam to manage my catalog and Digikam keeps sidecars automatically with the image files. With xmp alongside the exported file everything works even if the exported file is moved, Digikam keeps xmp with the image file and all I need to do is to locate the original file if necessary.
The question is, how do I preserve the edit, the recipe. I don’t use the jpeg to store the edit, I think that’s wrong. I don’t rely on the database for long-term security and I don’t bother to set up tags or ratings. I have date-based folders for my files, and when I’ve finished with a folder for the time being, I delete it all from DT. But I have the raw, a usefully named jpeg and a usefully named xmp in my folder, backed up.
If I just have the default xmp, I’ll try something down the line and then that’s my edit gone! Or I delete an image having not done a proper export - edit lost. The simple and obvious workflow to me is export when happy with it, with a meaningful name, and save a copy of the xmp with the same name. Choosing to have the additional xmp just seems obvious functionality to me. I appreciate others won’t need this facility.
When importing an image, darktable automatically checks if it is accompanied by a sidecar file. As well as looking for files named <basename>.<extension>.xmp and <basename>_<number>.<extension>.xmp (darktable’s XMP file naming formats) darktable also checks for the presence of a file in the form <basename>.xmp (the naming format for Lightroom’s XMP sidecar files). Files with the latter naming format will be read by darktable but will not be written to. Once the image has been imported, darktable will generate an additional XMP file using its own naming convention.
From documentation.
This! And especially the bolded part, and after that the xmp file should be automatically created.
But you can already embed the xmp in the jpg, so what’s the added value of having a separte file if the goal is “remember the edits that I used for this result”?
