Is the a Roadmap for user to see upcoming development goals?

It would be great if DXO has (maybe there is, but I have not found it) a road map to indicate what features they are working on and some feedback on customers Feature Requests.
Currently it all seems to be a case of “shoot and pray” and no visibility on the direction the program development takes.

There are clearly some easy improvements that could be made on the DAM side as well as some more difficult aspects (like masking). Whilst Noise reduction is great, I hope that not all effort is focussed on this.
(and is it me or is calling the edit module “customize” annoying? perhaps a Gallic urge to be different?)

2 Likes

There is no published roadmap and it is highly unlikely there will ever be one.

Once upon a time, when DxO employees had a strong presence on this site, a few individuals sometimes alluded to features that were being planned. As it turned out, those features like a new image browser, parity between the Mac and Windows versions, a Lightroom like Solo mode and other updates were mostly never implemented.

Sometime later almost all DxO staff participation on this site ceased along with the occasional hints regarding some planned upgrades. DxO is very averse to sharing any roadmap or setting any expectations which may be significantly delayed or never be implemented.

Mark

3 Likes

Thanks Mark,

I am new to PhotoLab after a period with CaptureOne and before that lightroom.

I wish I had spent more time on the forum before parting with my cash - a note to self for future purchases.

The software requires quite a change in my workflow and a bit of learning, but what is a bit annoying is that (aside from the odd masking methods), and missing some very basic things that every other software (including freeware) has.

The photo management is very lacking: some like the fact is does not rely on a database, but you could have both and give users to sync basic data either to inside the file (where standard) or to sidecars. Not being able to manage keywords or filter to find images that have not been keyworded, is just bizarre in a piece of software from 2025.

Also: offering Luminocity masking by forcing purchase of an add on, is grating.

That would not matter too much, if one could be sure that the company listens to their clients and intends to implement things - as it stands, I am not sure.

I want to like the software, so will give it a chance.

Some of these comments on this forum suggest not. What ashame that would be. As you say, interaction with DXO employees o the forum seem to be minimal: I have come accross anything recent.
J

Don’t you think it’s better to ultimately choose the software based on your needs and not necessarily on what others say?

First and foremost, it has to work for you so you can communicate your ideas.

First and foremost, yes of course you are right!

But when it comes to development and interaction between the developer and the customers, the forum can tell you a lot.

And many on this forum have years of experience with the software. A lack of interaction with DXO employees could be a warning sign to some.

Of course the “perfect” software does not exist, but overall, I like PhotoLab and I can live with the compromises (to me). It is just the simple omissions that grate. Now, with some feedback from the Company, one would know that any concerns are being taken on board. (or not).

You’re right, but that’s what DxO has decided (at least for now). They occasionally monitor the situation but rarely comment.

1 Like

@RAGING_FURY I believe that the product was developed around the SQLite database and the entries in the database are considered to be the definitive edits.

Removing the database from the product would probably require gutting it of a feature that pervades every pore of the product.

You can control the flow of data into and from DxPL using the preferences options and the ‘File’ options

If the DOP “Clashes” with the database entry then Virtual copies (VCs) can result and the [M]aster will always be the original database entry and VC[1] will always be the edits from the DOP.

Unfortunately if you choose

then when a new (to DxPL) directory is discovered, the images will be imported but the edits will not be taken from the DOP(s), if any exist. That importation will automatically add a new UIUID to that new database entry. If the user then ‘Imports’ the DOP there will be an automatic UUID clash and the “empty” entry will be the [M]aster and the edits from the DOP will become VC[1].

Those that don’t like the database have been caught out by the way the synchronisation works and VCs were easy to encounter in the past. Slightly less so now but still a problem for the unwary (as indicated above).

That DxO have failed to exploit the database more fully is down to the way that they do their developments. The search function is unfinished (about the politest way I can put it) and DxO shows no signs that they are ever going to finish it.

It is as if the software engineers get bored or DxO management always want to concentrate on the next headline grabbing feature, or a bit of both.

I have never used LR or CO, except to test, but own reasonably up-to-date copies of ACDSee, Zoner, ON1, CameraBag, Affinity 2 and renew them on an irregular basis (Zoner is subscription only) and tend not to use any as much as PhotoLab which has been my main photo editing product since OpticsPro 8 (8 and 9 were free copies), I tested 10 but finally bought a licence for OpticsPro 11, then it became PhotoLab.

I complain about the product in general and DxO in particular because of what it could so easily be if they could find the time (and urge) to finish what they started (after listening to their users and taking a balanced approach but last time they did listen they over-reacted and made the product worse instead of better).

I use a fraction of the features on offer but was drawn to the fact that I can start, stop and restart the editing on any image or 500 images as and when I like ,which puts PhotoLab head and shoulders above the other products I have access to as far as I am concerned.!

2 Likes

Hi Bryan, thank you for that explanation!!

that sounds very messy indeed!

I had understood/hoped that the DOP files contain the edits that are not compatible with other software and that the xmp s are used to store metadata that is standard.

I also hoped that the date from both these are kept in the database (to speed searching, but that teh DOP should be prioritised for exactly the reasons you outlined.
Users shoud have the option to also write any standardised metadate to the files itself (jpg and/or raw).
I had hoped that, if files are moved around outside of PL, that all data remains accurate when the folder is subsequently visited within PL.

If anything, the user guide could touch on the subject more.

My understanding (now…) is:
XMP contains all normal metadata
DOP contains all edit data
Database contains both.
Metadata is not written to jpgs or RAW files.

So if I understand your comments correctly, the database takes priority for edits (over DOPs) and xmp (if that option is set to “syncronise metadate with xmp sidecar files” takes priority (over db) for standard metadata.

That, to me partially makes sense (but not the treatment of dop files, surely, as we move and copy them with image files-even outside of PL-, these should also take priority - IF we choose).

All these things could be options available in settings.

Personally, I would very much like the option of writing metadata to the image files too, but I know many do not like that.
Since this data does not “alter the image” in a raw, I don’t see any issue with that.
As should be clear to all, my understanding is limited but managing close to 100 of GB of photos, it would be nice to have certainty, a small cock-up can cause plenty of pain. (been there, done that…)

Lets hope DXO read this and get back or implement some changes.

@RAGING_FURY Just a quick update I am about to leave on a shopping trip so

XMP is a standard sidecar file that obeys normal rules and is interchangeable with other software.
DOP is also a sidecar but to DxOs specification and the DOP contains the metadata AND the metadata but all in DxOs format and not containing the Camera Exif etc. data.
Database contains all metadata, including from the camera data and whatever additional metadata that the user has allowed or forced it to acquire.
JPG metadata is written back to JPGs if the user allows or forces DxPL to do that.
RAWs are never updated directly by DxPL it always writes the data to the xmp sidecar file when allowed or forced to.

Will read the rest and comment later this afternoon

Regards

Bryan

PS: my DOP analysis program has been enhanced to show the ‘Keywords’ data in the DOP

[14:13:06] 20/05/28_14:13:06.338 --------------------------------------------------------------------------[M]aster
[14:13:06] 20/05/28_14:13:06.338 @ line      8   Albums = "",                                           <===[
[14:13:06] 20/05/28_14:13:06.338 @ line      9   CreationDate = "2025-05-28T11:21:32.5051101Z",
[14:13:06] 20/05/28_14:13:06.338 @ line     13   Keywords = {
[14:13:06] 20/05/28_14:13:06.338 @ line     14   {
[14:13:06] 20/05/28_14:13:06.338 @ line     15   "test",
[14:13:06] 20/05/28_14:13:06.338 @ line     16   }
[14:13:06] 20/05/28_14:13:06.338 @ line     17   ,
[14:13:06] 20/05/28_14:13:06.338 @ line     18   {
[14:13:06] 20/05/28_14:13:06.349 @ line     19   "a",
[14:13:06] 20/05/28_14:13:06.349 @ line     20   }
[14:13:06] 20/05/28_14:13:06.349 @ line     21   ,
[14:13:06] 20/05/28_14:13:06.349 @ line     22   {
[14:13:06] 20/05/28_14:13:06.349 @ line     23   "b",
[14:13:06] 20/05/28_14:13:06.349 @ line     24   }
[14:13:06] 20/05/28_14:13:06.349 @ line     25   ,
[14:13:06] 20/05/28_14:13:06.349 @ line     26   {
[14:13:06] 20/05/28_14:13:06.349 @ line     27   "c",
[14:13:06] 20/05/28_14:13:06.349 @ line     28   }
[14:13:06] 20/05/28_14:13:06.349 @ line     29   ,
[14:13:06] 20/05/28_14:13:06.349 @ line     30   {
[14:13:06] 20/05/28_14:13:06.349 @ line     31   "d",
[14:13:06] 20/05/28_14:13:06.349 @ line     32   }
[14:13:06] 20/05/28_14:13:06.349 @ line     33   ,
[14:13:06] 20/05/28_14:13:06.349 @ line     34   {
[14:13:06] 20/05/28_14:13:06.349 @ line     35   "A",
[14:13:06] 20/05/28_14:13:06.349 @ line     36   }
[14:13:06] 20/05/28_14:13:06.349 @ line     37   ,
[14:13:06] 20/05/28_14:13:06.349 @ line     38   {
[14:13:06] 20/05/28_14:13:06.349 @ line     39   "A",
[14:13:06] 20/05/28_14:13:06.349 @ line     40   "B",
[14:13:06] 20/05/28_14:13:06.360 @ line     41   }
[14:13:06] 20/05/28_14:13:06.360 @ line     42   ,
[14:13:06] 20/05/28_14:13:06.360 @ line     43   {
[14:13:06] 20/05/28_14:13:06.360 @ line     44   "A",
[14:13:06] 20/05/28_14:13:06.360 @ line     45   "B",
[14:13:06] 20/05/28_14:13:06.360 @ line     46   "C",
[14:13:06] 20/05/28_14:13:06.360 @ line     47   }
[14:13:06] 20/05/28_14:13:06.360 @ line     48   ,
[14:13:06] 20/05/28_14:13:06.360 @ line     49   {
[14:13:06] 20/05/28_14:13:06.360 @ line     50   "A",
[14:13:06] 20/05/28_14:13:06.360 @ line     51   "B",
[14:13:06] 20/05/28_14:13:06.360 @ line     52   "C",
[14:13:06] 20/05/28_14:13:06.360 @ line     53   "D",
[14:13:06] 20/05/28_14:13:06.360 @ line     54   }
[14:13:06] 20/05/28_14:13:06.360 @ line     55   ,
[14:13:06] 20/05/28_14:13:06.360 @ line     56   }
[14:13:06] 20/05/28_14:13:06.360 @ line     57   ,
[14:13:06] 20/05/28_14:13:06.360 @ line     58   ModificationDate = "2025-05-28T11:21:32.5101148Z",