DxO PhotoLab vs Lightroom Classic – using PhotoLab for cataloguing

This recently published article may be relevant for those considering this question.

John M


So that PL can compete with LR on projects/collections, it’s missing the Smart Collection.
Being able to make it automatic the filling of projects according to criteria would be a good step forward.


For me, the question can now be answered with a simple “no”.

As with Lightroom, PhotoLab’s cataloguing basis (including finding files) is the database and it is DPL’s weak point imo. As of today, the tools to keep the database consistent with the photo archive/folder structure simply don’t exist. Maybe, a future release will cure those shortcomings, but will it be done in DPL 7, 8 or 27?


The article is written by DxO or for DxO? Mostly wishful thinking, I’m afraid. And Album + projects only for organizing is a bit very basic. Without intelligent albums, the whole point of cross-referenced files has too much obstacles to overcome. I fully agree with @platypus .


Guys, I think this article really has a few points and there are a few I can add myself:

The article states
" It depends on your approach to image organization. [Lightroom Classic](Adobe Lightroom Classic review (2022) - Life after Photoshop) works with catalogs, or databases. You have to import images into the catalog, and while you can move, rename and edit images within Lightroom and it will keep track of them perfectly well, if you move, edit or rename images outside of Lightroom, it will lose the link to the image file(s) until you manually reconned them or synchronize your folders. Lightroom does not offer a constant ‘live’ view of the images stored in your folders.

DxO PhotoLab 6 does. At hearts its PhotoLibrary window is a simple file browser, albeit with additional search and filtering tools. This is more likely to suit users who are happy to organize their images in folders and know where to look when they need them. It shows exactly what’s in your folders at any one time. "

I can agree about that.

The article leaves the metadata without any deeper thoughts. Lightroom lives very much locally in itselves. Exporting metadata was something you actively had to do in my version 6.x if you wanted to migrate for example that was not maintained on a regular basis outside the database which might cause problems at a crash if you haven´t got a working backup. In version 6 of Photolab XMP-metadata is now maintained continuously outside the database of that reason Photolab is easier to scale than Lightroom with any other software supporting XMP and if you do you might get an XMP-based metadata database that is much more powerful and flexible than Lightroom is and you can still enjoy the better image quality and have access to Deep Prime XD and a seamless integration too with other softwares.

I also think that one of the really strengths of Photolab is that it will always be in sync live with your files down to the folder leve except with the metadata but if you build your folder hierarchy with some care that´s no problem at all. Because it´s very easy to get in sync again. It´s just to point to the topfolder and make a “Reindex” and you will be on track again. I have personal experience from having to consolidate my image data that once was spread on several discs to one with Lightrrom and that was some work to do.

I felt that it was easier with Photolab and even easier with Photo Mechanic Plus integrated with Photolab because with PM Plus you get the flexibility to use several databases at the sametime that gives a possibility to cross query them all together or any of them with just a click in a few checkboxes. A solution like that scales much better than Lightroom and can handle far more images without any performance problems and a solution like that will solve all the other limitations of Photolab the article is talking about concerning smart folders e.t.c.

So, for some people Photolab can actually be a much better choice for their needs than Lightroom is. I´m one of them. For me Lightroom is far to inflexible and too much of a single point of failure with it´s monolithic inflexible database.

There are still issues with the metadata that has to be fixed and the export of the keywordlist is a crucial one… Capture One has a feature for that and DXO ought to look at their example.

Another is External Selections. Everytime you select a set of images in Photomechanic or any other tool in order to open Photolab with that selection on the fly, Photolab will save a history of those earlier selections. It´s really like a virtual catalog too. What i would like to propose for DXO is to make it possible to rename those. Today you can´t because they are just saved by day and time. You can delete them but that´s all. This could be an even more useful feature if it was just refined a little. This is one of my favourite features today despite it´s present limitations

I suspect this very useful feature might be totally unknown by many today.

I feel a little too much criticism is levelled at Lightroom when it comes to “hanging onto” your data or files.

It used to be everyone said Lightroom could ONLY import files into its own, managed locations. While the import step is always required, it does not need to involve moving files at all. It has always been able to “manage by reference”.

By comparison to this, PhotoLab gives the user no choice. You have to manage the files yourself. If you’re in PhotoLab and want to move a folder, too bad. You have to go to Finder/Explorer to do that.

Now we talk about “the database” and metadata. It was never difficult to write the metadata out to file. Lightroom would put one of its many symbols on the thumbnail to tell you it needed writing. You could even filter by that status, then select all and write to file. If you use DNGs, they’re written right into the DNG files themselves.

I get that some people prefer the way PhotoLab works, but it works one way and one way only. Lightroom is mature enough that apart from requiring the import step (which isn’t really much of an imposition in my view) it lets you do it whichever way you want and is more powerful and (as a manager) is substantially faster to use.


What I didn’t understand with dxo search, as there is no catalogue, how does it limits itself to your pictures?
I mean, if I accidentally clicked on a folder where I’ve got some images that are not originals (exports, or downloaded pictures), are they part of the database?
Would they show up in the search results?

Normally there would be no need at all to move anything outside a folder centric Photolab structure. It is most rational in all handling of DAM-data to keep a structural growth under one common top folder just because that will be the most efficient way to handling indexing.

Concerning Lightroom nobody has claimed you can’t export XMP the problem is that XMP doesn’t own the metadata on Lightroom, since the database does. Then Adobe has created a single point of failure when it comes to metadata. In Photolab and all other serious DAM-systems the metadata is owned by the images themselves when it comes to TIF, JPEG and DNG and when it comes to RAW normally as side cars. It is a far more robust way of doing it with distributed data model than in a monolithic database. With that I don’t mean the images themselves have to be stored inside the database. The problem is that it’s the database itself who owns the metadata and it’s an active action needed to export it to the files.

Both Lightroom and Capture One these days are pretty flexible when it comes to where the images are stored and they had to change of performace reasons. C1 also have a posdibility to use sessoons whick I always have prefered with that software.

… but there is a catalog and metadata is stored both in that and in XMP in side cars or written into the images headers and the files carries the masterdata. The database is used for the searches but the files owws the XMP- metadata.

Photolab is not a general filesystem that handles all your files data. It only handles the files thatcare indexed and indexed they get when you do so initially and then it is kept in sync when you add metadata to your files in Photolab. Your searches in Photolab then uses both XMP and EXIF and has the nice feature that it tell you where it found the search match.

Photolab very conveniently builds a keyword list of all the keywords it finds in the files automatically when you initially creates an index or refreshes it from your image folder structure. Not all other softwares does. So it’s really easy to migrate to Photolab but not as easy to leave it. When I “migrated” from Photolab to Photo Mechanic again after a computer crash last summer I had to import - create an index in C1 and then export the keywordlist from C1 to PMPlus, because you can’t do that today from Photolab which isn’t all that good.

@SojiOkita Short answer - Yes, the act of browsing = the act of importing with PhotoLab.

and there is a catalogue or rather a database, SQLite like most of the other packages. With a database comes the ability to search the data in that database quickly rather than having to read every image directly or utilize whatever indexing capability is on offer from the operating system!

The alternative to explicitly navigating the directories where the discovery process will only “discover” and “import” one directory at a time, is to use the ‘Index a folder’ feature when all directories including the initial directory designated will be scanned and imported into the database.

If there are doubts about whether all images in a directory (and all sub-directories below that directory) have been included in the DxPL database then simply re-index and any “stragglers” will be found and added to the database (just tested and it works as I have described it)!

But if the data is not in the database then it can’t and won’t be found.

@Stenis Agreed but CTRL A to select all and then add them to a ‘Project’ or create a ‘Project’ is all that is required. It might be nice to be able to designate an ‘External Selection’ as a ‘Project’ but …

@platypus I was going to respond to this when you first posted it but decided to concentrate on trying to get my new machine working and I have now got all three machines connected to all three monitors via HDMI switches, sound is reconfigured and only the keyword switch left so …!

If it is a weakness of PhotoLab then the SQLite database is also a weakness of Lightroom, Capture One, Photo Mechanic Plus, Photo Supreme, Zoner, ExifPro, IMatch, XnView and XnViewMp etc. etc. , excluding ACDSee which uses a variant of Dbase I believe, but that is “just” another database.

What singles DxPL db out for special criticism and what exactly are you criticising?

Re-indexing goes some way towards that but I will admit that if I had only navigated to 3 subfolders within a directory of 100 sub-directories and then I re-index the main directory all the sub-directories would be included!

This is easily fixed by providing an option to re-index only those directories already resident in the database @Musashi and ignore those that are not currently present. The code to include the option in the UI is far greater than the code to ignore “non-resident” directories but …!

Please (re-)enumerate those “shortcomings” for those that have not read your previous posts about DB maintenance Database Maintenance to provide some additional detail to your complaint.

I’ll not repeat what has been written already. You kindly included the link to my original thread, and in there, many other requirements have been added in text or as links to other posts.

The weak point is not the database (no matter the kind used) itself, but the lack of service functionality.

Would you like to be a passenger in a plane that is not serviced regularly?


I have played with that and it´s not that easy.
If I try to promote (Add) the images from an External Selection to a Project It works but I get an error message when I try to edit them and the strange thing is that I´m allowed to promote but not to use them.

If I select a bunch of images from an ordinary folder and not a virtual bunch of images it works fine. The strange thing is that both these Projects looks exactly the same in the project list but they act completely differently.

“This image cannot be processed since the source file could not be found” is all I get.

1 Like

@Stenis that’s odd because I ran tests some time ago and did just that to overcome the fact that the most I could do with an external selection was about 239/240 at a time. I wanted to get 1,000 images into a project that way, i.e. it turned out to be 4 external selections which was a bit of a pain and I wasn’t sure what was causing the limitation!?

The limit is flagged as an OS limit, I was trying to go from FastRawViewer to PL6.3.1 and after two such batch transfers and CTRL A and creating the ‘Project’ for the first group and then adding the second group I have

  1. Two ‘External Selections’
  2. One project containing both combined

I can access the ‘External Selections’ and the ‘Project’ images equally without any problems whatsoever!? Which is exactly what I found the last time I did this.

So we have the ‘Project’

and one of the ‘External Selections’

In ‘Customize’ mode (sorry the images are not as interesting as Zanzibar)

The problem you appear to be experiencing is that the pointers are pointing at the image in the database but that image cannot then be located on disk and that makes little sense unless something is “locking” those images or they were on an external disk or …?

Does this happen when in ‘PhotoLibrary’ mode when moving from thumbnail to thumbnail or only in ‘Customize’ mode? If you terminate the program that passed the images to PL6 does the problem persist? Does the problem remain after you restart DxPL?

I have not experienced this in the past and am not experiencing it tonight!

Repeated the test with another piece of software (on another machine) that can pass more images in a single transfer and all collected into a ‘Project’ of 1001 images and all are present and correct as far as I can tell

For some reason it works from me but not for you!?



DeepOdd® is the secret project name for the DAM parts inside DxO, don’t give it away in public. :grin: sorry, couldn’t resist. Good luck with further testing, it’s very entertaining.

1 Like

@JoJu If you find it entertaining then you really need to get ought more, so do I come to think of it.

Currently I have 2 (out of 3) machines running and starting up a machine certainly automatically triggers one of the HDMI switches and the issue of which machine is displaying where at any time is getting to be “interesting” rather than entertaining!

Changing the Taskbar colour might help but I rather like the boring grey I currently use (!) but with Machine 1 (the new build) using the centre monitor and Machine 2 (the old Main machine) using the two outer screens, all of which can be changed by the push of 3 buttons, I am getting confused already, time for a coffee!

Not as I understand it, JJ …

There are affiliate links and discount codes all over that site. He’s making money on this, so I think that probably says something about his objectivity.

Re-indexing does not help in its current implementation. Check out this example.

Thanks Bryan for your effort!

When I add images from an ordinary folder to a Project it works and I the can open these images without a problem in Customize.

If I use the External Search as a source and copy the images from that view in PhotoLibrary mode and create a Project from that search I have not been able to open and edit any of those images in Custimize mode.

Maybe you are right that the External Search doesn´t point to the folder but to a preview in the database still that is strange.