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.
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.
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?
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 ?
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.)
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.
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…
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)
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…
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…
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…
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.
