darktable-org / darktable-org/darktable

headless XMP import for darktable-cli

Open
#20,953 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

no-issue-activity
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:

  1. Read file.xmp with Lightroom/ACR crs:* fields.
  2. Create the native darktable history.
  3. Write file.RAW.xmp, or export directly using the converted history.
  4. 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:
  1. Open/import the RAW in darktable GUI.
  2. Let darktable create file.RAW.xmp.
  3. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.