Automatically Loading/Saving sidecar ? We need your opinion!

(fdeitos) #1

Hi everyone!
We hope you’re doing great :slight_smile:

We’d like to have your opinions on a feature available in DxO PhotoLab’s Preferences Panel:


As you can see, it’s about the automatic saving or loading settings from .dop sidecar files options.
We have two questions for you:

1 - Do you use these options ?

  • Yes
  • No

0 voters

2 - Do you see any inconvenience if we “merge” them?

(meaning we’d only have a single option, combining both the automatic save/load settings)

  • Yes
  • No

0 voters

Thanks in advance for your feedback and have a great day!

Best regards,

(Pascal) #2

Sometimes I use the menu:
File / import dop sidecars and the system replied “already done”.
In fact, I don’t understand this menu if they have already loading.

Same thing for this preference: “Load settings from sidecars” because the sidecars are always takes precedence on the database !?

Or I missing something

(Stefan Goldkuhle) #3

I’m editing a lot of photos on my Mac Book and happy about the DOPs, because all photos get copied (incl. DOPs) and archived on my newer and stronger PC (the room, where this PC stands, is not so comfortable), but it’s good to know, that all changes on these photos are transferred to the PC, too.


I use this feature but these two options can be merged.

The reason is that DOP > DB for me, and PhotoLab is the only one, who modifies these files on my system.

In case of XMP support, I would like to see two separate options for reading/writing.

(Peter) #5

Ok, ive bin here (preferencetab) only at the beginning and under processing i see “XMP”
(checked v1.2 and its also there. :hushed:)
So i did a file search “XMP” no DPL folders. So what is preserved? (EXIF metadata?) in where?
The DOP files?
About the auto safe and load in one choise, well if i want to safe them in auto way i want to load them also in auto way.
(One remark: backwards compatibility of versions. (forwards is basicly a write over)
Or if this can’t be done a option for side by side sidecars of two versions.
(like override of clearview with clearview plus) should be optional “would you be having a DOPv2?” (This way your carefully edited images arn’t corrupted/changed by version upgrade.(copy the settings of DOPv1 but make a new one.)

No clue if this is actual possible but lets go to the future:
DOPfiles : all DPL edit corrections are safed here. (only interesting for the rawfile/TIFF/Jpeg its applied to.) So after a wile you are some versions further with new algoritms which can change outcome of slidersettings (clearview 20 is different as clearviewplus 20 for instance.) So a back and forward compatible DOP would be great. (i know some apps have a “proces as Version X” in there choise in tools se quote benete.)
“V4 compatible” is a profile that passes down color creation when there is parameter information in xxxxxxxxx v4 or earlier. Please use if color tones were adjusted in previous versions."
So this kind of checkbox appearing in tools which have changed algoritms is great or maybe a main checkbox at the top of the editors toollist. So we can choose which version we apply on the earlier processed files.

Other new thing in the future: preserve metadata in xmp sidecars for raw images could be changed to : create XMP file aside dop and write metadata in xmp sidcars for RAw images



I don’t see any sense in changing anything here. For those who use these options, it surely doesn’t matter if there are one or two checkboxes. But if you reduce it now to a single option, it is absolutely sure that some day someone will request two separate checkboxes.

Furthermore, reducing this to a single checkbox means unnecessary effort (even if it’s probably not much) - and you have way more urgent work to do at PL than changing these options from two checkboxes to one.

Really, I am puzzled that you are asking such a question while there are so many really urgent things to do (and fix). If you need a to-do list, just leave me a note.

Best regards,

(Platypus) #7

I usually have these options off. When I use them, I need them to be separate.

Sidecars can be used as backups - if you don‘t trust the database - or for the transport between apps. Who can handle DxO Sidecars other than DxO?

(Melbourne, Australia) #8

I work in the opposite way to @platypus - I have both these options set ON.

I rely purely & only on the sidecar/.dop files - and I regularly delete the database.

Why?: Because I prefer the independence and flexibility of having sidecars located alongside their related image-file … with no problems caused if I move or rename any pair of {image+sidecar} files … and no “black-box” syndrome (associated with my corrections hidden away in a separate database file).

This approach (NOT being forced to rely upon a “black-box” database holding my corrections) was one of the key reasons why I first came to DxO OpticsPro - now PhotoLab.

It is useful, tho, to have separate settings for sidecar/.dop control - - For example, when evaluating a new version of PhotoLab I will have “Load settings ….” option turned ON - but the “Save settings …” option OFF.

Regards, John M

(Melbourne, Australia) #9

Note: VERY good points made by @Tilmann (3 above)

Why divert resource and effort into something that’s not broken ?

John M


Its nice for every images you edit, not everything in the folders, that’s what I like

(Pascal) #11

… maybe because it will have to make room for .xmp! :wink:



Let’s hope for the best. And in the second or third step they could remove DOP altogether and put the development settings also into XMP, like it is done with the crs tag (Camera Raw Settings) by Adobe. Two sidecars is one too many. And as I said, on XMP two separate options for auto saving / auto loading is needed, because XMP can be altered by anybody.

So, if someone uses an external DAM, he want his XMPs most likely not be changed automatically by PL. But if PL is the primary DAM, many will set auto write to true. Auto read allows to have full control on whether/when the PL database content is altered through external changes. I would set auto read on XMPs to false (after initial indexing).

(Pathal) #13

I save .dop file as I work on raw from my internal SSD, and after some time, I archive raw on an external HDD.
So the DB is then loosing reference to the raw/dop, and need the .dop to retrieve the modifications.
And sometimes, I may prefer not to take them, so now I can uncheck the Preference, while continuing saving new .dop.
OK, I could also apply the No corrections preset to start from scratch on this images…

So not really important, but as some why there is a need to change that. If it’s for something much better why not, but without knowing, it seems more like a less easy thing.

(fdeitos) #14

Hi everyone,

@Tilmann and @John-M => Thanks for your feedback. We definitely weren’t aware of better things to do and appreciate that reasoned people return us to the right path. :handshake:

On a more serious note, I know some of you are definitely angry at us, and take any opportunity to let us know your state of mind. We got that. Really. But I’m sure we’d all be better off if we can stay on a more constructive level.
You see a post with a poll, on a “small” thing to you, and you immediately jump to the conclusion that :

  • we’re only focusing and doing that at 100%
  • we don’t care about or don’t have others “more important” things to do
  • we’re not able to discern what is irrelevant in our work.

Wow. Well… if that’s what you truly think, then there’s not much we can do at the moment.

As I’ve posted on another topic recently, at the moment, our teams are working on a balanced load of tasks, at least as much as we possibly can, and those tasks include:

  • finally tackling long time users requests
  • UX improvements
  • new features, including DAM functionnalities.
  • general maintenance and bug fixes

At the moment it’s all words on a forum, but as I’ve already said, you’ll see the embodiments of all those efforts in the upcoming updates, and I hope, finally be reassured that we’re hearing you and that we may know what we’re doing.

Thanks for your understanding.

Best regards,


Hello Fabrizio,

I am not angry, just sarcastic.

But yes, I must confess that I’m somewhat disappointed about the way things appear to develop currently. So please excuse me if my sarcasm was too strong, that was not meant offensive.
(Also, I did not imply that you’re doing nothing else. On the other hand, this issue really is the least urgent one could think of in the current situation, IMHO.)

Please note that I really like PL, and I keep recommending it to other photographers.

Besides any emotions, the arguments are still valid. It doesn’t make any sense to remove a working functionality (and even put effort and ressources in this). If only one single user prefers to have two separate options here, you should simply leave it “as is”, unless you have strong arguments to change it. (In that case, it would be fine to share and discuss such arguments.)

All those users who always have both boxes checked or unchecked, will continue to be fine with clicking twice to change this setting(s) if necessary. However, the other users simply would not be able to configure this according to their needs if there’s only one checkbox.

Personally, I currently have both boxes checked. But if I was to change this, I definitely would turn off only auto-save, not auto-load. So please keep both checkboxes.


(NicolasC) #16

Hello Tillman,

Let me add my technical view on that topic. I hope it’ll make you understand a bit more what’s behind the poll and the corresponding changes.

The way sidecar are handled is not as simple as one could imagine. One of the goals of sidecar files is to let people share correction settings on image across several computers, for ex. when images are stores on a network share or on an external drive. In addition to correction parameters, it also stores ratings, tags, virtual copies, etc. Every time an image is displayed in the filmstrip, or when you re-index a folder, we synchronize the sidecar file with the content of the database, so that we ensure that you’re working on the most up-to-date version of your image and that your sidecar reflects this most up-date version. In some scenarios, this synchronization ends up in creating virtual copies of your images because we cannot figure out if the sidecar and the database contain 2 different virtual copies or 2 different versions of the same corrections.
Some people got in touch with our support because of that issue happening sometimes with their workflow and we want to address it. There are different technical solutions to this issue but the cheapest one to solve some of the scenarios is to avoid letting users enable sidecar reading without enabling sidecar writing. Hence the poll.

To summup the situation :

  • by working on that feature, we’re addressing real issues faced by real customers. It’s not because you don’t face it that other don’t.
  • by creating this poll, we’re trying to know if the basic solution, that would solve most of the cases, will not bring pain to some other customers. The idea here is to save time of the development teams, so that they can work on more “interesting” feature.
  • Finding the best balance between implementation costs and value brought to users is at the heart of our daily activity. We’re always trying to bring the most features we can, as fast as possible, to provide you with relevant solutions to your photographer’s problems.

I hope this helps…

Have a good day!


Nicolas, although I have both options “on”, I’m one of the users affected by the problem of unwanted virtual copies.

As far as I remember, DxO creates virtual copies if I modify image+sidecar pairs on another computer and copy them back to a local disk. It does not happen if I’m working on a external disk or a network share.

I don’t understand what the DxO developers had in mind when inventing this logic, maybe you can explain the reason behind.

Therefore, I delete the database always when transferring image+sidecar pairs (as John-M dioes). The sidecars are my primary place to store the information.

Instead of brutally deleting the database, I would prefer an additional switch in DxO not to create virtual copies if the sidecar is changed externally, or a dialog asking the user if external modifications are detected.

There are other problems with the sidecars I already described in

Please consider also backup or version control scenarios. If DxO scrambles the sidecars at every opportunity without changing settings, this creates unneeded pseudo-differences or backups.

And keep entries in a predictable order. Since the sidecars are text, it can be very useful to compare two versions with a text compare tool to find the differences in the settings.



Hello Nicolas,

thanks for the detailed explanation. This makes it much clearer - if the poll would have contained at least a small portion of that background, this would have saved much discussion…
(This again shows that the communication by DxO could be better, which has often been mentioned.)

For me, only the sidecar files have (ever) been relevant. I don’t mind the database, and for me it wouldn’t matter if there wasn’t any.

If you change anything here, please take care that it must be possible to use PL exactly that way.



Please never do so (unless you are the market leader with jester’s licence - SCNR).

XMP is a (halfway) standardized container mainly to make image metadata like description, keywords, geotagging etc. available for different applications over a long time.

But the RAW developer settings are very application specific IOW incompatible, you can’t share Lightroom settings with Photolab and vice versa.

Maybe somebody can explain me an advantage (for the user, not for Adobe!) of Lightroom RAW develop settings kept in the same XMP sidecar as my valuable metadata.

At the moment I see mostly disadvantages for the user, and advantages only for Adobe.


(John Barrett) #20

Indeed it used to be the default support solution to nearly every thing to delete the data base! Those of us using a DAM already have two extra files to each image already, whats the problem?