As a test please set the number of simultaneously processed images to 1 and try your export again. Your CPU has multiple cores and by setting the preference to 1 only one photo is processed at a time and only one core will be used and the remaining cores should be used for other work like developing other photos.
2 Likes
Both sentences are wrong.
In fact, your posts sound a little bit offensive, even if that might not have been intended.
And regarding performance, apparently you didn’t fully understand what we are complaining about, nor do you have any deeper knowledge about programming and multitasking technology. Please don’t post your personal assumptions as “immutable fact”.
Obviously it’s OK for you to wait until export is finished before you start working on another image - and we’re fine with that. But me and many others see that the current implementation has issues that can and should be fixed.
1 Like
If you had carefully read the previous posts, you’d have noticed that I already reduced the number of simultaneously processed images to 1 - without significant effect.
If you had carefully read the previous posts, you’d have noticed that the export process fully occupies all six available cores (with 12 simultaneous threads) when exporting one single image as well.
(What makes you think that only one core would be used when that pref is set to one??)
In the meantime, I had another idea regarding a relation between the internal PL processes. I will do a few more tests as soon as time permits, and then probably post my results again.
'Til then: Merry Christmas!
DxO have obviously multithreaded the processing of a single photo when using CPU only. Given the option to limit the number of simultaneously processed images I assumed that would limit the number of CPUs used.
It is possible that PL have got something wrong on your computer and is using ALL available CPU resources and leaving very little for other processes hence the slow responses.
You could raise a ticket and ask the question rather than try and get help on the forums.
1 Like
I never noticed this issue as I usually edit all images in one session and export as the very last step. During export I don’t use DxO and typically use others programs or simply let the computer do it’s thing.
However, it should be no problem for DxO to deprioritise the export process and allocate resources to the editing process when the user keeps editing. This would prolong the export process but would be overall more efficient.
I regularly work on photos while exporting and have never had an issue.
I promised to do some more tests… Here we go:
If an export with DeepPRIME is running, the UI stays perfectly responsive. The main thread gets as much CPU power as is necessary to react to the users operations quick and smoothly, including the main preview. If one doesn’t change much, the exporter thread gets almost 100% of the CPU, while with extensive changes of the settings the main thread gets about 10% or even 20% and the exporter thread gets what’s left. So far, everything’s exactly as it should be.
(A good and fast test: set manual exposure correction to maximum and then just turn this correction on and off in fast sequence…)
BUT: as soon as NR is switched to DeepPRIME for the currently selected image while the other DeepPRIME export is still in process, the preview freezes and none of the changes are applied. However, the controls themselves still react perfectly fine and fast, only the preview does not reflect the changes any more.
In my previous tests (and in the situation I described above), the copied settings (ctl+shift+C/V) included the DeepPRIME selection, so the preview freezed very early. When I copied settings without DeepPRIME activated, I could apply many other corrections and suffered the freeze only when finally selecting DeepPRIME for the export. (I think this effect was resposible for the first impression of some improvement by reducing the number of simultaneously processed images to one.)
Conclusion:
Setting the NR to DeepPRIME forces PL to immediately update the small NR preview window within the palette, and exactly this apparently is blocked by an already running DeepPRIME exporting process, maybe because some resources are used in common by these two DeepPRIME tasks. However, updating the small preview window seems to be a modal operation with respect to the main preview refresh, so as a consequence, the complete main preview update is blocked as well.
Svetlana @sgospodarenko , please carefully test this - I think the problem should be reproducible with this information. Take care to test under Windows and turn off GPU support, to have a comparable situation.
I think this is a general problem of PL and not related to my personal installation - so it should not need a support ticket, but instead be treated as a bug (and fixed with one of the next updates). Thanks for any feedback.
Comment: Personally, in this situation I don’t need the small NR preview at all (I know which amazing results I will get…) - if there’s any way to turn it off completely, I could live with that as a workaround for some time…
2 Likes
Does this happpen even if the preview isn’t in the display window because a different palette is showing?
I have just edited a batch of 54 images and all with DeepPrime (DP) enabled (I always have it enabled - no harm). Then I started a full-size export to JPG (all 30 MP) and the export took 3 minutes 53 seconds (4.3 seconds per image).
While the export was running I played with a bunch of 30 MP images that also all had DP enabled. I was able to change the exposure up and down with nearly no lag at all. I also played with all the contrast sliders and the same result. I also had no issue switching to other images and doing the same all while my machine was running full tilt.
Then I change the export from GPU accelerated (I have a Radeon 6700XT) to CPU only and then the export took forever as expected and editing of other files was very laggy.
So the solution is to get a decent GPU and relief your CPU to allow editing while exporting. DP is a heavy operation and optimised for GPU and not CPUs. So this result is no surprise.
I’m running a 3070GPU with 8GB of vram and 40 gigs of main memory with a Ryzen 5900 CPU processing 50MP images in 7-8 seconds and I have a terrible editing experience while an export is running.
So this is more than just GPU power. This is about thread priority.
Good morning!
Yes, I was able to reproduce it on one of the not powerful machines and even got a crash. We’ll investigate.
Thank you
Regards,
Svetlana G.
3 Likes
Can’t tell - in order to switch NR to DeepPRIME, the NR palette needs to be visible…
Interesting that after all detailed explanations, you still don’t get the point…
Please let me explain once more why I really don’t need a GPU. While an export is running, I am already working on the next image. With DeepPRIME, export takes roughly a minute. I often need that time to find the best corrections for the next image, so that fits fine. If I’m faster with editing, some more images are queued - if I’m slower, the export process shortens the queue again. At the end, only about one minute after the last export has been started, all exports are completed as well. That’s exactly the way the export queue works (and is intended for).
Adding a $$$$ GPU would change nothing except for reducing the absolutely uncritical time for the last export. And, what has been mentioned many times as well: it’s not a problem of processing power, but only a problem of thread priorities (or dependencies, eventually).
Luckily, Svetlana was able to reproduce and confirm the problem.
Well, I can edit images while a large queue is processing and get next to no lag. If I use CPU-only processing my system gets laggy as you described, so I can reproduce this issue.
Hence, I suggested using a GPU instead…
While this appears to be a “simple” solution, it ignores the cause of the problem…
I’d rather see this fixed instead of investing $$$$ for curing/avoiding a symptom.
1 Like
Just a quick remark.
PL5.1.1b52 Mac
I set 8 36Mpx images to export using DeepPRIME and then proceeded to continue editing one of them. No problem apart from the DeepPRIME loupe took some time to update.
… and the same goes for rendering previews in Library view…
Do you also use CPU only? And please try editing an other image, with DeepPRIME activated.
If that works without freeze/lag, you might have found just another Mac/Windows difference…
Here is my setting…
This time, I selected 24 images in one folder, set them all to DeepPRIME, started exporting and switched to another folder and selected a DeepPRIME image to try to edit it
The responsiveness depends on how many images I set to process simultaneously.
If I choose 1, the response to any edit is virtually instantaneous; and exporting 24 x 36Mpx images took 7mins 18secs.
If I choose 8, although the response of the tools is instantaneous, I had to wait 2 minutes for an edit to update the main image view; and exporting 24 x 36Mpx images took 6mins 36secs.
So, for the additional “speed” of running 8 exports at one time, I only gained 42 seconds over the 24 images.
Monitoring the memory usage shows me that each instance of XPCCore, which I am guessing equates to one exporting process, runs around 82-84 threads and PL5 is showing as using between 90 and 100. So, that’s an awful lot of threads (around 750) to be juggling at the same time on a 2.6GHz, 6 core i7.
My conclusion is, if you want to continue editing whilst exporting, reduce the number of simultaneous exports.
1 Like
I found the sweet spot for shortest overall export time to be around 3-4 simultaneous exports on my 8-core iMac - when batch-processing images. Interleaved editing/processing is not what I do, although it looks like a good idea under certain conditions.
1 Like