darktable-org / darktable-org/darktable
headless XMP import for darktable-cli
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 13.1k
- Forks
- 1.4k
- Avg merge
- 22h 14m
- Merged PRs (30d)
- 198
Description
Summary
Expose Lightroom/ACR XMP import in a headless darktable-cli workflow.
Use case
I'm working on RedLnx an AGPL-3.0 local AI tool for photographic post-production.
RedLnx trains from folders of XMP files or Lightroom catalogs, then writes Lightroom/ACR-compatible sidecars for new RAW batches. I'm now exploring an experimental image export feature, and darktable looks like the right renderer for that.
Current behavior
If I open a RAW in the darktable GUI and there is a Lightroom/ACR sidecar next to it:
file.ARW
file.xmp
darktable imports the Lightroom edit and creates a native sidecar:
file.ARW.xmp
That native sidecar contains darktable:history and darktable:params.
After that, darktable-cli exports correctly:
darktable-cli file.ARW file.ARW.xmp out.jpg
Problem
Passing the Lightroom/ACR sidecar directly to darktable-cli gives an empty/default history:
darktable-cli file.ARW file.xmp out.jpg
Observed output:
The exported image is pixel-identical to exporting without the Lightroom sidecar.
So it looks like darktable-cli expects a native darktable history stack and does not run the Lightroom/ACR import path.
Requested feature
Expose a CLI/headless way to convert or apply Lightroom/ACR XMP sidecars.
Possible command shape:
darktable-cli --convert-lightroom-xmp file.ARW file.xmp file.ARW.xmp
or:
darktable-cli --import-lightroom-xmp file.ARW file.xmp out.jpg
Any equivalent workflow would work, as long as it can:
- Read file.xmp with Lightroom/ACR crs:* fields.
- Create the native darktable history.
- Write file.RAW.xmp, or export directly using the converted history.
- Run without manually opening the image in the GUI/darkroom.
Why this matters
Darktable already knows how to translate Lightroom/ACR sidecars into its own pipeline when the image is opened in the GUI. The missing piece is exposing that same conversion for batch/headless workflows.
For external tools, reimplementing darktable:params is not a good option. Those payloads are module-version-dependent and likely to break across darktable releases.
GUI/Xvfb automation is also fragile and not a good fit for Wayland-focused desktop setups.
Environment tested
darktable 5.4.1
Fedora Linux
Sony .ARW RAW files
Lightroom/ACR XMP sidecars with crs:* tags
Example Lightroom/ACR fields:
crs:HasSettings="True"
crs:Exposure2012="0.080436"
crs:Contrast2012="..."
crs:Highlights2012="..."
crs:Shadows2012="..."
Current workaround
Manual workflow:
- Open/import the RAW in darktable GUI.
- Let darktable create file.RAW.xmp.
- Run:
darktable-cli file.RAW file.RAW.xmp out.jpg
This works, but it cannot be batched cleanly from another local application.
Closing note
Thanks for darktable. It is one of the few serious open tools that makes this kind of local photographic workflow possible.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the darktable-cli entry point and trace how the GUI/darkroom currently imports Lightroom/ACR XMP sidecars and creates a native sidecar. Define the headless workflow and verify that it reads crs:* fields, produces the native history or exports directly, and works without manually opening the image in the GUI.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100