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.
DxO not responding is too be expected in this user forum. Nevertheless, you could try to collapse the denoising tool by clicking on its title bar.
When you first work on a cession, why not.
But when you come back (I more than often do this) on a work in progress or on an more or less old project, this is not doable.
DxO team should find a (GOOD) way to store preview and not run process already processed.
This is one of those things which make photolab very fastidious to use.
Unfortunately, you are right.
However, since they claim they are reading here, it’s their way of showing us how they think about their customers. It’s a matter of respect or contempt.
The same applies to bugs that were promised to be fixed many years ago and still aren’t. Or feature requests with lots of votes and years-old but yet unfulfilled promises for implementation. Or “feature requests” for in fact missing essential core functions that are simply ignored. Again, it’s a matter of respect or contempt.
That wouldn’t help anything since with collapsed denoising tool you also can’t select DeepPRIME any more…
…unless you make it part of a preset…
I mostly don’t use DeepPRIME, but when I do, I select all images (needing it), switch on DeepPRIME and collapse the NR tool. NR is the last thing I do before export. I’m more interested in the overall looks of an image than whether there is some noise or not. I usually leave some luminance noise anyway or add some grain (requires a FilmPack license) 
1 Like
OK, that might be some kind of workaround until that bug (eventually) gets fixed…
I will test if the NR loupe preview really is not calculated when this tool is collapsed.
(If only the display is collapsed this workaround wouln’t change anything either…)
I also select NR only right before export. I know what it does to the images and when DeepPRIME makes sense. However, since it takes some time to process an image with DeepPRIME, it is essential that this is done completely in the background without blocking the foreground process (editing the next image) only because of the small (and useless) NR preview loupe…
fully agree.
Load management has not been a strong part of PhotoLab so far and I doubt that it will be within the next few years. Until we get there, it’s good practice to customize all images first and export them together and do something else while PhotoLab crunches its numbers.
It’s exactly as I already feared. Selecting DeepPRIME while another image is processed in the background that also uses DeepPRIME consistently blocks the UI even if the denoising tool is collapsed.
So there’s not even a workaround for this serious bug.
And still absolutely no reaction by DxO…
how about 2nd GPU ? may be that can brute force through the problem ?
I don’t see why I should invest $$$ just to reduce the symptom of a bug which violates the functional specification of the software and for this needs to be fixed urgently anyway…
1 Like
In the course for an other test, I found that PhotoLab gets really slow after exporting a bunch of images a few times and with slightly changed settings. Neither CPU nor GPU were anywhere near what they can deliver, but overall responsiveness of the UI felt like molasses. Like something invisible eating resources in the background like undiagnosed cancer. Deleting the database and cache files “fixed” the issue though. I’ll try to reproduce and collect and add the diagnostics in due time.
Interesting - but apparently a different issue…
However, I think I know what the outcome will be - even if you provide exact information about which circumstances produce that problem. 
…but possibly caused by the same problem (ineffective resource management). DxO might profit from additional diagnostics. If it helps them, it can help us.
Anyways, I don’t see the effect you describe, but I do things slightly differently by a) not exporting images one by one and b) not engaging the resource monsters unless as a last step before exporting. Moreover, I find not much benefit in parallel processing and set the slider to process only 2 files in parallel.
1 Like
I’d suggest contacting DxO Support at support@dxo.com. Based on personal experience, you’re much more likely to get a response than from a posting in the forums.
So I wrote to support@dxo.com, just asking when that bug will be corrected - and got an automated reply with a ticket number.
Now it’s ten days later, and nothing has happened since then.
Surprise, surprise…
When there were DxO staff here they would usually pick up and chase poor support but now?
At least they have mentioned several times that they were reading here.
Assuming that they also read their support mailbox, this behaviour appears to be their way of telling us how they think about their customers.
I dont think its not been DxO staff saying they read the fourm but some users saying (hoping?) that they do. My feeling is they don’t do so.
1 Like