Option to preserve metadata in XMP sidecars

Svetlana, I too use external tools to efficiently rate my photos (FastRawViewer in my case). On occasion when working on the RAW in PhotoLab, it makes sense to change the rating. Those changed ratings don’t show up in the XMP.

Or perhaps I go back to FastRawViewer and re-rate some of the images. Changes also don’t show up.

I agree with Brian: PhotoLab should be much more interactive with the .XMP files. To the point of even storing its own XMP standard metadata (ratings, keywords, GPS?) in an XMP for better interaction with external programs. Storing metadata in its own files just makes a mess.


Dear DxO, please begin to write xmp meta data to xmp side cars according to the the industry standard. And not only to your propriety dop files.

The rest of the world uses xmp and PL would benefit a lot if it only could begin to follow standards and not lock us in. :slight_smile:


Of course XMP should be used - it’s the industry standard.


So based on the replies here, I’m guessing that this Preferences option gives the user the choice of whether to process their files using the ratings (and other metadata) stored in the DxO dop proprietary file or that which is stored in the XMP standard file. Is this correct?

If so, then I agree that DxO is going down the wrong path. I see no value whatsoever in this as a feature. Certain core metadata such as ratings are fundamental attributes that are ubiquitous and should never be application specific. Furthermore, how would one know what metadata types are recognized and thus applied by PL and what is not? (Good luck keeping it in your head over PL versions.)

Anyway, aside from the problems I’m having getting it to work, would someone please confirm if I’m correct on how this Preferences option is supposed to work. I would be grateful.


1 Like

I don’t know any photo industry standard for xmp sidecar usage.
Even if everyone writes in this file, a big part of the “words” are understandable by only by their editor.


Dear all,
Thank you for the feedback on this preference option. To be clear on this option, i’d like to explain what does it mean this option “Preserve metadata in XMP sidecars for RAW images” in Processing session.
XMP sidecar contents not only Rating or Author/Copyright information, but there are a lot of other information in xmp sidecars as well. So,

  • If you enable this option, all information in xmp sidecar will be preserved in your output image.
  • If you disable this option, only a few basic information of xmp sidecar will be exported to output image.

Moreover, how we understand RATING behavior when working with image files associated with XMP sidecar ?

  • It’s independant with "“Preserve metadata in XMP sidecars for RAW images” option, so any this option enabled or disabled, rating of output image will be imported from rating of input image in PL. (for example, if rating of input image in PL is 2 stars, 2 stars can be imported from XMP sidecar or from Exif or directly set in PL, output image will also have 2 stars)
  • What is priority for rating? PL > XMP > Exif.
    *if Exif rating = 2 stars, XMP rating = 3 stars --> final rating = 3 stars in PL (stars with yellow color and explanation tooltip will be displayed when you mouse over on) --> output image rating = 3 stars
    *if Exif rating = 2 stars, XMP rating = 3 stars, then we rate 4 stars in PL --> final rating = 4 stars in PL --> output image rating = 4 stars

This is the way PL working for rating, in the first state, we respect XMP rating until you change it in PL.

About XMP writing, this is a future feature, we have already this one in the backlog and will let you know when we get back on keyword implementation.

I hope a few words above can help a little bit



Thanks for the update Hieu. This is fantastic news.

I understand that working with keywords in XMP is a serious challenge. In the meantime, would it be possible to at least move the ratings over to XMP?

This would mean:

  1. change in rating in PhotoLab modifies the XMP.
  2. PhotoLab always rescans the XMP files for ratings. The update could be a background scan to allow users to work faster. I.e. the ratings would be cached in database.

Moving the ratings fully over to XMP on a full time basis would be a good trial run for moving the more complex keywords section back to XMP.


Can’t agree more. Especially when you use an external DAM - Photo supreme in my case - it is very important to carry over rating changes done in PL to XMP. Otherwise your external DAM will not recognize these ratings correctly.


Yes, you are talking about XMP writing (rating is part of xmp sidecar), we should thinking to covert all (or max) cases possible. Something like:

  • What happens when we have virtual copies? and rating is not identical for each virtual copy. In XMP sidecar, we can store data for only one image. (therefore in the previous EA, we set the Master image notion, this can help workflow to overwrite XMP sidecar.
  • We should add preference options and let user decide for automatically overwrite XMP sidecar or not

We will keep your feedback and fine tune it when we implement this xmp writing feature
Thank you,

1 Like

Those star ratings are primarily for rating incoming images. Using selection ratings to rate virtual copies should be discouraged. Virtual copies should employ some other kind of rating or comment system (colour labels?). If I were the UX designer, I’d lock the ratings on virtual copies to the rating of the master file to avoid the issue

This an unnecessary and confusing preference. If a photographer has chosen to use XMP and DOP sidecars the XMP rating should always be overwritten.

Consistent behaviour is often more useful to the end user than flexible behaviour. Steve Jobs stressed that it’s the developer’s job where possible to make intelligent choices for the end user. Decisions carefully made save users time.

The deeper issue here is the conflict within DxO to make PhotoLab some kind of monolith program like Lightroom which demands that every other program be subordinate to it and runs off of a huge database or to carry on with a RAW developer which interacts well with other software and stores its data within the file system (.dop and .xmp files). Iridient Developer is an example of clearly the latter. C1 is an example of the former. PhotoLab doesn’t know which one it wants to be and has been walking the fence for the last couple of years.

For most existing users (we’ve all paid a pretty penny for the privilege), playing well with others and compatibility with other software and storing settings separately from a database are extremely important. The Lightroom users (most of whom would never drop €200 in a single purchase for any software, particularly if it doesn’t have the name Adobe on it) targeted by DxO marketing would probably prefer the monolith.

The question is does DxO throw its existing users to the wolves in the pursuit of potential users in the hopes of attracting users who 1. would not pay that kind of money for software 2. are mostly Adobe die-hard junkies 3. the last people to leave Adobe software behind. Never forget the existing Photographer’s Package includes a full copy of Photoshop. Phase One just had a go at pulling users out of Adobe, with an extended half price sale to bring in Sony and Fuji users. I’m curious to know if they made a dent in in the Lightroom userbase or not with that big promotion. Unless there are plans to radically change pricing and positioning, siding with the existing paying users would be both ethically better and commercially wiser.

DxO PhotoLab’s situation with its userbase reminds one of the husband of ten years abandoning his exquisitely beautiful and scintillating wife to chase after a common or even vulgar young nanny. Of course this illogical situation happens almost every day. I.e.: Jude Law and Sienna Miller or d’antan Hugh Grant and Elizabeth Hurley.

PS. The above is written with a smile, not a frown. To amuse, not to offend.


Agree with Alec:

  1. Virtual copies shouldn’t have separate star ratings, and
  2. changes star ratings should automatically be written / overwritten as XMP to the dop sidecars.

I disagree. A virtual copy in my workflow can be a totally different picture (different crop, perhaps B/W, …). Often I export even two versions of the the same source, but they may have different ratings from each other and from the other versions that I don’t export.


I would like to have the possibility for PL to Read only XMP files because PL is not gonna be my DAM anytime soon and I do not want any software to mess with the XMP, especially as long as you are debating those topics. I do NOT want to be an XMP feature beta tester :nerd_face: Thank you.


Marc, If you don’t make changes to XMP properties (ratings, keywords) in PhotoLab, there’s no reason for PhotoLab to write to XMP. If you are making changes to XMP properties, I’m afraid you and everyone else like me who do not use PhotoLab as a DAM do want those changes written. Otherwise we don’t have any kind of sync with our existing applications.

Your point that DxO should proceed with considerable care here not to damage existing data (zeroing XMP files for instance) is well taken.


Since I wrote the note below, I have done bit more exploring.

  1. I find that when you export a sidecar to a Nikon raw image, the exported file name is “filename.NEF.dop”. Although this file looks very much like an xmp file, Exiftool indicates that it is not a xmp file but a txt file.

  2. I have tried every combination of settings I can find but I cannot find any way to transfer color settings, star settings, or any other metadata between dop files and xmp files. this means that I can find no way to use Photo Mechanic to set metadata and then import it to PL3 or vice versa. I may be missing something, but I just cannot find a way.

  3. Metadata that is embedded in a jpg file by Photo Mechanic 6 Plus does not show up in any way in PL3.

This is all very confusing. I hope the developers might be able to shed some light on this. However, I find it disconcerting that it is so difficult to use other programs that all interchange metadata by xmp files that do not play well with PL3.

1 Like

I too have been very confused by this discussion. However, after digging around a bit, here is what I suspect is happening.

  1. All of the external programs/apps mentioned above read and write the metadata for raw files to sidecar, usually with an extension xmp. The format of this file is an industry standard ( Since early 2012, the XMP specification part one, which defines the XMP data model and core namespaces, is an open, international ISO standard (16684-1).) This is how Photoshop, Lightroom, etc. handle metadata. I use Photo Mechanic 6 for my DAM and have the preferences set so that the metadata for raw files are stored in such a sidecar. It is possible, but not a good idea, to embed the metadata in the file. If you do this, it is my understanding that PL3 will not process the file. Metadata for non-raw files (e.g., jpg, tif) is always embedded in the image.

  2. If the preferences are set, PL3 creates a sidecar with the extension .dop. This file turns out to also be an xmp-formated file. You can verify this by using Phil Harvey’s command line tool Exiftool.
    (the simple command to display the xmp data in a file is ‘exiftool filename.ext’. This file is thus a second, separate, and DxO proprietary xmp file. (I note the both files are, in fact, txt files, so you can read them in any text editor.)

  3. What is happening in the discussion started by Brian is that when he goes to IMatch and changes the number of stars, the information is stored in the industry-standard xmp file described in (1) above, while PL is reading their xmp file described in (2). Hence, PL does not see the change. And, vice-versa, when he changes the stars in PL, IMatch cannot see the change.

  4. The consequences of this disparity are significant. For those who use a cataloging program external to PL (e.g., Neofinder, Photo Mechanic 6 Plus, …), to the best of my knowledge they index only the xmp files described in (1). I have not looked in detail at how the metadata that one enters in PL is handled, but some of these data are set up to transfer to Lightroom, but certainly not all. Also, if you need to store IPTC data, as far as I can tell, the is not done in a dop file, but is fully supported by the programs that write xmp files. Caveate–I may misunderstand some of these details and certainly may stand to be corrected.

  5. For my personal workflow, I turn off the creation of the dop sidecar and rely on saving all of my parametric edits in the PL database. I do all of my classification and cataloging in Photo Mechanic 6 Plus (still in beta test as of this writing, but available to all customers). I can then find the images I want quickly and easily. Many readers of this forum do the same thing using other DAM systems as well. Once sorted and selected, I create an empty project in PL3. Then, in Photo Mechanic, if you right click on one of the selected images, you get a choice to ‘Edit Photos With …’. I have set up DxOPhotoLab3 as one of my choices (you get a pull-down, so you can add as many choices as you wish). One click, and all of the images show up in the project perfectly. As noted elsewhere in this forum, you may be able to drag and drop the selected images in your DAM onto an empty Project in PL3, but I have not tried this.

Since I back up my work nightly from my working drive to two separate external drives (a primary and a secondary backup), I also want to backup all of the parametric data in the PL database. Thus, I also copy this database (as noted elsewhere in the forum, there are a variable number of database files–anywhere from 3 to 5 have been documented) to a folder on all three of my hard drives. (My working drive only has images and their derivatives–all of my programs, apps, word processing, etc. are yet on a separate hard drive.)

Hope some of this helps in understanding what appears to be happening with PL and metadata.

1 Like

I can’t remember what this thread was all about, but after a trial and some reading about Photo Mechanic I can say, that you can configure it to save data to the XMP sidecars in a way, that Photolab will be able to read it.

Following topic of the Photo Mechanic documentation page shows the settings necessary for compatibility. Set it for Adobe Products and you should be fine.
Photo Mechanic documentation - Settings for compatibility

You can only use the star rating and the keywords only.
Unfortunately (at the moment) it is a one way street: settings in Photo Mechanic will show up in Photolab after you saved them.
You will not see the color labels as Photolab doesn’t support them.
Unfortunately if you change a star rating in Photolab or add a keyword it will only be saved to the database (or the star rating also to the .dop sidecar) so normally you shouldn’t do it. It will hopefully change to something more useful in the future.
If you export the edited photo, the exported file will have this information too.
The pick/reject (green/red) colors in Photolab are only useful inside Photolab.

In my experience the .dop sidecars are more useful and easier to backup.
These are not XMP files. You probably confuse XMP (a specific namespace inside XML) with XML (a markup language format). The .dop seems more like a JSON, but is rather something else. The categorisation as a text file from Exiftool is correct.
It might only be in the Photo Mechanic Plus Beta, but they were also talking about handling the .dop sidecars for renaming/moving.

Photo Mechanic handling of dop sidecar

You will not really be able to move information from a .dop file to a .xmp file unless you write some special program for it. But if you only change data outside Photolab and use above mentioned settings, you will be able to see them inside Photolab.
I definitely see changes made to star ratings and keywords in Mylio and IMatch inside Photolab.

1 Like

Hi Zoltan:

Thanks for your comments. As far as I can tell, all of my PM6 settings are for Adobe compatibility as you suggest. I still have the issues as I noted.

Regarding PM6, Camera Bits allows you to associate dop files with images that they support, but so far as I can tell that does not mean that they support transfer of metadata with those files. It just means that if there is a dop sidecar in the folder with a raw image, the dop file will not be shown with the thumbnails in the contact sheet.


Like Robert, I would really like PhotoLab to write back any changes to ratings.

In my workflow I rate all my files before bringing them into PhotoLab (just contemplating the slow tedium of rating files one by one in PhotoLab makes my eyes water), in my case in FastRawViewer. That said, among four star and five star files I view in PhotoLab, I’m often tempted to change the grades either up or down. It’s frustrating not to be able to do so.

The way I work around it @RWHendricks is to do a final pass of four and five star images within PhotoLab adding the green pick flag to photos I’d like to process and export. I play with the order when I apply the flag. The green pick flag is really for photos I’ve processed to the end and would like to export. Poor picks revealed while editing (limitations of the RAW file usually) get a red reject sign. Of course none of this makes it back to FastRawViewer (or PhotoMechanic in your case) to my great frustration.

How easy it would be for PhotoLab to apply any changes to star ratings or keywords to sidecar .xmp files, just as it reads them when ingesting a new folder.

I certainly would not go without the PhotoLab .dop sidecars. Any database corruption or a folder move gone astray and you’ve lost years of hard work grading your photos. Take advantage of what DxO does offer us – backup of our corrections work alongside the original image files.


I think DXO should consider cooperating with one of the major DAM software companies, my preference would be IMATCH or PhotoSupreme. Enabling access to processed thumbnails and interoperability of metadata would benefit both companies.

DXO would not lose anything as their own database capabilities would cater for the customers who don’t need an external database whilst the cooperation would allow them to compete more effectively with programs like Lightroom. A win-win situation.

This is a bit like Capture One cooperating with Fuji, Sony and Nikon to offer free raw processor software. The camera companies don’t have to develop and maintain software whilst C1 gains potential customers for their paid software. These days companies need to work smarter not harder, an old maxim that’s still true today.