Extremely slow UI responses when using DeepPRIME

DxO PhotoLab
61

Unless you explicitly select “CPU only”, your further tests are absolutely irrelevant and do not make any sense. I think that should be perfectly clear after all the previous posts, which I assumed were read by you.

Also, this is no challenge for selecting and exporting as many images as possible with a single command. The problem clearly described by me already shows when exporting one single image and editing the next (with DeepPRIME on for both), and with the number of simultaneously processed images also set to one.

1 Like
62

Hey, fella, I offer help to one and all. If you don’t like it, just be polite and either ignore it or just say thanks.

In your first post, you state that you are using an i5 processor, which might work but it is not the i7 which DxO recommend. They also recommend a GPU, which you do not have in your present computer. My Mac doesn’t have an external or additional GPU, it’s just straight out of the box like it is.

It would seem that your computer doesn’t meet the recommended specifications for running PhotoLab - why are you surprised it doesn’t handle such a demanding scenario?

From their website…

  • Recommended system configuration:
    • Intel® Core™ i7 4th generation or better, or AMD Ryzen™
    • 16 GB RAM
    • 6 GB available disk space
    • Windows® 10 version 2004 or later
    • NVIDIA GTX™ 1060, AMD Radeon™ RX 5500 or better with latest drivers

PhotoLab works fine on lesser specification machines - just not doing everything you want to do at the same time.

Of course, you could always stop using DeepPRIME if speed is that important. Or use one of the other methods for circumventing these problems like creating a project of all the images you want to process and, when you have finished editing them, select all and start exporting from there.

It seems like you are trying to drive a 2-wheel drive vehicle up a mountain when you know full well that you need a 4-wheel drive. And that is not DxO’s fault - they made it abundantly clear that 2-wheel drive might get you there but, just not as easily or quickly.

4 Likes
63

After all that has been written before, I thought you’d understand what the problem is all about…

First of all, I really appreciate any help, yours inclusive. Really. However, I explicitly asked for verification with “CPU only”, since it has been found out before that the problem does not happen with GPU support. Even more tests or numbers generated with GPU support don’t provide any new or helpful information.

Second, please don’t look at the “recommended” system configuration only, but also at the minimum supported (!) system configuration, which is “Any CPU supporting SSE 4.1” with 8 GB of RAM and no GPU. My i5 system is far beyond that, and in fact it’s not much slower as an i7 anyway. Of course an i7 system might be yet 10% or even 20% faster than mine, but that’s no reason to throw this one away.

Third, we have discussed endlessly that a GPU speeds up export, particularly with DeepPRIME. Yes, I know that. And I have repeated many times that this is not the point here. Of course, DeepPRIME also works without GPU, and it provides exactly the same results (in more time, which also is not the point here).

The problem definitely is not that my PC is not capable enough for that job. It has been mentioned many times that the problem lies at the multitasking within PL. And it’s also perfectly clear that simply not using DeepPRIME is no solution as well.

With your arguments and your comparison (in that latest post), you are just plain wrong.

I really appreciate you’re trying to help, but if you want to contribute to the discussion at the current state of information (and after the problem has also been confirmed by DxO), you could run the test exactly as described and without GPU support. That way, we might find out if it’s a Windows only problem or if it happens on a Mac as well.

1 Like
64

Ran a short test i the way of how @Tilmann works. PL is a pain to work in this way.

If DxO can improve the situation with redesigned resource management, fine. If not’ I’d be not really concerned. Nevertheless, any improvement of the UX is welcome.

2 Likes
65

I just tested exporting a DeepPRIME file on my friend’s iMac 27" 2012 with i7 4 core, 8GB memory and a non-compatible GPU (thus CPU only).

Just starting PL5 shows memory consumption of 1.7GB and around 80 threads running, with nothing going on. The preferences show that the most images I can export at one time is 3, so I set it to 1 for the test. Choosing the GPU is a waste of time as it is marked as incompatible and, if I do select it, the whole computer slows to a crawl when exporting, if not virtually stops working until I can patiently wait to cancel the export. So I change back to automatic (CPU)

Exporting then adds the XPCCore process with around 1GB of memory and around another 80 threads; and PL5 memory shoots up to 2.5GB.

Then I change to another thumbnail and try to edit that image.

Result - All tools still react instantaneously but the main image doesn’t update either for minutes or until the export finishes.

So, yes, it is a problem of PL5 on underpowered computers not being able to do much when exporting, even on underpowered Macs.

Nonetheless, @sgospodarenko has confirmed there is a problem and we now have to wait for them to see if it can be sorted out.

66

Thank you very much for testing!

No. This is not a problem caused by an “underpowered” computer (and besides, mine is far from being underpowered…). I clearly proved that the problem is caused only by setting DeepPRIME for the currently edited image which causes the NR loupe window to (try to) be updated, which then locks something internal within PL. As long as DeepPRIME is not selected, the UI is perfectly reactive to whatever I do during exports. I didn’t expect this is so hard to understand…

But yes, I’m eager to see what DxO finds out about this.

67

I have this problem on a beefy computer. With a powerful GPU. (RTX3070)

Anyway DXO employees have verified it and are investigating so I don’t know what you’re going on about telling us all we are doing it wrong.

1 Like
68

Yesterday I exported 10 16bit Tiffs. I don’t think DeepPrime was on in each of them nor the images I liked to look at (no editing involved) during export. I didn’t do all in one go, mostly two or four in one export.

During export PL 5 didn’t react. Minutes after the export officially finished I tried to scroll in the undocked image browser. 5-10 seconds no response, then a big jump, pause, another jump. The last update 5.1.1.52 made things worse, was my impression.

PL5 is hosted on a core i9 iMac with 32 GB and Radeon Pro 575X 4 GB. I don’t know why PL5 stutters to the point I had to close the app as it was no longer reacting, but I can compare it’s performance to that of Capture One and the comparison is not to PL’s favor.

And when I read all the “workaround suggestions” of long-time PL users I see a lot of blind love for a product and no insight that there are users who want to work. Without “around”.

69

Maybe that is another issue, not the one of this thread.
For example, some kind of freezes are reported for PL5: Upgraded to PL 5.1 (Elite), now freezing periodically

70

Should I have mentioned that while exporting PL was not responding to anything? Oh, I did…

71

What file types were you browsing?

72

Lumix RAWs, can’t remember if it were the 24 or 46 MP. All or most of them already had their .DOP sidecart

73

Unfortunately, because I rarely have more than a few tens of files in any one folder, I don’t see any hesitation, but I do see turning circles, showing that the rendering from preview JPEG to full edited preview is happening. But that is on my “more powerful” Mac.

When I was first writing my own browsing/keywording app, which can browse flattened folder hierarchies that can contain thousands of files in one view, even though it was only ever showing JPEG previews, there were significant pauses, especially when scrolling at speed. My findings were that this is a limitation of the operating system because, even with adding caching and look-ahead loading, there is just simply too much data for it to render quickly enough.

I will emphasise, this is purely using the macOS APIs for loading thumbnails with absolutely no treatment at all and after I had switched development to Catalina, which gave me access to an improved thumbnail rendering algorithm.

If you scroll slower, does the pausing get less?

74

Oh, yeah, we’re here in the work(around)shop. :grin: I would have liked to scroll slower, but if the library browser window doesn’t react for 5 - 10 seconds there are already some scrolling commands in the queue. I ended up with “screw it, shut the bloody app down.”

Capture One is more comfortable. If it gets nervous, it just shuts down by itself, no additional user action necessary. Of course, after restarting I need to recap the last 10-15 actions I did because usually being in that panic mode, the app forgets some of them.

So, all spectacularly good. One app keeps my memory in shape, the other asks for flexibility in finding complicated workaround for simple hiccups. Sudoku is not the only way to keep the brain sort of fit when aging…

EDIT: Here’s what happens in C1 if I select 9 images to get half-size TIFs exported:

Bildschirmfoto 2021-12-29 um 12.23.00
Bildschirmfoto 2021-12-29 um 12.23.00588×692 34.1 KB

If anybody is wondering why I call programmers usually “gameboys”, some of the reasons are here. But then, after successfully exporting (yes, that also happens) it opens the printer app or JPEGmini or Affinity to stitch Pano or Focusstack. It’s crashing on a higher level.

1 Like
75

Hello everyone,

We do confirm that there is an issue if you have the loupe set on DeepPRIME while an export with DeepPRIME is in progress.

You may try the following workaround: ensure that the denoising palette is either disabled or set to HQ or PRIME before changing a slider on the current image (ie. before getting blocked). If you move to another image, the correction must already be in this state too on the target image (by applying a preset before moving to it for instance).

The issue is present both in Windows and macOS, and whatever the device used for DeepPRIME acceleration, but it is much more visible when DeepPRIME processing is slow, for instance with CPU.

I cannot give an estimate for a fix but we are aware of the issue.

Lucas

7 Likes
76

Well, this matches my observations - but this can definitely not be called a “workaround” IMHO… Particularly if you proceed to an image that by chance already has DeepPRIME selected, you’re trapped.

Thanks for the confirmation though, and please assign this issue a reasonable priority. As it’s now, it makes the (extremely important and valuable) export queue concept completely disfunctional.

77

Yeah. Hopefully this can be fixed soon.

So to further the workaround perhaps the right thing to do is do all of your edits with the noise reduction adjustment switched off. Then select the first group to export and switch NR on and start the export. Then continue editing the rest of the images which have NR disabled. And repeat.

And hope you don’t forget to switch it on before one of those exports.

Thanks to DXO for confirming. @Lucas is this also related to the crashing while editing during exporting which was reported in other threads?

78

That’s exactly the way I work now… (after I found out the relationship to the NR loupe.)
But this is not something one can get comfortable with.

79

I’m not sure which thread you’re referring to, but the current issue is not supposed to cause any crash, only delays.

80

Thanks for the reply. Got it.

This was the one I’m referring to. And for me this is the bigger issue because I can’t continue to edit more than a few minutes while exports are happening anyway.