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
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.
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.
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
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”.
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
Should I have mentioned that while exporting PL was not responding to anything? Oh, I did…
What file types were you browsing?
Lumix RAWs, can’t remember if it were the 24 or 46 MP. All or most of them already had their .DOP sidecart
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?
Oh, yeah, we’re here in the work(around)shop. 
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:
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
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
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.
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?
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.
I’m not sure which thread you’re referring to, but the current issue is not supposed to cause any crash, only delays.
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.
Hi
In terms of not powerful machine, i am a expert 
I have same thing - takes me 13 mn to process dp pic so i don’t use it often, but it reminds me of a comment on a beta. Either issue was always there or regression occurred lately ?
1 Like
Several months have passed by since then, however the problem persists. It’s a pain in the a… if you are working on a larger number of images that were all taken at very high ISO and need DP denoising.
@Lucas: What’s your current time frame for finally fixing this?
(Please remember that this bug in fact disables the image processing queue, which is a very fundamental and essential functionality!)
As a first (and maybe quick) workaround it might be helpful to provide any means to turn off or disable the loupe preview window. When I’m working on a photo taken by ISO 10k, I know how it will benefit from using DP, even without having a (small and slow) loupe preview. So I’d just need some means to turn DP on, even without loupe… (Which is currently impossible, since the loupe preview is expanded with the denoising selector.)
More than a year later, and still not even any response from DxO.