Maybe not everyone wants to use the jpeg that way, I don’t. People went to a lot of trouble coming up with a compressed standard, so why bloat it out, which can be a significant amount if you have drawn masks. If you distribute the jpeg, you’re forcing people to have extra data they don’t need. Imagine the fuss here if some major camera brand was putting extra stuff in the raw files for their own purposes which was no use to us! Future software doing smart things with our edits might work better with small xmps rather than image files. What if you export to a big tiff for further processing, where is your edit then? If you send someone a present, do you enclose a map showing the route you took to the shop where you bought the present?!
Most camera brands put extra stuff in the raw files.
Hello, I don’t understand why this request is generating so much resistance. I don’t think it’s a coding issue.
I understand that there are workarounds to satisfy the need as using exported jpeg or duplicates or manual management of xmp.
I don’t like sidecars because, by definition, they’re stored in the same folder as the raw file. I prefer databases. Nevertheless, I’d like to be able to generate XMP files on demand.
If I need to send JPGs to a printer (on line), I might want to anonymize my JPGs while keeping track of my processing and my cropping.
Yes, I can also manage that perfectly well with SQL exports of the database.
Why not, writing a partial backup SQL query is not so difficult (ask google has become IA can help).
Because this is a typical use case for (LUA) scripting, as has been mentioned several times.
To further elaborate. If you read the thread, you will see that there are many different yet similar requests overlapping. Someone wants to use it to store edits. Someone for PlayRaw. Someone wants only the JPG and the XMP. Someone wants also the Raw. Someone wants them named in a certain way, someone in a different one.
Implementing this in darktable proper would mean either (1) choosing one code path and making 90% of the readers of this thread unhappy, or (2) implementing all code paths, which is a lot of code AND a lot of options. (And then more requests will come - more resolutions, multiple copies, w/ or w/o overwrite… more code paths, yay!)
Also, even just one code path would add some bloat to the UI (there must be a button somewhere) for something that serves a very niche use case.
That’s exactly why Lua is a better solution. Everybody can take a Lua script, change it a little bit and make it suit their own needs. This feature does not require access to any of the native C code, all the required hooks are already implemented in Lua, so there is no need to bloat darktable’s codebase to implement it.
The script that I posted above (and repost here for convenience) is a very good starting point.
copy_raw_xmp.lua.zip (1.8 KB)
Not a programmer? Not a problem! Copy paste the Lua script into ANY LLM and ask it to change the script so that it suits your needs perfectly. It will do it in a blink of an eye and it will just work. You may need a couple of iterations, but what the heck, it’s not such a huge effort, is it?
Even that is too complicated? Ask someone who is a bit more navigated to help you and you will get there.
That’s wild interpretation of this thread. I didn’t see anybody requesting anything more than xmp next to exported file. Then it was implied that for play raw one would need raw file also. IMHO letting the user to choose if xmp should be copied next to exported file, like the checkbox “Save processing parameters with image” in Rawtherapee would make 90% happy.
But I agree that scripting is the way to go, and this is turning into arguing for the sake of arguing. That being said, I also think that Darktable is full of small QoL features that are not about developing digital photographs and this is weird place to draw the line.
as OP, I agree. Maybe my question should have been: “Lua script to export a jpg with current export setting AND copy the associated xmp, for this state, to the same export location”
I’ll checkout @Masterpiga 's script when I have time again as work is very demanding at the moment and the hobby has to wait a little
If I understand correctly, there is no need for a lua script: this feature is already available through the export module. Choose “file format = copy”, it exports both raw+xmp.
Maybe, an option for this file format could be added, to choose between “raw+xmp”, “raw only”, “xmp only”.
I personnaly would not need “xmp only”, but I think it could solve different needs that were expressed here (with multi-preset export, you could decided to export both jpg + xmp).
Sometimes (rarely), when I want to share raw files, I use the current “copy” and usually delete the xmp afterwards, so it would avoid this step.
@EC1000
Fantastic. This is exactly what I wanted. I was not aware of what the “copy” option will do.
As you suggested used multi-preset one for jpg and one for copy.
Now I get to export jpg, raw and xmp. and use both jpg and xmp for the play raw or any other use. Copied raw can then be deleted if not needed.
The key for me was the “copy” option. I know, I know, I should have read the manual.