Sometimes when I export an image there’s a noticeable delay(about 5 sec) before the export starts, most times it starts the export right away. Anyone else have this?
I also have that, but only on the first export of the session, then the other exports starts immediately.
That’s normal. In my case (Windows/i7-14700KF+RTX 4070) exporting is handled by two DxO.PhotoLab.ProcessingCore processes spawned by PhotoLab.exe which have to be initialized first, taking 4 seconds. Probably the number of these processes is equal to the maximum number of photos processed simultaneously, configured in Preferences. You can check DopCor.txt log to see the timing details (checking CPU and GPU performance, initializing internal services). Next time they are used the init phase is skipped but still some database work has to be done (that’s < 1 sec in my case). These processes have “idle time” set to 2 hours, after which they wind down.
EDIT: DELETED being wrong (I think you need a batch export to make them stay in the background, single file export does not seem to trigger it.)
@Wlodek You need to do an export of any size to trigger the export worker. I just exported a single image and this is before
and this is the during and after
It doesn’t export without the necessary worker or so it appears.
You are right, even a single file export causes the ProcessingCore to stay alive after finishing the job, waiting for the next task or idle time expiry.
I just didn’t notice it during my first test, sorry for misinfo, corrected.
Thanks to all, this explains it
@jeffholdgate I believe but haven’t fully tested that you can change the edits while an export run is in progress and that will have no effect on the exported image.
If that statement is correct, it would imply that the preliminary part of the export is to capture all the edit data pertinent to the export(s) before the export actually starts?
Does the export process rely of what’s in memory, what is in the database, what is in the DOP or what it “squirrels” away before the export proper is started, or none of the above?
So a little test with some test data I have been compiling (mostly with CA/purple fringing)
- Use previous test directory which has been exported with 49 images.
- Start Export run and almost immediately
- Use a partial Preset to turn all edit options off!
Results the exported images look the same as the previous export and the files are the same size
So it looks like DxPL secures the necessary data for the export pretty quickly!?
The machine is a Ryzen 5900X with an RTX 3060 and all the data and the exports are coming from and going to a 4K/5K NVME.
Even if it’s true for some PL versions, that’s one of the things likely to change in updates without any notice.
@Wlodek I have held the opinion that DxPL checks for export duplicates and preserves the original edits for the export processes for some time, just not bothered to test it!
Because DxO publish so little about the workings of the product they could change almost anything overnight, so I made the post with the knowledge that it could change but thank you for stating it and I must admit that I am not a DxO employee and have no access to the code to verify anything I write!
In addition the original author of the topic is a Mac user and I am a Win10 user but I did a test and published the results and it is highly pertinent to this topic, i.e. it is part of the launch process of an export worker or workers, 3 in my case and a potential part of any delays.
Another possible cause for delays is whether DxPL forces any DOP writes before starting, although the Database and DOP will both be updated with the details of the export as and when the exported image is physically created!