Option to preserve metadata in XMP sidecars

[RWHendricks (Robert Hendricks)]

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.

Bob

[uncoy (Alec Kinnear)]

@bekesizl

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.

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.

[IanS]

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.

Ian

[Mike1]

@IanS

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 just needs to stick to the latest recognised international standards. That way it remains compatible with all the main DAM packages.

[uncoy (Alec Kinnear)]

@Mike1

DXO just needs to stick to the latest recognised international standards. That way it remains compatible with all the main DAM packages.

Absolutely.

DxO should go back to writing changes to star ratings and keywords (and any pick flags) XMP. That’s where this kind of rating information is stored, in XMP files. Not a database, not .dop files.

Frankly I’d like Photolab to offer a preference to disable the database. That would mean rereading each folder on open (all the .dop files and all the .xmp files). Image previews could be used and kept on some kind of a weekly or thirty day revolving cycle for speed.

The database creates nothing but trouble for those of us (most of us) trying to simply use Photolab as a RAW developer. The pseudo-DAM which does not write to XMP and does not refresh changes to XMP sidecars is just a nuisance and results in lost information and inconsistency.

At the very least, DxO developers should give us a folder refresh option in Photolab to read any changes to XMP sidecars.

Please play nicely with others DxO developers and write your ratings, flags and keywords to XMP.

[John-M (Melbourne, Australia - Win10)]

@uncoy

I’d like Photolab to offer a preference to disable the database. That would mean rereading each folder on open (all the .dop files and all the .xmp files).

This is exactly how I use PhotoLab, Alec. I have no interest in any of PL’s DAM fetaures - - so, I do not need to depend on its database: Therefore, I have enclosed PL in a “wrapper” that first deletes the current database, before invoking the PhotoLab application.

As you say, this means PL needs to read & interpret all my corrections from sidecar/.dop files for each folder that I present it to - - which can be a slow process if the folder contains many (100s or more) {image+sidecar} combos. This works fine with my workflow, tho - as I work with no more than 10s of images at a time, in a dedicated Work-in-Progress folder - after which I move all components of the images (RAW + Sidecar + Exported RBG) to a separate storage location … and then repeat with the next batch.

@uncoy

Image previews could be used and kept on some kind of a weekly or thirty day revolving cycle for speed.

There’s already a means of limiting the number of image-previews held - via the Cache settings in Preferences … albeit, based on cache size - not by time/age.
In my case, I also delete the cache (at the same time as I delete the database) before invoking PL … as its not needed with my batch-processing Work-in-Progress workflow.

John M

[uncoy (Alec Kinnear)]

John, thanks for sharing your workaround in detail and for the tip about cache. It would be wonderful if it would be possible to run Photolab in a way which doesn’t require these database-deleting handstands. With SSD ubiquitous now, there’s really no need to keep file level information (in the hundreds at least, thousands might be an issue)

I move more files than you (I might have 70 files in my five star folder for processing) and have run into issues when I don’t separate five star files into a separate folder before processing (those folders could have a couple of thousand images: sport). Even with the database, performance on the big folders can be an issue. Really better to separate selects before processing.

The reason I’m so keen to see star ratings, flags and IPTC copyright tags back in XMP is that I do make adjustments to those attributes when narrowing those selects from 70 to 40. It’s very frustrating that metadata changes made in Photolab are not shared back to PhotoMechanic, Lightroom, ApolloOne or FastRawViewer (I’ve used all of those programs within the last year to work on metadata, I’m leaning to consolidating on the new Photomechanic Plus which includes catalogues but continues to leverage the OS file system and external XMP files). Unlike Photolab, all of these programs store metadata in the XMP sidecar.

DxO really should cooperate better with other programs and share star ratings, flags and keywords with others via XMP. Just sucking the information in at the beginning and hiding it in proprietary files is a really Adobe/Microsoft style move. It’s very alienating and disappointing.

[John-M (Melbourne, Australia - Win10)]

@uncoy

It would be wonderful if it would be possible to run Photolab in a way which doesn’t require these database-deleting handstands. With SSD ubiquitous now, there’s really no need to keep file level information …

If you mean(?) there’s no need to continue with sidecar/.dop files - then I don’t agree with that; I reckon the complete flexibility of the {sidecar+image} relationship is a key factor of PL.

@uncoy

Even with the database, performance on the big folders can be an issue. Really better to separate selects before processing.

Absolutely, yes … that’s the way to go, Alec.

Regards, John M

[uncoy (Alec Kinnear)]

@John-M

If you mean(?) there’s no need to continue with sidecar/.dop files - then I don’t agree with that; I reckon the complete flexibility of the {sidecar+image} relationship is a key factor of PL.

Hi John, I mean the opposite. SSD are very fast so there’s no need to store information in a database (theoretically faster than reading two hundred .dop and .xml files for a total of six hundred files read to show a folder of two hundred images). Thanks to SSD high I/O transaction threshold there is very little performance penalty here other than loading the preview images, which happens whether or not the XML info (star ratings, flags, copyright info, headline/title, description, coloured labels – last three not available in the Photolab EXIF editor currently) is stored within the XML file where it belongs and not in the Photolab .dop file where it does not belong. DxO is breaking standards here.

It is almost criminal that DxO refuse to store metadata in the XML and only in the .dop file. It breaks photo application interoperability at no benefit to DxO users. DxO does so much right and then they sneak something like this in which frustrates existing users and makes non-users think, oh this might not work with my existing workflow. Worst of all it wasn’t always like this. DxO Optics did not try to bury info Wrong, issues with playing well with XMP files have bogged down DxO for the better part of a decade. In the past, DxO refused to even read XMP file ratings and Optics had its own rating system.

[uncoy (Alec Kinnear)]

High time that DxO breaks the broken paradigm and starts not to just read incoming XMP star ratings but write its own ratings and select flags back to the XMP file where it belongs for proper interoperability. IPTC keywords, headline, description/caption, copyright info also belong there. Photolab should stop worrying about a proper DAM and worry about supporting keywords, headline/title, description/caption in their mini-EXIF viewer-editor just as they support copyright info (a successful implementation, btw).

The IPTC fields most DxO Photolab users need access to are exactly those ones, with perhaps adding location (although there are just too many location fields to make location an easy add). Users who want more than headline/title, description/caption, copyright info and keywords are probably require something like Photomechanic or iMatch which really can not and should not be shoe-horned into Photolab. Lightroom’s own EXIF handling is inadequate, while CaptureOne has gone overboard with IPTC fields:

While it pains me to say something nice about the people who made subscription-only software mainstream, Lightroom seems to have the right number of fields.

As far as I know Lightroom writes that metadata into the XMP file (the preference has to be set on a per-catalogue basis which I find too granular and likely to cause user-error: should be set once globally by a user).

For tif or jpeg files, the information is stored within the tif/jpeg which is okay as those file formats are intended to carry XMP/EXIF/IPTC information and the applications which understand XMP know to look within the file too.

Since Photolab users work almost only with RAW files (I did try to finish my Fujfilm jpegs in Photolab for a couple of months but found the RAW to TIFF in Iridient Developer to Photolab to jpeg output workflow far too heavy) the important part here to keep in mind is writing that metadata and those metadata changes back into the XMP files. It’s somewhat less of an issue than I imagined as Photolab will write metadata changes into its own jpeg/TIFF output.

In my own workflow I start working with metadata again post-Photolab (was using Adobe Lightroom 4, currently trialling with much better results Photomechanic Plus) so any changes to metadata should be in the XMP so I can see changes made to metadata in Photolab. The big issue is with star ratings as I may wish to browse that selects folder with Photomechanic or any other fast efficient RAW viewer (does not include Photolab) and see changes made to star ratings or flags. It’s really a matter of principle. There’s no good reason for DxO to behave badly here by storing shared data like star ratings and select flags, and perhaps later keywords and captions when the accepted vessel for this information is an XMP sidecar.

I hope this information and these examples help some others to puzzle through the challenges of integrating Photolab into a DAM and metadata friendly workflow. Even more, I hope it inspires DxO developers to fix Photolab’s lapses with metadata (store metadata once and for all in XMP sidecars where it belongs; for bonus points, add support for headline/title, description/caption, keywords to the existing EXIF editor).

PS. If DxO improves the EXIF editor, storing metadata in XMP sidecars suddenly becomes much, much more important. Right now the most prudent way to handle metadata in DxO Photolab is to more or less ignore it and not touch it.

[Guenterm (Win11, MAC OS, DPL 5, FP, VP, Nik4, Olympus)]

Good morning all,

maybe some of you will vote for this feature request Possibility to add or change metadatas - DxO PhotoLab / Which feature do you need? - DxO Forums

Thanks in advance and enjoy rest of the week

Guenter