In this situation the problem is likely reproducible here, even if the number of images to process simultaneously is set to 1:
In a series of similar images, apply the required settings (including DeepPRIME);
Copy the settings (shift+ctl+C);
Start the export of the first image;
Quickly proceed to the next image, apply the same settings (shift+ctl+V) and start the export;
Try to select any other image in the filmstrip.
As long as the first export is still in process and the next one is put into the queue, there is no further response at the UI until the first export has been almost completed. At that moment, the latest selected image suddenly appears in the main window.
Maybe this can help others to reproduce the problem, and the developers to locate the cause.
(I did not yet try to reduce the MaxExportProcessingThreadCount setting in the config file.)
I also have this issue, preview is extremely slow if export is in process
v4 doesn’t have this issue, preview won’t lag during images are exporting in background
I guess the DeepPrime utilize all the GPU cores, and cause lag and slow preview
It’s better to utilize CPU for preview if GPU is busy for DeepPrime, or keep a small number of GPU cores in idle state, ready for handling preview image
Another observation, even if only one image is to process (without filling the queue):
At the very beginning of the export process, the UI is still perfectly responsive. I can use Shift+Ctl+V to apply settings, and these take effect immediately. However, at some stage of the export progress (roughly at 20 to 30% in the progress bar), there suddenly is no reaction any more. I can still move sliders (and the displayed numbers change accordingly) or turn controls on and off (with correct visual feedback) - but (only) the preview does not reflect the changes any more. But then, at a certain stage of about 90-95% in the progress bar, all outstanding changes are suddenly applied to the preview.
Apparently, the export process with DeepPRIME consists of several phases, and not all of them ignore the other threads that need to be worked on for the preview. Also, the threads that are responsible for the controls themselves appear to be always processed correctly.
This is common. Photolab doesn’t seem to do much prioritizing of the UI during exporting. It seems the Exports are handled by other processes. I wonder if it’s as simple as photolab spawning off the helper processes that are attached with exporting images with a lower process priority (“below Normal” instead of “normal”).
My current problem is that Photolab crashes when I try to continue editing while exporting since v5.1, so the UI priority doesn’t much matter as I have to take a break anyway. It’d be nice to be able to continue to edit with good performance while exports are ongoing.
That’s a good point, Mike - they are indeed … Which suggests that the core thread is simply fighting for limited resources … esp. when DeepPRIME is being handled entirely by the CPU.
Only the one internal to the i5 - I think that does not count as “GPU”.
Please let me repeat that I don’t mind if processing takes longer than with a powerful GPU.
Indeed, the “ProcessingCore” takes all available CPU resources.
And, interestingly: WTF are those six (!) Microsoft Edge threads??
Yes, that’s true. And that’s the normal way any raw developer works. At least, since I started raw development about 15 years ago, it has always been that way - regardless of the software used. This is an absolute “must”, it is mandatory to be able working on the next image while an export is being processed.
Also note that even during DeepPRIME export, when the UI of PL does not react any more, it’s perfectly fine to continue using other programs - they still react in real time, with only very small lags sometimes. So the problem definitely is not a problem of the resource scheduling by the OS, but only a problem of the internal multitasking priorities (or lack thereof) within PL.
I consider this as a bug which should urgently be addressed and fixed.
Further since deepprime uses mostly the discrete GPU and the GPU is mostly idle during editing I thought there would be some extra CPU cycles that could be used for the UI and further edits while the exports were happening. The CPU loading is not 100% when I’m exporting with DeepPRIME.
Separately I don’t have any “edge” processes tied to Photolab in my task manager.
Deep PRIME uses a lot of computer resources. You need to decide if you want the best noise reduction results or to bend your PC’s technical performance to the way you THINK it should be. You aren’t going to have both, it appears. When I use DeepPRIME I sit back, look at emails, check the weather, etc. while the process is working. Forget continuing to work in PL when DeepPRIME is processing. If it bothers you that much, don’t use DeepPRIME. Sorry, but I have little patience for people who bitch and moan over things they cannot control AND KNEW THEY WERE GOING TO HAPPEN BEFORE YOU STARTED! Learn to live with it or find another hobby. DxO warns people that DeepPRIME uses a lot of resources, so accept it or not, but you’re not going to find a solution here. No one, not me, not anyone, has a solution to this situation.
I run PL on a MacBook Pro, 2.3 GHz 8-Core Intel Core i9, 2019, 16gb RAM, 500tb SSD. One 50mb image takes about 30-45 seconds to process on DeepPRIME on my machine. It’s going to be proportionately slower on a lesser machine. No amount of fiddling with Windows settings is going to make it do otherwise.
Why the attitude?
Sorry but this management of limited compute resources stuff has been solved decades ago.
You don’t know how I work. Please don’t tell me what I am and am not supposed to do while PL is exporting.
Export is not a modal operation. DXO allows the user the edit other images or even the same ones you’re exporting. This has always worked. We are just suggesting the performance can be improved. And my machine is plenty beefy enough. 50MP images DeepPRIME in about 7-8 seconds. And UI updates sometimes take 20.
If it doesn’t affect you, scroll on by. But please don’t tell me or others how we should or shouldn’t use the software.
There’s no attitude. I simply stated an immutable fact regarding DeepPRIME performance. And I never told you how to work. I simply told you how I work.
If your machine is processing 50mp images in 7 to 8 seconds, then what is the basis of your “problem”?
Of course performance can be improved, and it will as time and different versions advance.
I guess I don’t understand the basis for your post. I re-read it several times and it’s evident you are troubled by the performance of your machine while processing images in DeepPRIME.
People here are a great bunch, and are trying to help your issue, but I don’t think you have a problem that can be fixed is my only point. Seriously, and I mean no disrespect or “attitude”, but how is it a problem that your 50mp images are processing in 7 to 8 seconds? DeepPRIME does not display it’s corrections in the UI until the entire image has been processed, which, as many here have stated, takes at least 7 to 8 seconds. My machine takes longer, actually, and I’m not troubled in the least. For me, it’s worth the small inconvenience of waiting for the best results possible in any software anywhere.
I think the suggestion here is if I edit 100 images and export them, during the 6-7 minutes that PL is exporting I want to start working on the next 100.
AH!! No wonder! Processing 100 images and running the export process on them all in one bite is your problem!! Not that it doesn’t work, because it does, but if you are running DeepPRIME on them all, then it’s going to be roadblock city in your CPU performance… I really don’t think there is a solution other than patience. You’re holding 100 images in RAM and that alone will choke your performance. Now I understand your problem!
Not holding 100 images in RAM. That’s not how it works. They are in queue but not all loaded into RAM. (I have 40GB anyway so that’s not the problem even if they were.) I’m telling you this is manageable with process priorities. And I think the suggestion by me and the others in this thread is that the process management is looked at for possible improvement.
I realize 100 images are not in RAM simultaneously, but they are going into RAM in batches as they march forward in que to be processed. PL is a resource hog at best, and I agree that they should take a look at better resource management, but NOT at the expense of quality. I shoot basketball at 6,000 ISO and run DeepPRIME on them all, processing about 40 or 50 at a time. I don’t fight the battle; I just go refill my glass of tea, stretch my legs, pester my wife and generally find something else to do while it’s processing. I do see that others might want to keep working, but I’m more concerned about quality results than efficiency of resources. I may well be in the minority in that regard!
It’s kinda like the community of photographers that focus so much attention on the speed of their printer. I’ve never understood that. If it takes X minutes to generate the finest result, then that’s what I accept; quality supersedes speed for me in every consideration.
I’m not suggesting to sacrifice quality.
I’m not asking to speed up DeepPRIME.
I’m simply asking that the processes be deprioritized to give the UI better responsiveness.
I don’t think anyone was suggesting the quality of the output should or would suffer by a priority change.
