Performance Problem and Fix

Over the past few months, I’ve received quite a few comments on my website and YouTube Channel complaining about the poor performance of PhotoLab. It’s easy to suspect a hardware problem but then I also had the same issue. Photolab went from having similar performance to Lightroom to being unusable, often taking minutes to reflect a simple change. I couldn’t even browse through my folders and the software would also crash from time to time. This happened on both my Mac and Windows versions.

I finally tracked down the problem and a fix which worked for me and others.

In brief, when I checked my Preferences, I found they had been changed to apply a “DxO Standard” adjustment to all discovered images. Additionally, they were set to auto generate a dop file every time there was an adjustment. Something, possibly these setting or their effect, changed during an upgrade. When I changed my preferences, the software was back to normal.

I have also documented the fix in my blog ( in case the above isn’t sufficient.

If any DxO staff read this, please fix this in a future release. I think it’s costing you customers.
Thank you


Same here, my own preset was replaced by the DxO Standard for RAW.

I think my slowness is bound to memory, it hits 86% very frequently, 8gb.
Tuesday arrives my 32GB ram set so see what that does for my sluggy local adjustment modes.

I run PhotoLab 3.3 on an almost 4 year old Windows 10 machine with an older mid-level nVidia card and have no significant performance issues. In fact it runs much faster on my machine than ON1 Photo Raw 2020. Additionally, to the best of my recollection, a production version of PhotoLab has never crashed on my Windows machine, and I use it almost every day.

Can you share your Windows processor, memory, and video card details with us? Clearly something is impacting PhotoLab on your Windows machine but I’m pretty sure that the default DXO Standard preset or writing to dop files is not the root cause since I have been doing just that for the last two and a half years. Since I’m not a Mac user I can’t comment on any issues you are having on that platform.


Hi Robin. Reading from your blog post, I believe you have slightly misdiagnosed your problem - with implications resulting from the “fix” you have applied.

Paraphrasing your post (see link above), you observe;

  • You found PL to be VERY slow to start-up to the point where you could use it for editing
  • You found there to be many new sidecar/.dop files in the folder you had been browsing
  • Once PL completed the “background work” that you noticed, it was then normally responsive - until you pointed it at a new folder, when the slow-down was repeated.

Here’s the explanation for the behaviour you’re experiencing;

  • When PL is pointed at a folder of images, it firstly attempts to find the image listed in its database - if it finds an entry then the image is rendered using the corrections in the database.
  • If there’s not an entry in the database it looks for a sidecar/.dop file for the image (in the same storage location as the image) - and if it finds a sidecar file then the image is rendered and an entry is inserted into the database (and that entry will be used next time, as above).
  • If neither a database entry NOR a sidecar/.dop file can be found then it goes thru the process you described - That is; the image is deemed to be a “newly discovered image” and, therefore, a set of presets are applied, as defined in Preferences (DxO Standard, in your example) - with the results written to the database and, depending on your Preferences, also written to a sidecar/.dop file.

So, in your case, here’s what I reckon occurred;

  • Somehow, your database was deleted - perhaps as a result of a PL version upgrade, tho I think that’s unlikely (or, perhaps as a result of you making some changes to the storage locations on your PC ??)
    – Note: image

  • Also, you have not been saving correction settings in sidecar/.dop files - as evidenced by your observation that you found a lot of new dop files once PL’s “background work” was completed.

  • So, PL considered EVERY image it encountered to be a newly discovered image and, therefore, it embarked upon the worst-case (= most time-consuming) option for dealing with EVERY image in your folder … resulting in very slow start-up times for each new folder PL encountered.

The solution you have applied has some implications that you may not actually want;

  • It solves your immediate problem only because, for “newly discovered images”, you have specified that you want No Corrections to be applied - so, there’s now nothing for PL to do; and that takes no time !
    But, it also means that you will need to manually (and tediously) select & apply a set of corrections for each and every image - and, unless you’re diligently applying the DxO Standard preset, there’s the risk that you’ll forget important corrections such as Lens Sharpening, etc

  • Not saving your corrections to a sidecar/.dop file means you now have complete dependency on the database file - with negative implications, as you found, if the database is lost or damaged.

Comments re PL’s database;

  • Having entries in PL’s database enables the fastest rendering time for each image (unless its genuinely the first time this image has been discovered by PL).
    – it’s slightly slower for PL to render an image if it has to read the correction details from a sidecar/.dop (which is what happens if there’s no database entry for the image).
  • If you’re using PL’s DAM features then the database will be important to you because DAM keywords are stored in the database - but they are not written to the sidecar/.dop file.
  • However, some PL users (and I’m firmly in this camp) do not like being dependent on a “black-box” container for all the corrections applied to our images (because it’s pretty much impossible to recover from any loss or damage to the database);
    – Instead, we prefer to have correction details stored in the sidecar/.dop files - which are then stored directly and transparently along with their associated source files (RAW, etc).
    – Note: If a sidecar/.dop file exists for an image with no entry in the database then PL will automatically create an entry in the database from the sidecar/.dop details. Perfect !!

Recommended practice for optimal PL performance;

  • Don’t expect to be able to use PL simply for browsing images - because, even if database entries exist for all images, it will still take some time for PL to apply your corrections to the original source image in order to render the result … especially if the folder contains 100s (or 1000s !!) of images.
    – It’s better to process images in small batches of no more than a few 10s of images in a work-in-progress folder - then move the results (along with associated sidecar/.dop files) to your storage area … and repeat.
    – Use a dedicated image browser (of which there are many free ones) to view resulting images.

  • DO use the option to automatically apply a set of presets, such as DxO Standard, to each newly discovered image - as this ensures that PL’s essential defaults are always applied to all images (especially those utilising the Optics Module specific to the {body+lens} combo used to capture the image), and it saves a lot of manual work for you, the user.
    – Even better, take advantage of this feature to apply your own set of default corrections to each image - even if it’s just as simple as {DxO Standard + your copyright}. Eg. here’s mine:

  • Whether or not you Load/Save sidecar/.dop files automatically is a personal choice - with implications described above (see Comments re PL’s database).
    – My personal choice is that I most definitely DO.
    The processing time-cost of taking this choice is insignificant.

Regards, John M

PS. Apols for the length - but I often see comments about PL performance, and I hope this may help.

1 Like

Is this the Mac equivalent to those two checkboxes?

Good luck with the memory but I think it’s still worth turning the preset in the Preference to “No Adjustment”. The preferences filled my folders with thousands of dop files and manged to bring a top spec Mac to a halt.


Yes - - but, please do read my post (above) before you decide to switch them off … just to be sure you’re fully informed about the impact of doing so.

John M

Hi John,

A very well considered post but I want to highlight a few points:

  1. My software was previously set NOT to make any adjustment and NOT to write dop files. The upgrade changed this which I don’t think is good practice. Yes my solution has implications BUT I was well aware of these before I set it up that way.

  2. The database wasn’t the problem as you suggest. It retained the edits I had made previous to the upgrade and is still working. This also happened on both my Windows and Mac installations mmediately after the upgrade. I’m suspecting the bottleneck is in fact the writing of the dop files to the external storage but it would need more testing.

  3. I’m a professional Photographer and asset management is critical to my business. I have some 0.5m image files and I can’t go back through 20 years of images to restructure them into smaller groups. A good browser should allow me to browse these releatively easily. I do appreciate there is an overhead with the initial rendering of the RAW preview BUT this shouldn’t significantly impact the other functions.

  4. This leads to the final point which I don’t think you address. For PhotoLab to be a success it needs to handle a wide variety of situations. Users will all have different ways of storing and tagging images with different specs of computer. Everyone needs to be able to use it without having it restrict their workflow. Applying any preset automatically to discovered images and writing out the dop files brings the software to a halt on both of my computers.

Finally, I’m not recommending everyone reconfigure their preferences. Your configuration of computer and photo storage may mean you don’t encounter this. If you don’t see a problem don’t try to fix it. BUT if you suddenly encounter a serious performance issue that leaves the software unusable, try making these changes. And I still think its something DxO should take a look at.


The lag in responsiveness of edit sliders such as exposure seems to be caused by NR being “on” with the DxO Standard preset. If normal NR is “on”, it will cause 2 or 3 seconds delay before a slider becomes active, with Prime NR the time is up to 7 seconds. I have raised a ticket about that. My PC is a WIN10 i7 7600K, 16GB, 1080Ti.

1 Like

Thanks for your clarifications, Robin.

I did put a bit of effort into my post (with result that’s it’s probably a case of TLDR for some !!) - but I figured it to be worthwhile for readers of your “fix” to be aware of its implications - and to properly understand what’s going on “under the covers”.

Yes, it certainly does seem like that’s the obvious cause of the slow-down - but I am rather surprised that it’s had such a big impact. I’d be interested to hear about results of any further testing you may undertake.

Regards, John M

Hi again, Robin - I’ve been thinking some more about your issue …

In that case, your images were not newly discovered by PL - and, therefore, the default presets would not need to be applied - and, so, nothing should be gained by setting the defaults to “No Correction” (?)

Did you try applying your Preference setting changes independently, in two stages? ie.

  1. Save/Load sidecar files ON - and default settings = “No Correction”
  2. Save/Load sidecar files OFF - and default settings = “DxO Standard”

The results from this test might be enlightening.

Regards, John M

Hi John,

I don’t think I was making myself clear in my reply. The already discovered images were already in the system but that’s a small fraction of my collection. The performance impact came when I went to a folder of images that I hadn’t previously browsed.

Yes I have tested the two settings separately. There is a performance hit with both but it’s more noticeable when the dop files are being created which is why I said I think it’s the bottleneck.

BUT ultimately I don’t want any adjustments applied to the images. I want “No Adjustments” so I can start each edit from scratch.


hmm is did a system support run for updating my pc software drivers and my Bios was a bit “old”
v04 to v13… updated.
much less sluggy already!
no spinning bolls.
Do a export test with old 8Gb ram and then again in 32Gb config:
Smacked to the ceiling!! :joy:

Edit: clean house of desktop , dust!!! its a vacuüm applience down there… :roll_eyes: placed 32GB
and rerun the test:

( i topped my cpu at 88% for video rendering purposes so it could run long time without overheating. and after cleaning i think i can go back to 90-95%.

Well memory wasn’t a issue here. LOL


It’s me again, Robin … I really don’t want to be harping on like a p-i-t-a !! - but this is an issue that’s oft reported - and, with your high profile, I reckon a lot of people will be taking notice of this thread … So, I’ll persist if you don’t mind too much :thinking: … I’m genuinely aiming to be constructive.

OK - To clarify, I’m assuming you mean that PL has never before encountered this folder of images and, therefore, there are no entries for these images in its database, and there are no sidecar files in this folder. I’m also guessing this folder contains 100s (or perhaps even 1000s) of images (?).

I’ll emulate that scenario on my environment (a reasonably well configured Win10 PC: i7-9700 CPU @ 3.4GHz and 16GB memory - I’m using PhotoLab v3.2.0 - Build 4344)

  • I created a new folder - and moved 1000 RAW files to it, nothing else
  • I deleted my PL database, to be sure these images were not represented therein
  • I changed my default presets back to DxO Standard
  • I pointed PL at this folder … and waited 32 seconds for the Image Browser to complete loading all 1000 thumbnails. (Note: I’m still in “Photolibrary” mode … not in “Customise” mode)

My test preferences are: image
The seemingly “obvious” conclusion from this test is that my PC is 1000s x times faster than yours … which I reckon is highly unlikely ! … But there’s more; I then checked the folder contents, and found nothing there but the 1000 RAW files I had moved to it … no sidecar files.

I then chose one image and switched to “Customise” mode:

  • I made a simple slider adjustment - and closed PL
  • I checked the folder and found only one sidecar/.dop file … for the single image I had corrected.

Conclusion: I’m really puzzled - - Your experience matches that of others, but I cannot emulate it.
Can you see anything in my methodology (above) that’s different from what you’re doing ?

Regards, John M

PS. @sgospodarenko are you able to add any insights to this ?

1 Like

I noticed that before. PL is just writing dop-files when an edit has been done. Applying a preset is not considered as an edit.
One can browse both in the library or customize environment without dop files being written.
I think just because a single preset isn’t written in the edit list. When I change preset though, an edit is done and the dop file is written.
I think I’ve to investigate what happens with my existing edits when playing with the preferences.


This post is not directed at you, Robin - - as I know you’re an experienced PhotoLab user and you know what you’re doing … This is directed at others reading this thread, who may be considering following your example.

One of the “killer features” of PhotoLab is that it’s able to apply corrections specific to the {body+lens} combination used to capture the image … especially for RAW files. Each time PL detects an image captured with a not-seen-previously {body+lens} it offers to download a matching Optics Module for this new combination.

PL does not simply/crudely allow for generic corrections for a given lens - its Optics Modules contain information that can be automatically applied to correct known aberrations related to specific {body+lens} combinations.

So, if these corrections are not applied (because a user has opted to choose “No Correction” as the default preset - AND then forgets to activate these corrections manually) then you’re missing out on one the key reasons for using PhotoLab in the first place.

  • The main/critical correction in this category is Lens Sharpness
  • Another is Distortion - for correction of “pin cushion”, “barrel” & “fish-eye” lens distortion, etc
  • And another is Vignetting correction (for dark corners cast by some lens configurations)

John M

At least you’ve got some new memory and you know that’s not the issue.

1 Like

I often add photos to a folder. I keep them by date. Often pl is open, but I weed them using fastview. Thus the images are seen by pl not corrected. I never get dops befor editing doing this. I may be adding to the database which is why I try to not do it.

Hello John,

The behavior you describe above :point_up_2: is the one expected on Win - we do not create any sidecars unless the image is changed (different from default (preset selected in preferences) corrections are applied).

As for @Lenscraft, it’s for Mac team to investigate and reply.

Svetlana G.

Thanks, Svetlana - but Robin/@Lenscraft says he experiences the same problem on both Win & Mac.

John M