There is no such preference.
I used the wrong terminology! You need to find the preference that specifies the number of simultaneous images to process. The more CPU cores you have the more simultaneous images you can process. My personal rule of thumb with PL is that the number of simultaneous images to processes should be half the number of CPU cores you have.
1 Like
Any way to mark the images and then selecting them later for export as group can only be a workaround. While I appreciate that people are trying to help (with workarounds I am already aware of), I’d really prefer a solution to the problem itself.
As mentioned before, queueing the images to be processed while already working on the next is a standard method which should “simply work”. Currently, it does not.
This one is set to 2 (default, apparently). It appears that makes sense for CPUs with 4-6 cores.
However, please note that the problem also occurs when there’s only one single image being processed, so it appears that the problem is not related to this preference.
I still assume that something is going wrong with internal multitasking as soon as DeepPRIME is used without GPU. Maybe something the developers didn’t notice since they all have GPU support, or did not test strong enough with working on the next images while the queue is being processed…
JFI: Reducing this to 1 does not change anything.
Edit: But I think the problem happens much less often then.
Maybe you like to have a look → Which Video Card? - #30 by Wolfgang and see, that DeepPrime makes use of the GPU. – When setting PL to “CPU only” it simply doubled the time with exports
( CPU comparison → UserBenchmark: Intel Core i5-10400 vs i7-8700 ).
When your GPU is supported by PL, better choose “Auto”.
My PC is almost 4 years now. For a really low noise machine I chose components with low power consumption (CPU 65W / GPU 125W max) in relation to output & price + low noise case & fans.
→ PL4 computer specs compared to PL3? - #38 by Wolfgang
→ Getting the PCspec right - #3 by Wolfgang
Specs are always a compromise, but I’m neither professional and nor ‘on the run’. 
With care (and backup) you could try editing DxO.PhotoLab.exe.config in the install directory.
Reducing the MaxExportProcessingThreadCount setting to less the the number of cores you have might leave more CPU power for the main program. You must also reduce the simultaneously process image count to 1.
It would likely be best to reduce the priority of the export process which you can do in task manager but only when it is running. Another setting DopCorShutdownDelay might let you keep the export process loaded for much longer meaning you only need to reduce priority once in a session.
That said DirectML which DeepPrime uses may take no notice of priority or thread counts.
I notice some lag in reactivity if a few local corrections have been used. Feels like PhotoLab is getting tired 
This might interest you:
It’s was more obvious in previous versions of Windows but now it’s buried deep down in there but still accessible
I know that DeepPRIME makes use of (and gets faster by) a GPU, but that’s not the issue here.
Well, that’s interesting. Thank you!
Yes, one can allocate CPU cores to particular programs - with several drawbacks:
- it’s uncomforttable (as you mentioned: buried deep down in the Task Manager);
- it can be done only when the program is already running;
- it’s not persistent, after the next reboot the settings are gone;
- it slows down the whole program, but without changing anything at the internal multitasking.
So it takes some effort, without providing any improvement.
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.
Good morning @Tilmann ,
Have you already created a support ticket for this issue?
Regards,
Svetlana G.
Not yet.
But I think it would be of some help if others (and you?) could try to reproduce the behaviour.
Perhaps using your GPU, even tho it’s not all that “powerful”, might alleviate your problem (?)
- Which GPU do you have ?
John M
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.
John M
1 Like