Processing photos in Darktable without a GUI

Software darktable
1

Hello,

Here is what I want to achieve:
I want to use the command line to apply Darktble styles to my photos without using the GUI because I want to run things on a powerful remote computer.

I know I can just apply some style to a photo using the darktable-cli like so:


darktable-cli photo.CR3 out.jpeg --style portra --style-overwrite

But the issue is that this command requires the portra style to be already imported into Darktable’s database.

How can I import a Darktable style without using Darktable’s GUI?

I couldn’t find a command that does that.

If this command indeed does not exist, I guess the only hope is to somehow manually set up the style by changing things in ~/.config/darktable, but I have no idea how to manually install a style like so.

2

Styles and presets are stored in data.bd, so if you have access to that remote computer that may give you some options. But I have no idea if it’s safe to copy data.db from one installation to another (using the same darktable version seems a minimum requirement, though).

3

What about using an xmp?

4

Could work, but that will apply the full history stack, including white-balance and exposure settings.

I guess we’d need to know a bit more about the intended workflow with that remote machine (e.g. has OP physical access the remote machine, is it a headless system, …).

5

The remote machine is my personal NAS server, so it is a headless system that I have physical access to. And I mainly interact using SSH.
I could install some DE and Wayland just to import the style, but that is really my last resort if I can’t figure this out.

I tried exporting multiple different raw photos using the same .xmp, and it seems to work fine.

I guess this is a solution, but maybe I am not using the xmp as intended?

7

I have noticed a problem with the xmp idea:
if I try to export the same photo again with a different xmp, the result is a broken photo. I don’t know what happens, but it seems darktable remembers the last xmp used to export, and somehow this messes up the new export.

It seems to be some side effect of not using the xmp as expected to.

8

The intern is that you apply the same xmp to multiple images. If you apply the multiple xmp to the same image, you will get the variations of each xmp to that image.

9

My expectation was to get multiple variations of the same image.
Maybe I didn’t explain the issue well enough.

Here are my actions:

 darktable-cli photo1.CR3 portra.xmp out_portra.jpg

This gives the expected result.

Now, if next I do:

 darktable-cli photo1.CR3 astia.xmp out_astia.jpg

I get a broken image with wrong colors.

There is nothing wrong with the xmp files,
If instead I apply first the astia.xmp to a “new” photo, and then the portra.xmp, then the astia.xmp gives the correct result, but the portra.xmp now gives the broken image.
My conclusion is that there is some internal state change in Darktable that makes this workflow not work.

10

I don’t use darktable-cli, but perhaps one thing you could try is append --core --library :memory: to the invocations of darktable-cli. If the sidecar history is appended to the image, named modules could be present in several copies if you use a sidecar on an image that’s already in the database. (in effect applying both portra and astia effect to the image).

You also should perhaps review the darktablerc on the NAS…

11

I’m not on my PC for a while. Can you test a few things? Open the GUI and change the xmp mode to overwrite instead of append. Does it make a difference? If yes, open the GUI again and see if it makes a permanent change to the image(I assume yes).

I might have a workaround to test.

12

--core --library :memory: made no difference.
I will take a look in the darktablerc, thanks.

13

It already was in overwrite mode :frowning:

14

this just means: just take astia.xmp to process the file - or if you replace it by portra.xmp than that. If both xmp files have different modules, then it’s obvious that they give different results if they were defined using different images

If you just want to add a style, that just adds a look onto a proper edited image, then your command in the initial post can be a solution (but don’t use overwrite mode in this case): if you don’t use file related settings (like lut3d or custom icc files in colourin) then copying the data.db from your machine, where you defined those add-on styles into the config directory of your remote machine might work. darktable on the remote machine must know the configuration you want to use.
The initial processing of your file must be available as a xmp sidecar

15

Maybe with a Lua script? But you can’t import from darktable-cli. The style must already be imported when running the command with --style option.

16

You can import a style from a lua script, darktable.style.import(filename), though I’m not sure you can run a lua script in darktable-cli.

Maybe darktable-cli --core --luacmd 'require "script_name"'

EDIT:

Maybe run the --luacmd first to load the style, then run to actually do the export?

17

The user manual for darktable-cli says we can import

import
Specify input file or folder, can be used multiple times. This option cannot be combined with .

18

Doesn’t that mean importing image files?

19

Per reading the manual, it seems that it adds them to the library. I’ve never tried any of this.

20

Maybe I am being naive, but provided that there is the same version of DT on both machines, can’t you copy your .darktable directory to the NAS, and then manually change all the paths in data.db to match the new filesystem? If you have the same folder structure on the NAS and on the client this last step may also be superfluous.

21

It seems --import is for importing photos, not styles.
The commands

darktable-cli photo.CR3 portra.xmp  out_portra.jpg

and

darktable-cli --import photo.CR3 portra.xmp  out_portra.jpg

Have the same result.

1 Like