DPL7 is sluggish

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 …

I don’t understand how

relates to

I can however imagine how this

can lead to this

Seems like it’s being reported with something 32 bit along the line. Do an online seacrh for that exact amount of GPU memory and you can learn more than I understand.

Indeed you should read messages in between (and/or around).
I agree, your summary is completely incomprehensible.

I should be in bed an not posting but need to get something done with time betwen clicks…

If you are seeing only 4GB where there should be more, it sounds like a 32-bit limitation. If you do a websearch for the exact amount you posted, you will find more information about misreported amount of GPU memory.

Guessing part of the software works in 32-bit.

I see the same with 8GB by the way (4095 in every one of those files).

1 Like

Didn’t thought about it. 32bit is so far now.

Why as operating systems change programs need to be reprogrammed to make effective use of the new norms (and clear out the old rubbish). Clearly PL is using some elements of current operating systems but appear to have put these on to the original programing. No wonder it cant make effective use of modern hardware and operating systems. Its the result of marketing needing new features rather than optimizing the basics and dealing with outstanding problems.

And for some softwares, writing everything back from scratch takes very long.
I remember softimage doing this to create XSI. It took about 4 years to write this very good software, but users and companies couldn’t wait 4 years and jumped to maya which appeared at the right time.
And now no more softimage and no more XSI.

But waiting too much to keep up to date often ends up with outdated software that can’t keep up with the latest hardwares when other softwares can …

1 Like

Which is why its such a bad idea to neglect updating basic elements of a program but just add bits to them.

1 Like

Root algorithms are big endeavors to take when you want to update. It took them several years to upgrade the Working color space which was hardcoded since DxO 4/5 era (2007 !), and was a slightly customized version of AdobeRGB (to say you are not using AdobeRGB). It was good enough for years, but along maturity came experienced users that wanted something else than just flashy sRGB files for internet. I think it is pretty much the same for processing. the DPCore instances that are launched during exports are obviously not very multithreaded. It surprises me because it seemed that even with 2 or 4 exports at the same time, I could get 100% load on my 6 cores intel 6850x, or 18 cores 10980xe, I will check and make more comparisons.

how about you switch OFF / disable all GPU in DxO PL and try to export files with all NR disabled - see if purely CPU load ( w/o AI/ML NR ) can be increased that way + try > 4 parallel processing

GPU execution units typically do not require 64 bits. I think most of them are currently 32-bits, while some registers are even smaller. For Ampere, see [NVIDIA Ampere GPU Architecture Tuning Guide] NVIDIA Ampere GPU Architecture Tuning Guide. For Ada Lovelace (e.g. RTX 40x0) it might be similar.

I will try to do that, but I am already late with our annual photo book and my wife waits for my exports :-). Kidding.

I use mainly canon R5 (45mpxels), still have some Pentax 645z (51Mpxl) files to process for some prints, some GFX100s files (102Mpxl) 1dxMark III and very recently R3. So three typologies of files : 20-24Mpxls, 45-51 Mpxl, and 100+Mpxls

Something also: I use a Eizo CG319x for my main edits and proofing work, so 4k display, and use also second 4k wide gamut Dell display for the picture selection windows. At 100% the soft has to display considerably more pixels (8Mpxl) that on a 1080p display (2Mpxls). So when I use local corrections + repair tool and alternate back and forth between the two modes it takes a lot of time and is very slow. A bit quicker with the 1dxMark III files (20Mpxls only).

I don’t know the exact details but it is a noticeably quicker when i disable OpenCL. I will make my next export with disabling the deepPrime XD support by the GPU during export to figure out.

Thank you but no more need to. I encountered it today after I had edited an automask, duplicated and inverted it, on a linear DNG exported from a stacking tool using RAW files - it felt like minutes.

Generally I edit the shots in PL and then stack. Today I was “inspired” by all the pain spoken of in relation to DNG here an thought I’d give it a go.

MAC users are reverting back to 7.1.0 (which also happens to be the latest version number for Windows on which I encountered the issue). 7.1.0 is the only one I have for Windows so I can’t try if an earlier version is better.

Also see here: "Correction Review" Keeps Sticking - #14 by User_Number_777

I am able to make it a bit slower with enough other local adjustments, but edited automasks make it really bad (It was worst with the DNG.)

I have just upgraded to 7.2 latest upgrade today, and I upgraded the nvidia drivers just after. I still have to have a full working session but in a CPU only setup (without OpenCL, RTX only for DeepPrime support)) I feel a noticeable upgrade in the responsiveness. instead of 6-8 seconds to go in/out the local adjustments mode I have 3-4 seconds now. It is better.
Still not as quick as I want but an improvement nevertheless. Has anyone similar feedbacks?

PL 6.11.0 window here (not 6.12.xx - I keep what seems to work and do not upgrade until new feature interest me - things are so volatile around here and I don’t like dangerous life … anyway not with my photo editing software) :

About 3 seconds too to create preview to work with local adjustments (just tested this now with a fresh image without any local adjustment - don’t know if this time increase when bunch of local adjustments are aplied - I think so but not sure).
45mp raw.

After a day long session of photo editing and process, I am sorry to report that what I initially thought to be an improvement did not confirm…at all. DPL 7.2 is still super slow when going back and forth local adjustment mode and with repair (rubber) mode. Adding a local (like U point) adjustment zone may take up to 7-10 seconds to display 100% ratio.

Sorry DPL Team but this is very very slow. MAJOR need of improvment.