darktable-org / darktable-org/darktable

Support opening an ad-hoc lighttable collection from multiple file paths passed on the command line

Open
#21,096 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

feature: enhancement no-issue-activity
Dominant language
C
Stars
13.1k
Forks
1.4k
Avg merge
22h 14m
Merged PRs (30d)
198

Description

Is your feature request related to a problem? Please describe.

Yes.

I use an external DAM/browser/culling application (for example XnView MP) to organise and filter photo sets by metadata/categories. A common workflow is:

  1. filter a specific subject/set in the external DAM
  2. select only those RAW files
  3. open the selected files in darktable for RAW development

Currently there is no robust supported way to open an arbitrary externally-selected file set as a temporary lighttable collection because darktable's GUI invocation appears to support only one positional target:

darktable [OPTIONS] [IMAGE_FILE | IMAGE_FOLDER]

This works well for opening one file or one folder, but not for opening an arbitrary selected set of files as a temporary/ad-hoc lighttable collection.

Example use case:

raw/
  IMG_0001.RAW
  IMG_0002.RAW
  ...
  IMG_0420.RAW

Only a small subset belongs to one portrait subject/project:

IMG_0172.RAW
IMG_0173.RAW
IMG_0174.RAW
IMG_0175.RAW
IMG_0176.RAW

Opening the whole folder in darktable shows the full film roll instead of only the selected set.

When trying to pass multiple selected files from XnView MP using a command such as:

darktable %F

darktable shows a loading/import dialog but does not reliably open a usable lighttable view with only the selected images. In my case it either finished without showing the expected main darktable view or appeared to crash/hang.

The current workaround is to create a temporary folder containing symlinks to the selected RAW files and then open that folder in darktable:

mkdir -p worksets/portrait_subject_a

ln -s ../../raw/IMG_0172.RAW worksets/portrait_subject_a/
ln -s ../../raw/IMG_0173.RAW worksets/portrait_subject_a/
ln -s ../../raw/IMG_0174.RAW worksets/portrait_subject_a/
ln -s ../../raw/IMG_0175.RAW worksets/portrait_subject_a/
ln -s ../../raw/IMG_0176.RAW worksets/portrait_subject_a/

darktable worksets/portrait_subject_a

This works, but it is a workaround. It adds friction and creates temporary filesystem structures just to express an already existing selection.

Describe the solution you'd like

I would like darktable to support opening multiple image file paths as an ad-hoc temporary lighttable collection.

For example:

darktable file1.RAW file2.RAW file3.RAW

Expected behaviour:

  • darktable opens in lighttable mode
  • only the supplied files are shown
  • the files are imported/registered as needed
  • no filesystem copy or symlink workaround is required
  • existing XMP sidecars and normal darktable non-destructive workflow remain unchanged
  • the collection can be temporary/ad-hoc, similar to a filtered view

Alternatively, an explicit option could avoid ambiguity:

darktable --collection file1.RAW file2.RAW file3.RAW

or:

darktable --files file1.RAW file2.RAW file3.RAW

The important part is that external tools can pass an arbitrary selected file set and darktable opens exactly that set in lighttable, not the whole folder.

Alternatives

Current alternatives are possible but weaker:

  1. Open the whole folder in darktable and manually search/filter filenames
    This is slow and defeats the purpose of using an external DAM/category system to identify the set.

  2. Create a temporary folder with symlinks to the selected files
    This works, but it is a workaround and adds unnecessary filesystem clutter.

  3. Copy the selected RAW files into a separate folder
    This is worse because it duplicates RAW files and can create metadata/sidecar divergence.

  4. Use darktable as the only DAM
    This does not fit workflows where another application is already used for browsing, grouping, contact sheets, category assignment, or fast external culling.

Additional context

This feature would improve interoperability with external DAMs, file managers, and image browsers such as:

  • XnView MP
  • digiKam
  • file managers
  • shell scripts
  • custom culling workflows

The workflow is especially useful when one physical folder contains many images, but only a subset belongs to a specific subject, client, project, or delivery set.

Example real-world structure:

raw/
  IMG_0001.RAW
  IMG_0002.RAW
  ...
  IMG_0420.RAW

External DAM metadata/category:

Categories
  People
    portrait_subject_a

Desired action:

Filter People/portrait_subject_a in external DAM
Select all visible RAWs
Open selected files in darktable
darktable shows only those selected files in lighttable

This would make darktable more usable as a RAW developer in mixed-tool workflows, where another tool handles DAM/category filtering and darktable handles RAW editing/export.

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 by tracing darktable's command-line invocation and the code that opens the lighttable for supplied image paths. Compare the existing single-file or folder behavior with the requested multi-file case, then define how the selected paths are registered and displayed without showing the containing folder.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
cli, desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.