Some (UI) improvements I'd love to see

Just a few points I collected in the recent days while using DXO Photolab 2

  1. Centered Filmstrip, would love to have the file I’m working on to be centered in the filmstrip below. This way it is easier to navigate through a project visually.

  2. Nested Projects, Using projects a lot as I do my culling etc. outside of DXO. Would be great if we could group projects several levels deep.

  3. Better integration with Photo Mechanic (or other external metadata editors). At first import the files do get the rating from PM but after that it is DXO PL only. Would be nice to be changing labels, rating etc. in PM and seeing those alterations reflected within DXO PL

4a. Clearer highlighting of the selected image(s). I believe this is a Mac version problem. It is incredibly hard to see the selections. The hues and colours are way too similar.
4b. Same goes for the background of the histogram. It is now very hard to see where exactly the endpoints are. A lighter background would help tremendously.
4c. Histogram overlay in the curves tool. Please?

  1. Selecting multiple projects for deletion. Can only do this one by one now.

  2. Sort by processing state.

  3. Cropping within picture constraints. It is costing a lot of time to correct for overshooting the boundaries when cropping. The whole cropping experience would be greatly enhanced by that. This can of course be an option.

  4. Using the same keyboard shortcut to exit a function as used to enter it. For instance, pressing R again to confirm a crop and leave the function.


Totally agree with this one. The inability of PhotoLab to play well with others in the XMP area is extremely frustrating. XMP data (ratings, keywords) should be stored with XMP and not away in some hidden database or even in the DOP files. Some consistency here DxO. Don’t act like your applications plays well with others and then make data inaccessibly by hiding it in the database.

Cropping within picture constraints. It is costing a lot of time to correct for overshooting the boundaries when cropping. The whole cropping experience would be greatly enhanced by that. This can of course be an option.

Can’t agree with this. After adjusting horizon, I sometimes want to crop just outside and then do some Photoshop work to add back in turf or foliage or black to allow me to keep an element in shot. Autocrop does do what you want. It automatically crops leaving the maximum possible image without any black. You can even choose the aspect ratio you want forced as your crop.

You can add Autocrop to your default preset (as I do). Which means when you adjust horizon you the crop is applied automatically.

The crop tool is flexible, powerful and automated. I wouldn’t want DxO to tinker with it.


I don’t agree with this part. The standard paper in Europe is the A ratio which DXO has always refused to add as a preset. I and others have been asking for this for years, or some means of creating users cropping sizes. We were promised it at one stage, but as with all such things its not come to anything. In the former forum it was felt if any one at DXO know how to make the changes it would be easy to add the A ratieo, but…

Besids the xmp file a dop file and the database.
Assumming the database contains the xmp info combined with the dopfile information.
Read from the files bound to the image file.
The folder has jpeg, tiff and raw files , then thus 3 dop’s, 3 xmp’s file all with same shotnumber.
Starts to be a bit crowed messy.

I would be happy if i can decide and set subfolders for exported tiff and returned tiffs from nik.
( myself always create a oocjpeg subfolder inside the rawfolder before loading in dxo.)
By making a sub folder when creating a tiff, the xmp and dop’s are less mixed.
Because when dxo creates a tiff it needs also duplicate the xmp for location and tags.

So i like to have some control in organising all those attachments.

Adding a ratio is not a major change. I’m astonished that DxO hasn’t just done this. We are in agreement that the small touches which don’t involve re-engineering an interface should be implemented in a timely way.

The folder has jpeg, tiff and raw files , then thus 3 dop’s, 3 xmp’s file all with same shotnumber.
Starts to be a bit crowed messy.

I don’t agree. I’d try to keep TIFFs somewhere else myself. JPEGs should just be ignored as they are probably only there to allow faster culling (I use my jpegs for quick full size preview, FastRawViewer knows to treat RAW and JPEG with identical name to single entity). In PhotoLab file browser you can let PhotoLab know to ignore the JPEG.

Just keep image information in sidecars and XMP please DxO so we have cross-compatibility with all the other applications which all the diverse PhotoLab users work. I don’t expect people to use the same workflow and same applications as I do (I’m happy to share how I do it though). We have a single common point: we all require good cooperation with other applications in our workflow.

PhotoLab cross-application cooperation is pretty good. Moving storage of XMP data from the database into the XMP files would fix a huge host of workflow issues for so many dedicated users of PhotoLab. Cross-application cooperation is a big talking/selling point for the marketing team as well. PhotoLab has a good following already among photographers who don’t want to be tied into a single tool. Play to your strengths to win more.

En attendant la prise en charge par DxO pour le ratio au format A…:

  • Palette Recadrage / Ratio de l’image, mettre en surbrillance (sélection à la souris avec le curseur), puis taper “99/70”.
    Si nécessaire faire ensuite le choix de la Correction (Auto… / Manuel)

Le ratio n’est conservé que pendant la session en cours, il est perdu après fermeture et réouverture de Photolab. Mais les photos déjà traitées avec ce ratio sont au bon format. Si une de ces photos est ouverte, le ratio est ensuite présent dans la liste pour la durée de la session.

Google Translate :
While waiting for the support by DxO for A… ratio:

  • Crop / Aspect ratio, highlight (mouse selection with the cursor), then type “99/70”.
    If necessary then make the choice of Correction (Auto… / Manual)

The ratio is kept only during the current session, it is lost after closing and reopening of Photolab. But the photos already processed with this ratio are in the right format. If one of these photos is open, the ratio is then present in the list for the duration of the session.


This long winded work round is really no let out for what should be a simple change that DXO have refused to make over at least 5-6 years that I have been pressing for it. The way I get round it is in a preset but its really not good enough that so many different people at times have asked for it, for a standard paper size that is widely used and to have it ignored for so long! Along with all the other improvements long not actually implemented changes to cropping was hinted at but along with all the other ones has never seed actual release.


Brilliant workaround Gerarto! Thanks for sharing it. John’s also right: a little fix like this to crop ratio shouldn’t take years (or even months). Hence you both get thumbs up from me.

@Marie There’s a very easy fix here which would make John very happy and help a lot of PhotoLab users who print their pictures.

first source out SD of camera:
Rawfiles and OOCjpegs of same image as RAW files and jpegs processed for effects like black and white with one color made by menu of camera and panorama jpegs.
So i split duplicates of oocjpeg and raw in a folder after culling. Wile i keep the jpegs of panorama’s and such inside my “rawfolder”
This means that i need to have jpeg processing inside my DxO active.
second: when i use the export to application, i setup DxO as export in 16Bit it proces a Tiff and places this inside my rawfolder as a sortoff Virtualcopy, opens up NIK do some stuff, save back in to default folder which is the same as origin. or overwrite or creates a filename_dxo_dxo.tiff.

This process has entries in the data base and in the Dopfiles when you open the imagefiles in the developer workspace.
When XMP files are also made and updated by DxOPL you got:
0001.jpg (oocjpeg of rw2)
When you use export to nik:
opens NIK
saves altered file:

12 files of 1 source image!!

My proposal is a option for setup a subfolder system.
folder 01 (rw2)
folder01//subfolder 01: created tiffs by export to application of DxO
folder01//subfolder 02 : saved back images from NIK or Adobe or…

rw2 file dopfile and XMPfile

“created tiff for export to NIK” and if looked with “customize” it gets a dop file and it should get a XMP-file which is a copy of the rw2.xmp
(So if you want more the one attemped: create VP export to NIK (no processing needed its already a TiFF)

Returned processed file from NIK
again in separate folder: with its own dop and xmp file:

why? maybe you process this one a bit more before you export to jpeg exportfolder (the finished/final images)

This way you keep organised and i can trow away any sub folder i like when done without looking which is for what.

Export to disk is already choosable so no problem there.

Do you know thr destination path ?
. . \TIFF a folder is created on the same level than raw folder
(two dots without space. The system can’t write it :frowning:
.\JPEG a folder is crated on parent level


YES Alec
and even more



Toujours aussi précis Gérard :smiley:
For my use I write: .7 (0 is optional).



Peter, thanks for the detailed explanation. If you would just manage your panoramas in a parallel subfolder, there’d be no need to mix RAW and jpeg. It would be a pity if because of your very complex file management needs, the rest of us are denied all data in XMP and DOP files and are condemned to struggle with a database and poor inter-application compatibility for as long as we continue to use PhotoLab.

If PhotoLab becomes an island, I will probably immediately move to another RAW developer which plays better with other applications. The main reason I chose PhotoLab over CaptureOne (they are both pricey) is that PhotoLab plays well with other applications and doesn’t require either a database or a ridiculously complex “session” structure just to edit a few RAW files.

Sorry can you explain?
i just typed my own as a example.
normally you have a folder say: “20190423 weekendwalk” in your 'new images folder"
all images you download from your camera are in there, Rawfiles, made jpegs, 4K movies.
So in windows explorer you separate the photo’s from the 4k movie and then start culling the bunch.
After that you open DxO for further developement mostly rawfiles all in that folder alone.
in the export window i can by export to disk choose to select a export folder for Tiff’s and developed jpegs.
So export to disk is wel placed.
The place where the (folder location)control is fairly minimum is when you use “export to application” and “save from application back to DxO”
This makes the use of NIK fairly complex/confusing and the returned Tiff is processed by DxO and then again by NIK placed back to DxO folder from the origin rawfile.

All those image files can get Dop files as siblings. Normal i delete the inbetween files when i am done to save diskspace, (tiff’s are rather big and bigger then de rawfiles it self.) So the one’s i maybe keep are the returned tiff from NIK application which be used as export to disk as jpeg.(most of the time is cleanup my folder (the 20190423 weekendwalk) throw away all oocjpeg duplicats, the tiffs and try outs (different aproaches to get the wanted image) and move the folder containing the rawfiles and Dopfiles to a archive.
So at this moment i use in nik a “safe as mode” to select my “tiff folder” i manual create in my 20190423 weekendwalk or i use the main one where “export to disk as tiff” is pointed at. This way i know which tiff files are almost ready to finallize as jpeg.

My main itch is about the fixated not adaptable way the connection works with NIKcollection and DxOPL.
And if DxOPL is also not only reads XMP files but also create and update/write them in the future with a dop file as second one, a cleanup after processing your rawfiles gets ugly complicated when all kind of file types are “dumped” in the original folder.
Silkypix uses a subfolder for there kind of dopfiles and i am not want that for DxOPL. No need and the present way is better.
I just want a way of selection when transfering between NIK and DxOPL. So i can choose how i safe my tiff files.Especially the returned one’s.
So when i hit “safe” in NIK i get a popup with a folder path which i can change if i like.
That’s all.

HA LOL, i don’t think i am that powerfull in directing DxO.
XMP isn’t integrated yet as read/write function and i am not “use” xmp gererator to ad keywords and tags for DxO database.
As i earlier stated i am adding tags/keywords at my end game, my photo archive, which is at the present time “guarded” by PSE13 organisor.

My “frustration” is the cluttered folder i can get when i am “playing with NIKcollection filters” and use DxOPL as “controller” of all images. (except the one’s exported for photo archive)
Now i just have filename.rw2 and dop and some jpegs plus dop from panorama and such, and the tiffs plus dop all placed in one original folder.
Imagine that every image file gets a XMP file added by DxO. and you want to change the location afterwards… argh.
with mp3 and “tag and rename” i can go on file and on group of selected to change the entry like a batch.
So managing XMP/DOP and database made by DxO is very basic at this moment.(XMP non existing yet)

it’s not the interface and connection but the control between the applications where the files are write/saved to which is not present. (if i like to clutter all in one folder fine and when i create subfolders or a flowchart structure and point my export and save command on the folder of my liking also fine. No need for complicated auto creation of folders but there is a lack of control at this point.
So your flexibilty isn’t in danger. only you have to “click” maybe one time extra.(selection of destination folder.)

Well there are really two alternatives: sidecar files kept together with the image or database only. I used to dislike sidecars (say twelve years ago). Then I ran into my first RAW incompatibility issues with ACR DNG (originals deleted as many experts were recommending at the time and Adobe was nodding and winking at). Then I ran into issues with moving folders of images from MacBook Pro to desktop and losing all metadata and/or processing, unless I jumped through the exactly the right hoops.

Then Apple abandoned Aperture and my data is more or less trapped in a catalogue. Then Lightroom became hopelessly slow with very frequent paid major updates.

At that point, I realised that storing data out in the open next to my RAW files is a wonderful idea.

  • I could see which images were processed by what software when just by looking at the images folder.
  • I could move folders from MBP to desktop and back again whenever necessary or even convenient with no loss of data or time.

From that day on, I’m no longer worry about “clutter” in my images folder.

Oh this long explanation Peter :smiley:

YES, “Export to Application” have no path proposal.
But, in my mind, these TIFF images are “new” master files.
In this case the raw folder is not a bad choice.

You write “So the one’s i maybe keep are the returned tiff from NIK application which be used as export to disk as jpeg.”
In fact the file Weekendwalk_001_DxO.tif generated by DPL is overwrite by Nik and appears in DPL (Sometime you might to press F5 to update the thumbnails).

First solution:
You must to move it in your TIFF folder.
With explorer OR directly in DPL environement.

Second solution:
In the chapter
I propose to export it in JPEG since DPL
“To keep consistency of output formats (definition, compression, rendering) it is better to save in TIFF from the third-party software and reserve to DPL the final export”.
In this case a dop sidecar is generated but you do not do anything.

Today, DPL write no any xmp sidecar.
Maybe soon DxO will come up with a better solution.



Point taken, yes keep all collarated things in one basket together.:blush:

That’s what i do now, i need to explain i work on DxOPLv1.2 at this moment and v2.x is more consistent with the export and import out nik. ( the temp. File issue, in order to see the returned nik tiffs i need to rename the .temps in .tiff.)

(i see you updated your “handy guide”. Look great. Have to reread your guide again from front to back when the sun is bringing warmed in the back yard. ; sun, glass of beer and a tutorial :sunglasses:)


I also use the auto crop and yes sometimes it is useful to crop outside of the image. But when doing a batch of shots that just need a little cropping tinkering it is way more useful to constrain the crop. Cropping outside of the image that should be an option imho.

The option to crop within the existing image frame already exists with autocrop. What case are you trying to make, Bob?