Were the earlier versions of Photolab even slower than the new 6.5?

I have felt quite a while that Photolab has become painfully slower and slower, especially when working in the contact sheet of Image Library, view selecting images or just walking through the images with the arrow buttons. Maybe version 6.5 feels a little bit more responsive at least in Customize View.

Export is not affected - it´s still fast.

It seems at least for me that using the “filmstrip” in the Customize view is considerably faster than ImageLibrary. Still it´s not all that efficient. Of that reason I have started to use the really good totally free viewer XnView instead. It also gives a much more efficient overview of the metadata status (EXIF, EXIFTOOLS, IPTC, XMP and GPS-data) than both Photolab and Photo Mechanic Plus. XnView has a very useful set of “flags” on the thumbnail images that gives me a possibility to check so I haven´t forgot to set any type of metadata. Either Photolab or Photomechanic gives me such a transparent control.

If I compare Photolab with Capture One the latter is far more responsive today. I think DXO have to address this ASAP.

I usually test DPL with 60 images and a new database. Doing this, the app is responsive and a joy to use.

After indexing 25k images, responsiveness is still good…but then it gets worse after customizing and exporting, e.g. like this:

  • Select image files, apply a preset, set denoising and export.
  • Repeat with different denoising algorithm
  • Wait until finished
  • Select exports from above and export again in different format or colour space

While the last step is executing, responsiveness of DPL turns to delivery times, even though CPU and GPU are not maxed out at all. Looks like DPL is standing in its own way somehow and that computer resources are not managed well.

After completion, overall responsiveness in customize and Library views stays bad.
Restarting DPL does not help in this case.

Caveat: The above reports a single test and is in no way a definitive result.

1 Like

MySQL Lite which is the database PhotoLab uses struggles over 25000 entries general. Mail Steward claims MySQL Lite will work until 50,000 emails and after that one must use Mail Steward Pro and do a full install of MySQL. Lightroom also had (may still have I don’t know) serious slowdowns with catalogues over 50,000 images. The solution here would be to delete the database entirely every now and again.

Some other tips which help with speed:

  • Restart PhotoLab reasonably often. Memory use on macOS climbs over time. Eventually the memory is released but it happens immediately if one just closes and reopens the app.
  • make sure to keep noise reduction off until you are finished the session. Apply noise reduction at the end, just before export.
  • repairs slow down image correction and quick preview. Do repairs last. Expect slow adjustments on an image with a lot of repair. Latest version of PhotoLab has much more powerful repair tools and relatively speaking the repairs slow down preview much less. I use repair a lot now (before PhotoLab 6 I’d have to take most serious repair work into Affinity Photo, not now).
  • local adjustments in some cases can also slow down preview. Doing local adjustments last is not convenient as local adjustments seriously affect the artistic integrity of a set of corrections. No real suggestions here, just something of which to be aware.

Others might have suggestions.

1 Like

My DPL database lists a tad more than 26’000 items in the ZDOPSOURCE table, as do Lightroom’s and Capture One’s databases. Alas, C1 and LrC seem to handle this situation much better than DPL, which takes away resources for user actions, which is poor practice or bad management by the OS. Some slowdown can be acceptable, but I don’t appreciate an almost unresponsive user interface (e.g. for changing the sort order or applying a filter in DPL), while processor load is just about 20% of what could be delivered.

One thing I have hard to understand is that it really seems to do quite a few things in the background despite nothing have changed with images and metadata and DOP-files. I could accept syncing when things have changed both not if it hasn´t.

There has always been a price to pay with integrated image libraries and converters in integrated software but normally since the beginning of Lightroom that has mainly affected the scaling of the images to high resolution previews like in Photolab 6. BUT, how to explain that it´s the “Image Library” that is way slower than the “Customize”-module when walking through the images with the arrow-buttons or just selecting different images with the mouse.

… and Alec, of course we can start to deactivate a lot of functions to improve the speed but doing so we are bound to forget what we have deactivated over time creating a mess for ourselves in the long run, for example when reediting or exporting.

Adobe and Capture One seems to have addressed these problems in some way but DXO has not and I don´t accept deleting databases of reasons like this. They have to start to use timestamps. Doesn´t MySQL Lite support that?? When I used Lightroom I had problems that were more understandable since they were related to rescaling of previews when editing the images but as written the case here is not that but just walking through the thumbnail images of Image Library.

I asked Bing Copilot if MySQL is supporting “timestamps” and got this answer:

" Yes, MySQL Lite supports timestamps. TIMESTAMP values are recognized by MySQL in several formats and have a range from ‘1970-01-01 00:00:01’ UTC to ‘2038-01-19 03:14:07’ UTC12.

I hope that helps! Let me know if you have any other questions.

Read more:

1. dev.mysql.com2. mysqltutorial.org3. stackoverflow.com

So DXO ought to be able to use timestamps or other techniques to deactivate processing on the fly when walking through thumbnails without having to delete the whole database.

25 000 images is nothing today. Personally, I have over 70 000 images now in Photo Mechanic databases and I am a photographer never taking more than two shots of the same motif. How unique isn´t that today when cameras are taking 30 images+ in one second?

Yes there is one way:

Use another application like Photo Mechanic or XnView or something else of your liking to select and “Open with” → Photolax.exe. If you do, you will get those images opened with Photolab instantly in “Customize” if both applications are open simultaneously and Photolab is in Customize-mode. Photolab will even automatically create “External Selections” in Image Library that you always can use to reopen that same selection whenever you like. Be sure not to use ImageLibrary because it is still as slow as it is.

XnView MP (multiplatform) gives flexibility to use it on several operating systems. According to the Copilot XnView MP is supported on Windows , Mac , and Linux in both 32-bit and 64-bit versions and it´s free without any obstacles or feature limitations.

Still it shouldn´t be necessary I think :frowning: but it is, since it takes about 2-3 seconds to walk between two images in my ImageLibrary and that is totally unacceptable in a workflow like this.

@uncoy The IMatch author suggests that his product, which also uses SQLite like just about every other product, which includes XnView and XnViewMP, should be able to handle 500,000 images or more and there is an interesting discussion about the search times for that product here Imatch performance.

@Stenis As far as I can tell the database hasn’t changed materially, i.e. the database specification for some/many releases, let alone sub-releases, has remained unchanged, so why should it be the culprit for any apparent slowing of DxPL?

Your workaround of submitting images selected in a third party product, e.g. XnView and XnViewMP (available of both platforms) or FastRawView is a viable workaround.

XnViewMP can submit tagged images (from some of my tests up to 280 or thereabouts can be passed in one go) from multiple different directories.

FastRawViewer can submit from only one directory, I believe.

My favourite viewer FastStone Image Viewer is only available for Windows and can submit many images but only the last of the group will make it to DxPL(Win), I presume because of the the way that FSIV is using the interface.

But these are workarounds, useful for the moment, but we really need an explanation from DxO @DxO_Support-Team, @Musashi as to what might be happening.

DxO have been silent in the forum for way too long while forum members are shouldering part of the burden of supporting each other and new members without any re-imbursement for the effort, even the courtesy of assistance from DxO personnel.

I do appreciate the various releases from DxO for PL5 and PL6 while they are working on PL7 development but forum members are “expected” to offer support without access to any DxO resources whatsoever!?

I would offer to try loading up my database with multiple copies of my 11,000 image bulk tests but I can’t be bothered and have other projects, like helping my son with work on their new house, mostly with moral support by being there from time to time, although it looks like my self taught plumbing skills are going to be put to the test soon!

2 Likes

This is exactly the reason that DxO should stay out of the DAM business, or hire a separate programming team to build a full-scale DAM module. Frankly PhotoLab had a great deal more integrity before DxO added the database.

Open a folder, read the .dop files into memory. Move to another folder, do the same. Arguably keep a cache of recently accessed folders.

On macOS, either NeoFinder is the solution (a file management solution with enough GPS and metadata tools to be able to work to manage archives of hundreds of thousands and even millions of images) or for people who want more intense DAM photo tools, Photo Mechanic Plus.

XnView unfortunately still stinks on macOS (very clunky and un-Mac like). Last tested a year ago, probably on your recommendation. Lyn
and Xee offered something similar on Intel Macs but after a decade of stability and regular updates neither have transitioned well to Apple Silicon and the latest macOS versions. For the last five years, Apple makes life really difficult for software developers, constantly changing API’s, making it difficult to build for more than a couple of versions of macOS. These barriers are gradually crippling the shareware and independent developers who made Mac OS and OS X amazing.

since it takes about 2-3 seconds to walk between two images in my ImageLibrary and that is totally unacceptable in a workflow like this.

Not running into this issue, but I only open a folder with a hundred or so selects in PhotoLab. The triage is all done in FastRawViewer ahead of time, so I’m only selecting among selects (goal is to cut the 100 down to 30 or 40 finished photos).