DxO Photolab Command line interface

I know that DxO Photolab do not have official of command line interface, but as soon as GUI work with DopCor.exe and it provide some help output for CLI commands.

Usage: DopCor.exe [OPTIONS]+
General switches:
  -h, --help                 Display help and exit
  -l, --listening            Server mode (Use `-l --help` for related help)
      --debug                Increase verbosity
Command line switches:
  -c, --cafsdir=PATH         [Required] PATH to directory containing DxO Modules
  -d, --cafsdb=PATH          [Required] PATH to DxO Modules database
  -k, --oclcache=PATH        [Required] PATH to OpenCl cache file (ocl64.cache)
  -i, --img=PATH             [Required] PATH to input image file
  -s, --sidecar=PATH         [Required] PATH to Preset file
  -o, --output=PATH          [Required] PATH to output settings file
  -p, --outputpath=PATH      [Required] PATH to folder where to write processed
  -f, --outputsuffix=SUFFIX  SUFFIX to append to the name of processed image
  -t, --threads=VALUE        Max number of threads (default: 36)
      --cl, --opencl         Enable OpenCL acceleration.

I try to make CLI working but can’t figured out why it ignore sidecar file

DopCor.exe --cafsdir="c:\Users\Admin\AppData\Local\DxO\DxO PhotoLab 3\Modules" --cafsdb="c:\Users\Admin\AppData\Local\DxO\DxO PhotoLab 3\CAFList3.db" --oclcache="f:\Temp" --img="x:\06_D.ARW" --sidecar="x:\06_D.ARW_.dop" --output="c:\Users\Admin\AppData\Local\DxO\DxO PhotoLab 3\Presets\1 - DxO default.preset" --outputpath="x:\" --outputsuffix=tif --opencl

app exit with error -1

and this

[DopCor|Error] Parameters file doesn't exists or is not a valid sidecar
[DopCor|Error] OutputSettings file doesn't exists or is not a valid OutputSettings files
(Exit code: -1)

Can anyone help me with CLI settings?

And there is a big demand in command line RAW image processing in 3D scan and VFX studios.
And main reason why we just stop use DxO, LR, CaptureOne but start use opensource raw processing tools even if they not as good as commercial not in quality or speed, but because they are give CLI interface.
Can DxO make official support for CLI but not hide this!?

1 Like

Hi Vlad. im asking for this for 3+ years already…

We need make a bit bigger request so that they see we need DXO working with CLI commands.

Dear DEVs, i helped to spread word about DXO and 100s if not 1000s ppl use DXO in 3D scanning. but now we need get thsi to get working. as we processing LARGE amounts of images ( yes even 50.000 - 100.000 pictures in one project )

1 Like

True. Than i will try find contact with real person in DxO :wink:

DXO would have to reallocate resources currently working on other enhancements in order to develop and implement a command line interface. The decision to do that will, in part, depend on the size of the effort involved, the number of likely new customers when the CLI is released, and the future growth potential of that niche market. If they don’t see any significant growth potential they are unlikely to do it.


They do not need relocate resources. They already have CLI.
Information about CLI and it’s behavior just need to be shared to users.
I just have feelings that this CLI interface a bit outdated, and may be not tested for years. As soon as Lightroom plugin use client/server communication with DopCor.exe engine, not via CLI

To say they don’t need to reallocate resources for this suggests you believe there is zero effort required. There is no need for analysis, coding, testing, beta testing, documentation and implementation tasks. In other words all they would have to do is push a button and it would go live. Anything other than that would require a reallocation of resources.


It already working, tested and used by thousands of DxP Photolab users :slight_smile:
When you export anything from GUI it staret Dopcor as listening server.


In theory possible reverse engineer (with wireshark for example) what commands and options GUI pass to server.

For developers this is more like write documentation about CLI and API.

This definitely need time, but not as much as write all this from scratch, i think


I’m a lead developer of the team who is responsible for DxO PhotoLab for Windows so probably I can help you on this topic and answer your questions, if any. Feel free to ask me :slight_smile:

As I know we added the CLI many years ago for the feature that was abandoned somewhere in the middle of its development. However, what you mentioned above looks promising for us so we can decide to resurrect the CLI, update it, and make sure it’s production ready (tested and documented).

For the moment I can share our internal documentation for the CLI interface but you should keep in mind that it’s unofficial, i.e. there is no any public obligation on us regarding it.

@shaman Please confirm that you use DxO PhotoLab for Windows, let us know its version, and share your sidecar file that caused the error so we can investigate it.



Hi Mark,

To see what Vlad/@shaman is referring to, go to “C:\Program Files\DxO\DxO PhotoLab x” and type the command: DopCor /h … which will cause it to provide details of command line arguments.

Interesting …


1 Like

Alex, great!

Yes I using DxO Photolab Elite on Windows.

Actually I already found missed CLI comands, but already have some more questions or may be some bug reports. And will be glad to see at least unofficial documentation that may be show me what’s wrong.

And I already contacted Fabrice from Support, so if you need you can find my contact details.

Sidecar was correct.
Main problem was to find what DopCor expecting for --output it required correctly made xml with settings for jpg/tiff/etc. And in windows embedded inside app config.

I also found that Dopcor do not like multi-threading. Even if run 4/8/16 task simultaneously. Some “forks” do not generate any files. But some made correctly. And this probably my main worry for this moment. Because single thread work extremely slow. But system have dual or quadro GTX cards with 64/128Gb ram with i9 7980XE

1 Like

That sounds like some huge projects !
I am curious, what kind of 3D scanning is that ? Can we have a screenshot if it is not confidential ?

Sounds like a big opportunity for DxO to expend it’s business too :+1:

I have a specific request for CLI that I hope you can point me in the right direction.
Is there a parameter that can be passed via cmd.exe CLI to PhotoLab with two parameters:

  1. raw.pic.filename
  2. DxO project name

The intention is that DxO adds the file raw.pic.filename to the specified DxO project name.


Hello Justin,

Unfortunately, we don’t have such a parameter.


Hi Shaman,

I’m facing the same problem as you, DopCor returns error -1 and I don’t understand what I need to change.

If you managed to launch the execution, can you share with me how you did it?

Many thanks, it will be a big step forward to have DxO in CLI!

Hi Vlad and Alex (and all)

I would like to use DopCor to simply export a RAW file to a TIFF with DeepPrime enabled on the image. Is there an example of a command line prompt to do this? I am not sure of the XML needed in the output as mentioned.

Any help appreciated.


Hi Martin,

If you haven’t already, it’s worthwhile reading comments by Alex (DxO staff), above.

Meanwhile, FWIW, the available command line parameters for DopCor are;

John M

This will not work :slight_smile:

Values definition are different from what they are. And sidecar file is totally different and can be reversed only if you have access to OSX version that export specific file.

But to be honest, i found that DxO Photolab extremely slow in CLI.
It not well multithreaded. Because multiexport for this moment probably work only via socket from GUI.
And even if you will use max possible concurrent exports from DxO it will work much 5-10 times slower than some other raw processing apps. :frowning:

Thank you John-M,

Yes have read through the thread but am curious about what Shaman is saying below. I don’t understand this oart.

Have you been able to export TIFF with DeepPrime through DopCor as yet? Be great if @alex could chime in if there are any advancements or clarifications.


OK, thanks Vlad.

I wonder if @alex can continue on development with this as a CLI has so much potential in a workflow.

Appreciate your input.