PhotoLab 3 Trial - large folders and working with third part DAM applications.

DxO PhotoLab
1

Hi,
I am seeking a new method of managing my images. I use Lightroom 6.14 at the moment but recognise that it will stop working at sometime in the future. I have downloaded a trial version of PL3 and am having some issues with it which I hope you might help with.

First my images are stored in folders by year e.g. PhotoLibrary/2018 ; PhotLibrary/2019. There are often may thousands of image files in each year. The folder 2019 stores eleven thousand. Yes I know i really should do some culling.

The first issue is a problem occurs after PL3 has scanned a folder and sub folders and then the images are moved from the sub folders up into the parent folder. Any keyword search finds the images in their new location but also reports them missing from their previous location. This clutters the display with question marks and also causes PL3 to report an incorrect number of found images. I have not found a method from within PL3 to remove all these images from the display . I have tried to filter on them but “Can not be processed” does not find them as they seem to have the status of “Ready to be processed”. Rescanning the folder also fails.

I find it odd that PL3 appears to save a database of keywords but does not provide tools to manage this database. Also it does not appear to save thumbnails which means that it takes an age to populate its display when changing from one folder to another.

So the above indicates to me that PL3 is not anywhere close to having the DAM capabilities of Lightroom 6.14 and that I need to look elsewhere. Using a third party app with PL3 should be a breeze given that PL3 started life as an uncomplicated raw editor. However a problem occurs when trying to invoke it using an “open with” or “edit with” command from another app. If the image is stored in a folder that contains thousands of images PL3 scans them meaning it is not ready to edit and is generally slow and unresponsive.

This performance is doubly annoying because DxO have a Lightroom plugin that does allow a single image to be edited. When run it causes the image to to placed into a DxO project which restricts PL3 to just the images in the project. This useful feature does not appear to be available to other applications such as the Finder or NeoFinder.

Talking of projects why is there no smart projects i.e. one that automatically update as keywords are added to images? After all if you have a database its a pity not to use it.

I’m on day three of my trial and so far I’ve not tried to edit any images as I can’t see a way to use PL3 with any other app other than Lightroom. Frankly the folder scanning is clunky and a resource hungry when dealing with folders containing a large number of images.

best wishes
Simon

2

Hi Simon,

I’d encourage you to give PL a go for your RAW processing - - that’s its key strength - it regularly receives accolades for exactly this function, if nothing else.

Many PL users, coming from a LR background, continue using LR only for its DAM features - but use PL for RAW processing and image editing.

John M

1 Like
3

Correct, DPL is a raw-processor and not a fully-fledged DAM software.

Index your folders in DPL

Sigi

4

1 dxo plv3 is a raw processor application, main strenght is Prime denoise, optical module. It just renew your images to a next level just as default.
2 plv3 has some neat tools in the bag /box which give you a nice start and maybe finish from your rawfile.
3 it has a index and reading facility of xmp files and keywords and in v3.1 release on win it has editing tools to place keywords. But it’s no DAM as in fullblown image manager
In my point of view you need a external DAM to create structure and manage your rawfiles if you have terabytes of images. In the near future you can modify som parts of it, so you don’t need to go out dpl modify go in update/restart.
4 it isn’t a pixel editor as in photoshop.

Can it replace lightroom 6? Don’t know stopped by LR4.2🙂 using it for my images. Hated it’s import behaviour claiming every image it’s scanned.
Can it be a stunning step in your workflow? Yes

At this time a keyword manager and editor which is longer around then DxO’s present toolbox in the librarymode should be better in alot of things but they are working on improvements.
2e step raw to tiff dng jpeg, one of the best i tryed. Does it has gabs and empty spaces in the toolbox? Yes, not all you think to need is there. So if you like to go wild as in stacking, hi-resolution, HDR, moving people around in the image,… Sorry no go.

But again the key features you need to transform a raw in to tiff or jpg are there and it’s pretty good. You can use your LR version for 3e step and end managing of images until it won’t supported anymore.

5

Yes, you’ve hit the nail on the head. DxO is creating all kinds of problems for itself and users with this half-hearted but much requested pseudo-DAM functionality in PhotoLab.

The DAM features in PhotoLab can be neatly avoided though by judicious use of the file system. Here’s how I do it.

  1. First step is triage via FastRawViewer. All the bad or duplicate images (for sports shoots that’s most of them) go straight to Rejected Images. Now there’s one third as many images to deal with.
  2. A second pass through the four and five star images in FRV demoting and promoting until five star includes only the images I want to process.
  3. Use the move function in FRV to move the five star images into a “Selects” folder within at the same folder level as the “Originals” folder. I usually have between five and fifty images selected for PhotoLab processing from an event or shoot.
  4. Point PhotoLab at that “Selects” folder. As there are only a maximum of about fifty images there, there’s no performance issues.

On the back end I export the finished images to a folder at the level of the “Originals” and “Selects” folder, named eponymously “Exports”. I might have subfolders of different resolutions for posting to the web for instance. The initial export from PhotoLab is by default to a subfolder of the “Selects” folder. I’ll often accept that initial destination and then just move the “Exports” folder up a level. It’s often faster than choosing a destination and creating a folder. Once the folder is created, adding new exports to its new location is easier (no folder creation required).

A couple more tips:

  1. Be sure to turn on .dop sidecars as that makes your changes portable between computers and over time (backup drives). What’s in the database stays in the database in case your primary computer fails or changes over time. What’s right there in the folder (.dop files) stays with your originals forever. You’ll be able to reopen your RAW files with your changes in five or ten years and make additional changes or improvements as you see fit.
  2. If you are having trouble getting a folder to show certain images or sync, it’s the damn database and its pseudo-DAM efforts. There’s two solutions.

The first solution is to rename the folder you are working on. This will force PhotoLab to rescan it, using the existing .dop sidecars and adding any missing images. The second is to delete the whole database. I have a shortcut in the sidebar of my Mac with a link to the folder where the PhotoLab v2 database resides. Whenever I’m having trouble with PhotoLab and a folder, I can just delete the whole database.

The delete the database method (wasn’t my invention, at least some of Mike, John, Pascal and Peter are big advocates of this approach, I learned about it from them) does not work so well when you are indexing thousands of files. Don’t index thousands of files. Don’t try to use PhotoLab seriously as a DAM. It will just end in frustration.

The workaround above to make PhotoLab behave as OpticsPro 9 did – just a RAW developer – will make your use of PhotoLab far smoother and more pleasurable.

In terms of DAM management and keywording of finished files, Lightroom 4 does an admirable job of storing a catalogue of masters. There’s no issue with camera updates as jpg and TIFF files are fixed formats. What’s nice about Lightroom 4 as a catalogue is its very easy to filter on camera and lenses to see which focal lengths you shoot your best work. For instance, you might shoot a lot at one focal length but in the end it’s another focal length which generates most of the keeper files. Or perhaps it makes sense to shoot on a prime rather than a zoom if you find that 90% of your images come from a single focal length. Or with two bodies and two primes rather than one body and a zoom.

After losing Aperture (Apple cancelled it) and Lightroom (Adobe made it cloud software and subscription only) and struggling with CaptureOne’s awful sessions system, I’ve given up on all-in-one photo software. My primary DAM going forward will be the file system and named folders. The file system on OS X or even on Windows is a fairly reliable tool which is consistent across OS and decades. The file system scales to millions of files not ten or twenty or even fifty thousand files. Any other approach is just pie-in-the-sky IT optimism and will result in lost and broken catalogues in the end.

2 Likes
6

@uncoy
This is common sense :smiley:
Pascal

7

Firstly thank you all for your comments, secondly I apologise for the delay in replying but I have been busy fighting Capture One and also looking at ways of using DxO PL3 in conjunction with the DAM application NeoFinder .

Alec you have hit the nail on the head and I am coming around to your way of thinking re the Finder. I seemed to have followed the same software path as you have and am rapidly coming to the same conclusion about integrated image management. They are fine until the company decides to leave the market (iView, Apple) or change their pricing plan (Adobe). As I said above at the moment my images are stored in a flat folder structure all under PhotoLibrary/Year. This is what causes me problems when using DxO as some year folders contain twelve thousand images. So I feel that a restructure is called for, probably by using an Apple Script.

Recently I have learnt that its possible to open raws directly into DxO projects, doing this prevents DxO from the slow process of scanning of the parent folder. I explained to DxO support that I thought it would be good if the auto scan could be switched off but they don’t seem to understand why this might be a good idea. So thanks Alec for confirming that there are at least two of us who have concerns in this area.

The Lightroom plugin is interesting, this allows images to be transferred from Lr directly into DxO. I have looked inside it and found a unix shell script that can be run from the command line or from other applications. This script tells DxO to open the following files in a new named project. The good news is that the script may be used by any application that chooses to implement it.

I have created a proof of concept application that when sent a number of images will pass them on to DxO for opening in a new named project. This is much the same as selecting a project in DxO and then using Open With from the Finder or DAM application. So its not earth shaking. However, when I edit an image in DxO I’m proposing to save small jpeg preview of each virtual copy back to the same folder as the original raw file. Say 1000 pixels on long side. Now when a jpeg is sent to my proof of concept App, the app reads the metadata and determines the name of the original raw file. The app then passes the raw file into DxO and DxO opens and displays all the virtual copies. Not as smooth as Lightroom but it means that edits can be viewed and re-edited from the Finder or general purpose DAM.

I suspect that my app may prove to be to clunky and that having the jpeg previews keep the same name as the raw may be a simpler method of association given that they will be kept together in sorts. Howeverm it shows what could be done in general purpose DAM software if the authors choose to implement some new features. (xnView may even allow this now through its file associations interface).

Getting back to the general point. It seems that writing an integrated file management database is a very difficult task and one that no software house should undertake lightly. Based on the various apps I have tested only Adobe and Apple have come anywhere close to succeeding and they both have had problems in the past.

The fact that this thread is discussing work arounds and the almost routine deletion of the DxO database is an indication of the complexity introduced when implementing any database type features. In my opinion the keyword search that DxO have implemented is not one thing or the other. If the folder is large enough to need keyword searches the speed is to slow.
If the folder contains fewer images then the images probably share the same keywords.
What is implemented just seems to get in the way and not really do the job especially since I can use the Finder to find and list 11,000 images from 89,000 images in my photo library based on a keyword search in about two seconds.

Having said all of the above I think that I will be purchasing DxO PL3 once my trial ends. The raw editing is great and I can use it with both LR, NeoFinder and Apple Finder without to much trouble.

Simon

1 Like
8

For the level of cataloguing you are looking for, I have some good news for you Simon. There’s a disk cataloguing utility which has been enhanced in the last few years to be a passable DAM. It’s called Neofinder and is based on an ancient application called CDfinder. It’s creator Norbert takes his work and the continuity of his application very seriously. The RAW support appears to be fairly comprehensive.

I’m not using Neofinder for these purposes, I use folder structure with selects and deleting anywhere between 60% and 90% of my RAW files as I go. There’s almost no reason to ever look inside any folder besides selects. And I use FastRawViewer as my image folder browser (as well as for triage) as it’s almost instant and it allows me to make any rating changes if I’m so inclined when I’m there or to migrate certain files.

I only need to improve my discipline on cataloguing finished masters in Lightroom 4. I loathe Adobe enough I can’t generate sufficient enthusiasm about building a catalogue in their software, even though it’s the right tool for the job in this case (which is cataloguing and comparing master files and determining what body, lens and focal length combinations generate my best images).

9

Hi Alec,

Given the problems that I have had and am having with catalogs I’m reviewing the way I will store my image files in the future. I have just purchased NeoFinder and it is very good. However I think that I will also re arrange my folders into a logical structure so that if NeoFinder becomes unavailable I will have a viable fall back plan. I to need to get more disciplined and delete the thousands of poor images that I’m storing. I think I will also start to “bake” my final versions into jpegs and store these.

I’ve also managed to get my utility app to work which means that as long as a “preview” jpeg keeps the same name as DxO assigns it, the app will pass the raw sources of the selected jpegs into DxO, much in the same way as the LR plugin does.

Simon

1 Like
10

I’m running PhotoLab as a pure raw developer and PhotoSupreme (PSu) as the DAM with very good results.

PL is hands down the developer which yields the best results per invested time and money. As a Nikon user I sometimes take the route via Capture NX-D and others to without problem.

PSu is very good on labels, keywords, sorting, stacking and versioning. And it is quite agnostic when it comes to external editors and physical folder and storage locations. Importing and managing the photos in PSu and editing the photos with PL is for me a wicked good combination.

Sure there are other developers, pixel editors, DAMs etc but sometime you get tired of the eternal search for something better and with that eternal disappointment (and subscriptions) which it so often end up in.

I want to capture amazing photos with my cameras and make sure the workflow afterwards support my ideas and creative vision.

1 Like