DxO Photolab Command line interface

Joanna · April 30, 2025, 10:08am

No thank you. After many years programming in .NET, there’s no way I’m letting that junk anywhere near my Macs.

What’s more, unless DxO could embed .NET in their app, it would mean users having to do so. Then there’s the question of updates

Gyves · April 30, 2025, 10:31am

Ok…
The term “junk” reflects your personal opinion. Do you give me permission not to share it and to consider .Net Core differently?

And for your information, I don’t know for macOS but on WIndows, it seems PLB is using .Net (but maybe not Core ) for PLB on WIndows.

Joanna · April 30, 2025, 3:02pm

Of course. I was just glad when that contract came to an end

Of course, it’s the only sensible choice.

gserim · April 30, 2025, 6:35pm

I think that the classic command line will become obsolete sooner or later. The more powerful option in future will be communication with the built-in AI interface. I will no longer have to program processes myself via the CLI, but will first discuss my requirements with the AI and then instruct it to carry out the specialized requirements.

Gyves · May 1, 2025, 7:58am

Do you want to talk about a query method to an AI in natural language, and not with writing that uses strict syntax and semantic rules like PowerShell commands?

If yes, it’s not exactly the same thing, imho.

A CLI authorizes the use of commands that will be executed according to the “computer code” writed.
For example, PowerShell allows you to adapt to each case (processing size, limitation, parallelization, etc.) and optimize the execution time for each task.
This is exactly what you want to optimize with a script: process time and load balancing.
The limit of a CLI/Script tool is that it’s dumb. But it is a very robust dumb. It performs time-consuming tasks for you.

An AI is (should be) able to give you more advanced means of processing (a local adjustment can’t be done simply with a script), but the AI will be less robust than our workhorse of a script.
But why? Because you have control over how you want the PLB* commands to be executed.

So, imho, they’re 2 different tools with different uses depending on the circumstances.

*Not sure if this is of interest to many people, but I could give you examples if DXO had a PowerShell module.

gserim · May 1, 2025, 10:29am

I’m just going to take the position that the AI (I’ll call it assistant in the following) will be robust enough. I assume that it is already possible today to have Copilot generate PowerShell scripts. That is already going in that direction. It would be a great advantage for DXO to hide the CLI behind the assistant. Reengineering code would be much more difficult (this has already happened earlier in the thread :-). In addition, any small change to the CLI interface would mean that scripts that we users have painstakingly put together would no longer work correctly after a software update. But this is all speculation. It could, however, explain why DXO is deferring a CLI implementation.

asvensson · May 1, 2025, 11:08am

My guess is that it will never happen. DxO has a hard enough time maintaining the UI they have, let alone adding a completely new one with (likely) a relatively small target audience.

I love the command line, and I use it with ImageMagick and exiftool to perform various batch tasks (eg. converting/resizing exported tiff to jpeg), but actually editing images using the command line (which I’ve done in the past with dcraw and ImageMagick) requires iteration that’s clumsy at best.

Editing images is inherently graphical, unless you don’t care about the result.

poulp · May 13, 2025, 8:12pm

+1 on this!

“Editing images is inherently graphical, unless you don’t care about the result.”

That’s not always true. There are many professional and technical workflows where manual editing isn’t needed—or even feasible—due to the scale or nature of the task. For example:

Photogrammetry and 3D scanning
HDRi panorama creation
Scientific image processing

In these cases, users need to apply consistent, high-quality corrections—like DxO’s lens profiles and DeepPRIME denoising—across hundreds or thousands of images automatically.

A CLI is essential in such scenarios. It enables automation, scripting, and distributed processing across multiple machines—This makes a huge difference in production workflows where manual input is a bottleneck.

DxO’s image quality is outstanding, but the lack of a proper CLI is currently a major limitation for users in these fields.

An alternative could be an SDK or API that allows developers to interface directly with the DopCor server. That would open up powerful integration possibilities for advanced users and studios alike.

shaman · May 14, 2025, 12:58am

Gals, sorry to be a bit arrogant, but 5 years is enough understand that DxO will never release this feature.

I tested almost all raw processors in terms of cli batch processing abilities including DxO.
Even if you will nailed how DoPcore works you immediately will find tat it did not support multithreading, even if GUI support it.
So CLI DxO is totally useless.

Best in speed is Lightroom, that CC version you still can control using Javascript like API. That open you the way to CLI batch processing with some pain. That will be a fastest solution.

Most usable is RawTherapy, that can run in parallel, and as result you can run multiply parallel processings in RT and get speed about half of speed that can give you LR.

DarkTable maybe more feature reach and has cli too. But its developers are on the same wave as DxO and you can’t run multiply DT threads.

If you still want to try to use DopCore you need find a user.config in you
c:\Users\*****\AppData\Local\DxO\DxO.PhotoLab.exe_StrongName_****\#.#.#.####\user.config

there you can find data that you need format to xml like this:

<?xml version="1.0" encoding="UTF-8"?>
<ArrayOfanyType xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
  <anyType xmlns:a="http://schemas.datacontract.org/2004/07/DxO.OpticsPro.OutputSettings" i:type="a:FileOutputSettings">
    <a:AllowResampling>false</a:AllowResampling>
    <a:CanDisable>true</a:CanDisable>
    <a:CustomIccProfile />
    <a:CustomResolution>72</a:CustomResolution>
    <a:DestinationFolder />
    <a:DestinationIsOriginalFolder>true</a:DestinationIsOriginalFolder>
    <a:Enabled>true</a:Enabled>
    <a:FormatType>Tiff</a:FormatType>
    <a:FullOutputPath />
    <a:GenerateTemporaryFile>false</a:GenerateTemporaryFile>
    <a:IccProfile>Original</a:IccProfile>
    <a:Id>f6a2ef05-befc-44de-8e1e-36649cd33855</a:Id>
    <a:InterpolationType>Bicubic</a:InterpolationType>
    <a:JpegQuality>90</a:JpegQuality>
    <a:OutputHeight>1024</a:OutputHeight>
    <a:OutputName>VLAD</a:OutputName>
    <a:OutputSizeUnit>Pixels</a:OutputSizeUnit>
    <a:OutputWidth>1024</a:OutputWidth>
    <a:OverwriteOutputFile>false</a:OverwriteOutputFile>
    <a:RawSuffix>_raw</a:RawSuffix>
    <a:RenderingIntent>Perceptual</a:RenderingIntent>
    <a:ResolutionUnit>dpi</a:ResolutionUnit>
    <a:RgbSuffix />
    <a:SavedExifFields>All</a:SavedExifFields>
    <a:Sharpness i:nil="true" />
    <a:Suffix>_cor</a:Suffix>
    <a:SuffixForSnaphot>_ds</a:SuffixForSnaphot>
    <a:TemporaryFileSuffix>tmp</a:TemporaryFileSuffix>
    <a:Tiff8Bits>false</a:Tiff8Bits>
    <a:TiffCompression>false</a:TiffCompression>
    <a:UseRawOrRgbSuffix>false</a:UseRawOrRgbSuffix>
    <a:UseUniqueNaming>false</a:UseUniqueNaming>
    <a:UseVirtualCopySuffix>false</a:UseVirtualCopySuffix>
    <a:Watermark xmlns:b="http://schemas.datacontract.org/2004/07/DxO.OpticsPro.DopCommon.OutputSettings" i:type="b:Watermark">
      <b:Active>false</b:Active>
      <b:FileName i:nil="true" />
      <b:Position xmlns:c="http://schemas.datacontract.org/2004/07/System.Windows">
        <c:_x>1</c:_x>
        <c:_y>1</c:_y>
      </b:Position>
    </a:Watermark>
  </anyType>
</ArrayOfanyType>

you also need this files:

%USERPROFILE%\AppData\Local\DxO\DxO PhotoLab 3\OutputSettings.xml
%USERPROFILE%\AppData\Local\DxO\DxO PhotoLab 3\CAFList3.db
oclcache="%USERPROFILE%\AppData\Local\DxO\DxO PhotoLab 3

Not sure if this will work in V4+ I tested this only in v3.
But as soon as DxO newer versions as slow as older one, don’t think you really need this CLI at all.

As for me, at the end I just wrote my own raw batch processor (LGPL) that maybe not so powerful as LR but several times faster than LR

gserim · May 14, 2025, 6:10am

Are you referring to this batch processor?

poulp · May 14, 2025, 8:26am

Hey Vlad ,

Thanks for the info about the DopCor CLI! It still kind of works, but like you mentioned, some settings don’t apply properly, and it’s both slow and unofficially supported.

Regarding speed, I tried to replicate what the GUI does by running DopCor in server mode and connecting to it via a C# named pipe. But generating the correct correction and processing parameters per input isn’t straightforward. Also, I’m not sure this approach complies with the Terms of Service, so I’ve decided not to pursue it further.

I also use LibRaw, RawTherapee, etc. But in general, and especially when it comes to Fuji X-Trans RAWs, DxO still delivers significantly better results in my experience.

For now, the best workaround I’ve found is to use DxO PureRaw—which does have a basic (and undocumented ) CLI—to convert RAW → DNG with DeepPRIME and lens corrections. Then I continue processing the DNG with LibRaw or other tools.

noninc · July 11, 2025, 11:17am

Hey @poulp,
can you please share how you use PureRaw from CLI?
Thanks a lot!

Joanna · July 11, 2025, 12:45pm

Try asking in the PureRAW section