Organisation of raw, working and completed files

This is the best, default approach! Unless you are trying to solve an actual problem, how you’re doing things now is usually the best way!

The problem with PhotoLab is that it uses a database and sidecar (DOP) files. Everyone here has their preference for which it should use, but I think we can all agree that using both is one of the biggest pain points.

You have no option to NOT use the database. I have always relied solely on .DOP files and occasionally I delete the database and have never had an issue.

A database can always get corrupted or lost and all edits will be lost unless you have a backup.

There is no database management facilities provided by DxO except for backups so I do not trust it. I can at least backup my DOP files right with my photos so I am happy no matter what happens to the database.

1 Like

Thanks again Bernard @be51 !

I do use PhotoLab since several years (starting once it was still called OpticsPro) … but in discussions like this I notice that I stick too much to my workflows and routines and look too little left and right and to new features.

So VERY helpful shedding light on features such as “projects” and DAM and understanding how more experienced users handle it!!!

Also I enjoyed your photo site as well - for sure you must have spent a lot of time on it …

I should have been clearer. The fact that DxO insists on both is a problem.

I’m new to DXO so am not sure exactly how the flow will change but, however that works out, I will continue to us a DAM to organize my files. In my case, I rely on Daminion which makes the folder structure completely irrelevant and allows me to immediately sort and access files by date, place, keyword or any metadata. Until now, I processed my RAWs in Silkypix, saved the resulting tifs in a year folder and use those files for further editing in Photoshop or to export as jpgs if desired.

Imo, that is not a problem of DxO. It’s not a problem at all depending on how one looks at it.

Capture One, Lightroom, Photo Mechanic, PhotoLab and other major apps use a database.

  • The DB is the app’s brain, it remembers metadata and edits, tracks files etc.
  • Sidecars are a way to communicate metadata and edits to other apps (.xmp) or to store metadata and edits as file, so that not everything is lost if something goes wrong with the database.
  • Think of a .dop file as the little note that helps you remember your password, sim card code etc. The notes help, but the main thing is the brain.

Not all apps are built to take care of their brains properly and sadly, PhotoLab is one of these apps. and when I look at features that have been added to PhotoLab over the last years, I sense that DxO is slowly advancing its database maintenance towards a level that will be on par with other apps in a few years. Until we get there, it’s good practice to save sidecars. And/or use more reliable solutions for asset management.

2 Likes

I would be perfectly happy using project mode if DxO would :

  • read the flag “has been processed” in the sidecar file
  • update the database for each photo I click on.

Then the project mode would have the best of the two modes.

For sure ! more time on the photos and less on technical considerations.

1 Like

You then went on to describe why we need both to keep tabs on each other. Ergo, it’s a problem.

The issue, in my view, is that

  • The database is locked away, machine-specific, and inscrutable (to the average user).
  • The DOP file is openly visible, portable, yet incomplete.

The worst part being that some information is stored in both places. The second worst part being that not all information is stored in both.

I wish DxO would pick one and do it well.

I used to make a folder for my raw files, then a subfolder for exported jpgs, but I’ve since found that cumbersome. I have five or six main folders to vaguely categorize my images, then I put today’s images (for instance, I shot my grandson’s soccer today) into a folder 20260425OliverSoccer. I use Lightroom to cull, delete the throwaways and mark the picks, then rename all the images 20260425OliverSoccer_001.ARW. I use LR to add metadata (including GPS) and keywords into sidecar files, then I open PhotoLab to actually edit the picked images. I export full size jpgs back to the original folder, and downsized (3000 pixels on the long side) into a completely separate folder. Those are the images I might upload to Google Photos and/or Facebook for family, or Google Drive or Dropbox for clients. The important thing is that every image has an absolutely unique filename. If I were doing it entirely in PhotoLab, or darktable, or digiKam, I would do it the same way.

What of importance is missing in the .dop files?

My tip for event photographers (includes sports, concerts, weddings as well) would be to do the main culling in another dedicated application like FastRawViewer which is still all of €20.[1]

Move the 4 star and 4 star images to a Four-Five Star Event Name folder. Use that folder in PhotoLab as it lightens PhotoLab’s database and processing considerably. Instead of over a thousand files per event for PhotoLab to manage one should have between twenty and one-hundred and fifty.


  1. Don’t let the fair price discourage you: FastRawViewer is a better pure culling tool than the $300 PhotoMechanic. ↩︎

@uncoy Interesting … thanks for sharing your workflow!
It appears all of us have developed own procedures and it’s helpful seeing how others do it - and with which intention/advantages.

As a voluntary press officer for a nonprofit organization, I regularly cover several-day-lasting events. Over the day I participate in the event and I have the next early morning to work on the photos from the previous day (~600–800)

  • make a selection of ~100 for the organization’s website, out of those ~3-5 for newspapers
  • modify selected photos in typically the same steps: adjusting crop, tweaking exposure and colors, modify geometry
  • export to jpg (different sub-folders), upload to the organization’s website / send to press
    and then it’s on to the next day of the event.

I do all of these steps in PL today and hadn’t noticed PL having troubles handling large numbers of photos. It does take a split second for PL to display the photo indeed, however in return I immediately get an idea of how a photo looks with different (default) settings.

Time is very tight in these mornings so I am looking out for steps simplifying/speeding up the process. So far I didn’t got to the idea adding an extra selection loop using an additional software for photo selection (such as FastRawViewer) and would assume it goes with pro’s and con’s …

1 Like

Those aren’t large numbers of photos [1] for PhotoLab 9 on recent hardware. Different versions of PhotoLab on different hardware do more or less better.

When I talk about large number of photos I mean in the 1500 to 5000 category (and thinking mostly of sport, which I do shoot, and wedding, which I do not).

It’s definitely an advantage to see one’s RAWs partly processed. I can’t stand the lag between images on large sets though. The lag is not as bad as it used to be (if one is on recent hardware).


  1. I’m assuming your event photos are RAW, otherwise there wouldn’t be much point in putting them through PhotoLab. I’m just working on some accidental jpegs and not enjoying it much. ↩︎

For a timelaps I made about 7000 images. No problem. Except it takes a very long time. There’s no info showing it’s busy or frozen.

George

1 Like