DPL7 is sluggish

The title is provocative on purpose, but I have been a loyal user since 2007 and I can only acknowledged for the work that has been done so far.

DxO was sluggish in 2008, in 2010, and until today. All these years I thought it was because the raw files were very large for the available computing power then. in 2007 I had 4 gb of ram and a dual core intel cpu, it was more than decent at the time. But processing 50 files of the Alpha 900 (24mpixels) or 5D mark II (21 Mpix) was a big ordeal often crashed. It was worth it for the quality. But over the years, my computing power exponentially increased…but not the Mpixels of the picture i take.
I shoot R5, R3 and GFX100 (seldom used, 10% of my production) and yes I have one hundred of image or so in each projects, mainly composed of picture from 24 Mpixels to 45Mpixels.

My computing power is I think close to the best you can have today, Threadripper 3970x (32 core and 64 threads), 128Gb or Ram, coupled with RTX4090. You can have more of course, but what for in this case ? Man, even in 2023 DPL 7 is so sluggish and slow !
I wanted to push all the levers I had on the hardware side : my working folder and all the image I work on are on a RAID-0 of two PCIexpress gen4 Nvme drives (seagate firecuda 530). I have 13,5 GB/sec bandwith…and very good numers in random access. Every other soft I have are lighting fast and snappy…except DPL. Previously I had my files on a seagate classical hard drive, and DPL7 took forever to display them.

Detecting the need for new lens profiles and applying them is very long also.

Going from local adjustment mode to normal edit mode takes time, zooming and have 100% aspect ratio takes forever after applying local adjustmens. I like to work fast, when I have to edit and tune 100 images, I want to go very quick. I know the software, I have been using DxO and DPL for 15 years. I am waiting too much for the software to do and respond to what I want it to do. Local adjustments, crop, adjust geometry, apply Lut or profiles from FilmPack…it could be snappier.

I looked in depth, it seems DPL takes time to transfer data in OpenCL to the RTX4090. Deactivating the OpenCL support improved the responsiveness a bit and with 64 threads in my CPU, it is okay I think. I kept the DeepPrime acceleration with the RTX Card.

My concern is that nowaday, it is very common to have heavy multicore setup. having 12 or 16 cores and hyperthreading is common in the community of photo enthusiasts. And I don’t find DPL very well optimized for multithreaded environment.

The CPU capacity load is very very light. I am frustrated that in any setup, with or without OpenCL or not, the system is quite slow and sluggish while my system load is so light. Use more power ! It is here to be used. DPL could be more optimized for Highly multithreaded environments.

My experience is roughly the same as 15 years ago (well DxO 9 did improved the browsing speed of a big folder) with a computing power and storage speeds that are much higher today, and with file size that are pretty much the same (24-45megapixels).


Forever and very long are subjective and hard to grasp. Can you substantiate the times in minutes or seconds per image and add an example file and fitting .dop sidecar for us to get an impression of your issue?

How about your image folders? Do they contain tens, hundreds or thousands of files?

Have you taken into account the fact that PhotoLab renders each image in such folders, while other apps just display the built-in jpeg previews?

Fair enough.

At least 4-5 seconds of waiting for several operations described above (each of them), best setting is to completely disable openCL support in my config. Here I can save 1-2 seconds. Even DeepPrimeXD acceleration is questionable with 64 threads.

The longest is going from local ajustment to erase mode to normal edit mode. Circling between these tools takes time. It is frustrating when the system load is not over 5-6 %. Even when i launch the processing of dozens of image in a row, my system load is not over 25-30%. it could be more an go quicker.

I don’t care if my folder has hundreds of raw files, C1, lightroom, Canon DP or FastStone have no problem browsing the raw (not the embedded JPG…).

Engine should be optimized for more cores and hardware.

I have FastStone, and when I set it to view raw files using the raw file size and interpolation settings below, refreshing is much slower then PhotoLab. I wonder what FastStone settings you are using.


1 Like

the issue most probably are with either gpu driver and/or specific to this amd cpu …

DxO writes about OpenCL is very generic terms :slight_smile:

“When activated in the preferences, OpenCL is used for rendering export images, as well as for displaying RAW previews when the zoom level is above 75%. This is only the case if our benchmark has determined that OpenCL performance is superior to CPU processing.”

ask the support if they have benchmark to run on your specific PC

PS: I do not see any material difference between using OpenCL -or- not using OpenCL on a much less spec’d PC ( i7-9700K / 64gb / RTX 4070 ) when doing a batch export with 3 simultaneous processed images in setting ( 3 is the optimal in my case vs default value of 2 )

one can assume that whatever coding DxO did was/is not able to use OpenCL to the proper potential ( or even actually detrimental in case of some configurations )

Good remark for the internal benchmark. Maybe it is a driver issue with the new RTX4090, but this GPU has been out long enough for DxO to adapt normally.

I use fastone without the high quality interpolation, but it makes a quite little difference to me. FastStone is used here as a first level culling/editing of a shooting day. I use it to halve my usable images, and reduce by 50-60% my daily production when I’m out on a serious shooting day. Then I move to DPL.
On the advices of some members here I bought FastRaw, and got disappointed. Interesting to cull and select quickly the best images of a burst shoot for wildlife, but in the end, FastRaw doesn’t help you judge if an image is photographically better just because the focus zone is crispier than the image a split second before. In FastRaw you have this special view for microcontrast and sharpness (zebra kinda thing focus peaking) the picture is all black except some green and red zones on the sharp zones of the picture…impossible to use it to make any art-related selection. Even the ergonomy is not streamlined and definitively could use the help of an ergonomy expert for batch review.

Funnily enough ImageBrowser from canon could display the raw file quicker than DxO at the time.

So after FastStone, I use DPL7 directly for the editing of the final 40-50% of my images. At a time, DxO had a preview tool that I loved very much. This used a quick raw rendering, you could rank and give stars to your selection. I really wish this tool makes its comeback soon. A real Editing tool with a few quick metrics like Dynamic, sharpness, and some neutral/optimized rendering for you to make your selection.

To go back on my subject, i think there is work to do to have DPL leverage from the high end hardware it can play with.

You could summarize my feedback into the suggestion to make DPL engine more capable to work with big amount of cores, to better work with high end hardware so the experience could be snappier.

I know this is deep work, because we are talking about how the foundation modules of the soft handle scheduling of tasks, and use hardware.

As a long time user and loyal customer (more than 15 years !), DxO and DPL now is my main worktool for my photography, and I am demanding a bit more. I think DPL could go further in :

  • the color management (C1 forte here) as I described in another post
  • the responsiveness that has to improve for usability
  • revamp the repair tool which is lagging behind now. With the prowesses of Generative AI, clone-based algorithms are outdated. When I want to remove an imperfection in a portrait or remove a can on a lawn it is ok, but going further still requires that I open photoshop afterward.
  • By all means improve the printing module ! Printing requires photoshop still. DPL could do all of it.

And I am not asking any AI-generative fancy crazyness (it will have to come though, but at the service of photography tools).

But let’s not complain, the results I get are outstanding, the DxO team provide exceptional work that I am happy to support, and I don’t like lightroom :slight_smile:

1 Like

I see a difference when i deactivate OpenCL if feels snappier when i zoom beyond 80% in a image. Especially the case in medium format pictures, but even feels it with R5 pictures. Not that the Geforce RTX4090 is slow, but it seems the software has hard time calling an OpenCL session, task the GPU, send the data and get results back. CPU only feels quicker.
The root of my frustration is this relative sluggishness when I see a system load of 2-6%. I would like it to be much quicker (1-2 second rendering time at 100% of a EOS R5 picture or GFX100, instead of 4-6 sec, and could live with a system load of 15-20% :slight_smile:
maybe a patch for scheduling tasks better? At the dawn of multi-core CPU. Adobe was one of the first to support it, but it took them some time. Matlab for exemple took much more time and required the use of a multithread toolbox that forced you to rewrite your code quite much. but it was in 2004-2005…in Apple’s world, M3 will have 20+ cores available. I am curious to see how my workload could be handled on a mac-version DPL7. Anyway the windows experience has to improve.

1 Like

you can check dopcor.txt in C:\Users\ {user name used} \Documents\DxO PhotoLab 7\ for text like

OpenCLDeviceCache Dump :
cpu perf : 35.1812
initilization test result : Initialization test succeeded
list of device :

  • ID = 0: Signature = NVIDIACUDA-NVIDIAGeForceRTX4070-537.42 - b9e018ec5a3ea5718856b14e9c81754f PerfIndex = 627.139 Status = OpenCL device is faster than the main CPU BinOffset = 0 BinSize = 342614

see what is in your system… not sure if that will be useful in your case


I have not been a PL user for long, but I have learned from the forum that I am a world away from a professional approach to the variety of functions and targeted application. I have to rely completely on the esteemed forum members, who give me important impulses just by reading along. However, I can contribute something from my professional past, as I was also allowed to deal with more complex systems.
I still remember the following constraints:

  • In order to distribute the tasks to all processors and then utilize them well, the software processes must be splittable. Finding this out is more difficult than you might think.
  • If it is possible to divide them up, recombining the sub-processes is an additional task that requires different solution strategies.
  • Different operating systems (Windows / MACOS) contain different mechanisms for this - portability suffers.
  • Analysts estimate that the additional effort for this approach is significantly higher (up to a factor of 3).
  • The new software can potentially contain more sources of error. Software maintenance is also significantly more time-consuming.

This does not mean that such a system cannot be programmed. But it does mean, for example, that programming new functions can take considerably longer. This is usually not accepted by us users, as can often be read here in the forum. These are my personal experiences with complex systems and I personally (unfortunately) don’t expect a solution to these request.

1 Like

It is.

It is.

Photolab is the sluggiest software I know of by far.
Not talking about denoising, but usability of the software in several areas.
Too much things make it slower than imaginable.
Even with a top recent graphic worstation it looks like it is running on a more than 20 years old workstation.

1 Like

You are right, it reminds me my early days of engineering as I was trying to run complex Matlab code for high bandwidth signal processing on a multi-CPU workstation…I had to rewrite the code so badly that in the end i did it only for critical data processes.

But 2023 is nowhere near early 2000s. A very good friend of mine working at Github showed me what the latest version of Copilot is capable of in terms of code writing from prompts and specs…it is simply amazing. This is the end on long nights of code writing and code checking. With a single prompt, and a copy paste of thousands of lines of code and just say "optimize this for this power enveloppe / multithread…"The magic works.
The pull requests mechanism is also an incredible time saver.

So…sorry guys but a soft HAS to be optimized now for multicore environment, no excuses ! AI is here to help by the way for the code optimization.

But again DxO work is incredible, and the best work attracts the most demanding customers (but, as me, they stay loyal when the improvement pace is satisfactory, I must admit that I hardly saw the interest of DPL7, but wanted to support anyway because I hoped work was in progress in the color fidelity and proofing / printing area, prove me right please).

1 Like

I just checked this out out of curiosity.
And I found this :
GPU model: NVIDIA GeForce RTX 3090 Ti
GPU memory: 4095 MB
GPU model: NVIDIA GeForce RTX 3080 Ti
GPU memory: 4095 MB

(PL6 and PL7 trial gave the same values here).

I’ve got both cards on this workstation.
What does this mean ? (neither RTX3080 nor RTX3090 are 4095MB vram …).

I hope DxO is monitoring these frustrations.
Has anybody with a direct connection to DxO’s development team ever responded here, i.e. in the capacity of an associate with influence - not just as a super user?
It would be of common interest if these issues were recognized by DxO through a direct confirmation.
Or is DxO actually a distant, disconnected and dialog avoiding and user unfriendly entity?
In cases where I have contacted DxO’s support, I only met the well known student responder. A complete waste of time.
You are welcome to answer these questions directly - DxO.

They are monitoring, but the most meaningful contribution are made during the beta-test campaigns. The slight limitation is that during the betatest, the feature set of an annual version is pretty much defined already, and you are only intensely testing and debugging.

But as a company, DxO has limited ressources and must choose its battles (features to implement). With the coming of Generative AI (latest version of Photoshop is a real GameChanger for agencies, design, and illustration. Firefly is just really really incredible), it will attrack most of the ressources I guess. Before that I would really like an updated printing module (and I don’t want to wait for another ten years, like I did for WideGamut and softproofing).

How many people in ad agencies using Photoshop and generative AI to edit images for online use utilize the same process for large format print output?

And what percentage of them are photographers(when not saying everyone is a photographer today because they use their mobile phones for snapshots)?

Also generative AI is not a game changer, it is part of the game.

What is the global market share of camera user who shoot RAW and who don’t need or want generative AI anyway?

What I’m mainly trying to understand is how Photoshop with generative AI in an agency environment with collaborative working compares to a photographer processing their RAW photos. Is the output intent even the same and is the market share for the creation of sans-generative AI photography really that insignificant?

I couldn’t even find any numbers for how many percent of the worlds cameras are used in agencies.

Working with a marketing agency I monitor the development of AI closely. So far the majority of clients hesitate to use generative AI in ads/campaigns.

But AI has changed the speed ofproduction of ads or videos. Have a look at Davinci Resolve: Superscale, Voice Isolation or Magic Masks (all AI powered) have made production of common clips so much faster and easier that noone can recall the times these tools were not available.

Once some legal questions using generative AI have been answered, we will see more and more campaigns with “invented” visual content. Generative AI will become one additional tool in the toolbox of ad agencies (as ChatGPT and its siblings have become already).

I’m assuming you also work people in other agencies or at least have contacts. Is it the same for every agency? Also is there there no difference between generative AI and corrective algorithms?

Regarding the speed of PL 7 vs 6.
On my Windows 10 system with an i7-9700k and RTX3070, startup time has reduced from around 40 to less than 20 seconds. As to processing speed I have not done any test to be able to say, but it is definitely not slower.

I have pretty much the same experience between PL6 and 7, and in between I have upgraded from 10980xe intel (18 core with HT) to Threadripper 3970x (32 cores with HT), and from RTX2080 to RTX4090. Same amount of Ram. My wife is now using my previous config for editing, and creating the layouts of our prints (books, posters, fine art printings). I am currently using it tonight, and local adjustments with repair tool, espacially the masking tool are still way too slow. up to 8-9 seconds to display the changes on EOS R5 raw files (and not even at 100%, just in fit to screen ratio). This…is…very…slow. Especially when my cpu load doesn’t get beyond 10% (20% during the export with DeepPrime XD), and the RTX no more than 10% also.
Having 64 threads available, I tried to launch a big batch of export (200 photos) with 12 simultaneous rendering. No more than 6-8 launch at a time, with a maximum CPU load of 20-25%

That is sluggish. :open_mouth:

I have not been able to reproduce it with the RAW files from my M6 Mark II or some of the random NEF files I from the forum I still have in my downloads folder. Even if I quickly randomly click on the sliders, the view updates quickly after the last click (not timed but feels like few hundred milliseconds - not 8-9).

I would like to ask you for a favour @Kyosato. Could you take a random photo of something so the content is not relevant to you, make adjustments where the delay happens and then share the RAW file and DOP here. And say with the change of which setting(s) you get the delay?

As there are not more people complaining about this in this thread, I’m wondering if it’s limited to certain configurations. At a minimum I would be able to confirm if the same file with same settings causes the delay here.

Regarding your CPU load. Could it be the CPU itself?(I don’t know enough about instructions sets and architecture to say what is affected when). But judging by this thread (I did not read everything) it is not the number of cores itself that is the issue: DxO PhotoLab multi-core utilisation: Retouching Forum: Digital Photography Review (unless it got broken later)

In this thread we can see PL does not use lot of cores when processing one image.
I think DxO team fight against an old software architecture …