DxO PhotoLab vs Lightroom Classic – using PhotoLab for cataloguing

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.

4 Likes

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?

5 Likes

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!?

Regards

Bryan

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.

@Stenis I copied from the ‘External Selection’ which came from FastRawViewer in the case of the first tests or Photo Mechanic in the case of the second full test and in both cases I followed the procedure that I identified in my post, i.e. Ctrl A on the ‘External Selection’ and ‘Create Project from current selection’ for the first group of 239 images and then the same for each additional selection but now using ‘Add current selection to Project’.

image

In fact both the ‘External Selections’ and the ‘Projects’ use the same database structure of ‘Projects’ and here they are

Doing it this way means that at this point I have twice the number of pointers I “need” but I could also have created embedded ‘Projects’ etc. and the limitation of passing the images is the size of the “array” used to hold the data of all the selected images being passed and Photo Mechanic seems to be a bit better at using the space that FastRawViewer!

So ‘External Selections’ and ‘Projects’ are also pointing to the same images in the database as each other and those ‘Items’ in the database should be referencing images on disk via the ‘Sources’ Table entries

Which in turn reference entries in the ‘Folders’ (‘FolderId’=40 in this case)

which then allows DxPL to find the referenced image on disk by reconstructing the Directory path from the data in the ‘Folders’ table, or not in your case!

Sorry for my ignorance but what exactly do you mean by ‘External Search’?

@ platypus, I don’t doubt your results but will do some testing later today or tomorrow.

1 Like

Sorry for confusing you but that was just semantics.

I used “External Search” to describe that it is “External Search Path” seen from Photolab. See tese images doesn´t need to be part of the Photolab ImageLibrary scopy (Index). It could come from raelly any application outside Photolab.

In my case it is really the same 25 000 images that both Photo Mechanic sees and Photolab sees.

This is what I do:

I Open PM Plus and I selected 12 images in the "contact sheet of PM which is just the main list of images. After that I right click on one of the images which opens a dialog where I select “Edit selected photos with DXO.Photolab”

What happens then is that an “External Selection”-record is created under “External Selections” in Photolab´s ImageLibrary´left panel. This image selection is opened in Image Library. I the select these images and creates a new Project. Everything works fine and these images in the new Project works if I open them in Customize Mode - BUT NONE OF THE OLD SEARCHES IMAGES IN THE LIST DOES :frowning:

Well my conclusion is that something has happened when I have upgraded Photolab since last year. I have done so a couple of times when new service releases has been released.

From what I can see now everything seems fine with the new Projects I have created for this test and I´m very relieved to see that, because this is a very important integration feature that really is crucial to me.

I will have to delete all the present External Selections I have in that list and build new ones when I need them.

So thanks again for your help Bryan!

That´s great really because then it shouldn´t be all that complicated “promoting” an “External Selection” to a Project if one should want a project on such a selection.

Can I ask you what kind of interface you have used to access the tables in the Photolab Image Library DB. What kind of DB is DXO using?

Obviously written by DxO or by a fanboy.

Photolab is hopeless/useless as a DAM system.

However, anyone migrating from Lightroom can simply continue to use LR for the DAM even without a subscription, even simple develop tools continue to work when the subscription expires.

Just do development in Photolab and send a DNG or JPEG back for viewing in LR.

2 Likes

DxO uses take open source SQLite database and you can use any tool that supports this database to open and view it. Always make a copy of the database and work on the copy so you do not inadvertantly mess up your database. The database is just a single file so it can easily be copied to another location (after closing PL).