PhotoLab's Pleasant Simplicity

DxO PhotoLab
1

I’m new to PhotoLab and one of the things about it that I enjoy the most is its simplicity. I don’t mean that its capabilities are simple, but that the implementation of those capabilities and the user interface are pretty straightforward. Arguably, PhotoLab has the best-in-class raw conversion, lens correction, Smart Lighting, noise reduction, and ClearView. But applying those corrections is ‘simple.’

And I’m glad PhotoLab does not have, at least in v6, such things as automatic sky replacement, specialty masking for portraits, and many of the other ‘AI’ things seen in other raw editors. I feel as if it’s better to have excellent general-purpose tools that can be used in many specific situations.

My primary complaints are the lack of metadata presets and the lag going from PhotoLibrary to Customize. A better print module and the ability to read HEIC image files would both be nice additions and they wouldn’t add to the complexity of use. Here’s hoping for a worthwhile v7 upgrade this fall.

4 Likes
2

Moderation and cautious use are the keys to that particular feature. It’s just too easy to overcook an image using Clearview.

3

That’s for sure! Just a touch.

4

I do not understand people being glad that others ( who might have different opinions on various matters ) do not have things that they (others) might find useful ( because nobody is showing them down your throat to use ) … as for best in class “lens correction” - that depends on the lens… I “arguably” have a problem with a module that provides the SAME corrections for a macro lens @ infinity vs @ 1:1 distance being a best in class approach :joy:

2 Likes
5

And that is the key. Can a software developer add features without mucking up the interface and adding complexity? Take a look at ON1’s Photo RAW as an example of a ‘do everything’ application that has a complex and scattered interface.

6

I agree. Its one of the reasons why I switched to PhotoLab in the first place. Simple, but powerful and straightforward. Sky replacements and all that, better to do in programs meant for that. Luminar was once also simple, than they made it into a mediocre host of various AI plug ins they can charge for. But most are not that good or not needed, and yet program is over 2GB and more when you install it. I juts want to develop raw files with best quality and this is where PhotoLab shines.

7

Essentially well-said, Bob. A key element of this ‘simplicity’ to me is the ability to open folders & images without having to ‘import’ them.

However it would be good if the database could be exported (transferred) to another computer when required. To me that lack is a handicap.

As for print output, and in fact web output too, I remain wedded to the use of another app that’s more capable for that (such as Photoshop or Affinity) - and I don’t feel that to be an impediment. But the introduction of soft proofing to Photolab was still a welcome tweak.

8

@roj The act of opening a directory while “browsing” in DxPL automatically imports the images in that directory into the database, i.e. it is an implicit import rather than an explicit import. It was one of the reasons I purchased DxO OpticsPro11 since it cut out the whole explicit import process!

But with that automatic (implicit) import comes the associated automatic render every time an image is “selected” even if that “selection” is simply traversing over a thumbnail to get to the image you really want to access.

It would be good to retain the navigational working of PhotoLab but with the ability to select whether that directory should be imported or not. In addition it would be good to be able to select when images are rendered to speed up navigating over 1,000 images to get to the one you want!

While this would add an element of complexity to the simple interface, the current method could be retained for absolute simplicity, while offering selective importation and selective rendering to enable increased speed of browsing/navigating and reduced power consumption!

@roj why do you suggest that the database cannot be transferred? I do not know the exact circumstances you are referring to nor the platform you use.

I believe that the limitation on Mac systems is that the location of the database is fixed? Whereas that limitation does not affect DxPL(Win) users.

I can copy the database between any of my three Windows systems and open them in a copy of PhotoLab with the only real issue being the fact that the database is upwards compatible but not guaranteed to be backwards compatible (that certainly applies to DOPS and I believe also to Presets).

But if I open that database without the correct disks being present then DxPL will essentially ignore any database entries where the ‘UUid’ (Partition Id) does not correspond to an entry in the ‘Folders’ structure and re-import the images (and DOPs etc.) again!

This creates potential problems for ‘Projects’ (Win & Mac) and ‘Advanced History’ (Mac only - Windows has no ‘Advanced History’ retained across sessions) which will still be in the database but referring to now “missing” images.

This is a major problem with my fixed disk subsystem even though the drive letters and drive layouts are identical (certainly as far as my image library goes) but no real problem if I take the images over on a USB drive, i.e. it is possible to carry images from a laptop to a bigger home “beast” on portable media and transfer the database along with them, either located on the same disk or transferred via the same disk to be located in a fixed DB location (Mac) or a preferred location (Windows)!

This certainly becomes a problem if you want to use both systems at the same time unless/even if you are scrupulously diligent.

So

  1. Moving the database with the images ,which must be on a portable device (or prised out of one system and installed into another), should be fine. For use by DxPL(Mac) the database must reside on the system not on the (portable) disk on a Mac (I believe).

  2. Having the database on the same media that is being moved between systems and then used directly by DxPL(Win) is possible on a Windows system. Even if that disk is given a different drive letter the ‘UUid’ I referred to above as a “problem” means that DxPL(Win) can locate the disk in the database and all should be fine (please see Test comments below).

  3. Moving data between systems with a DxPL database on each runs the risk of having the DOP UUid not matching the database ‘UUid’ (under certain circumstances) and causing “Unwanted Virtual Copies”!

But @roj what scenario are you referring to in your comment and what platform do you use?

Please note a DxPL(Win) database cannot be used on a MAC and vice versa.

Test Results:-

To confirm what I had written was accurate I took and old USB3 SATA SSD I used for tests some months ago which contained the database and the data and added them to my main system (PL6.9.0), selected the database on T: and navigated to the ‘Projects’ and attempted to open the first project and DxPL hung @DxO_Support-Team!

Task manager was used to terminate DxPL and I restarted it and the first project was now O.K. but the second project Hung DxPL, so it was terminated.

3rd. restart and the first, second, third, …seventh Project were O.K.

I attempted to repeat the test on my Test Machine (PL6.6.1) and could never get the ‘Projects’ to successfully open, the machine hung every time!

On to the third machine (PL6.7.0) and that was a repeat of machine 1 and the system was fully operational on the third restart where the drive letter is D: (not T: on this system)!

So, ignoring the bug, I can move the data and the database between machines with different drive letters being allocated with no problem(!?) whatsoever on DxPL(Win), but only if the data remains on the same disk with the same UUid (Partition ID, or Drive number or whatever is the correct term for the identifier)!

2023-09-01_105355_
2023-09-01_105355_1119×608 132 KB

PS:- Both sources of edit data are on the same drive in this scenario so backup the database regularly to an alternative drive. However, DxPL does not provide a solution that allows a drive with the same folder structure and images to be “matched” with the database in the event that the data is lost.

I have documented a “kludge” in another post but DxO should provide a cleaner mechanism!

9

About simplicity : when a problem is well analysed , even complex things can be very simple to use for the user.

10

Exactly! Rarely must we loose simplicity to gain function. But it’s hard to make complex things simple.

11

And more than that, simplicity/complexity are subjective values.

12

that does not justify your gloating over here ( multitplied by a neophyte syndrome … I shall say people who did not find at least half a dozen bugs in the software shall be prohibited to render their exaltments about it ) … it is one thing to be happy that you have a feature and a different thing to be happy that somebody does not

13

I said nothing about features, or lack thereof. Only about the simplicity of their implementation.