Workflow and/or Preference settings in DXO PL4.3.1 for a two computer workflow

Alec, the topic has been discussed in the forum elsewhere - and you can easily test it yourself and you should do it yourself in order to get the results that apply to your environment and version of DPL used.

Let’s look at the following scenario:

  • Computer 1: Rate, cull and keyword images, then copy keepers to Computer 2

I observe the following with .dop sidecars written by DPL version 4.3.1.60

  • In Library Module: Rating transfers to “Rank”
  • In Library Module: Traffic Lights transfers to “ShouldProcess”
  • In Customise Module: Author and Copyright transfer together
  • In Customise Module: Keywords do not transfer to sidecars

While the above does not look too bad, keywording is something that should be done close to shooting time. If you do that, your effort will be lost if you only transfer the image and sidecar files. Note that I tested all of the above on a single iMac running macOS Mojave.

Future developments might change what is written to sidecar files, which means that all of the above was maybe just an exercise headed for the bin. This is why I recommend that people should run their own test before committing to whatever comes their way.

Edit history also doesn’t transfer to .dop files. Incidentally I don’t use XMP files at all. I would prefer the keywords are stored in the dop. Files too…. Or perhaps all the edit information also be stored in a customized section of the XML file so I don’t have to deal with two sidecars for each raw file…

Either way really. The worst scenario is the keywords are only stored in the database.

1 Like

The standard is a XMP sidecar in this case.

1 Like

Our preferences are irrelevant here, really. The correct standard is keywords and ratings in XMP. What’s cool is that XMP can also store crop information which means we could bring in crops from triage tools like FastRawViewer or Photo Mechanic. Getting crop info read from or stored to XMP would be a bonus. Keywords in XMP is standard fare. Doing anything else is deliberately obstructive, hindering interoperability.

Diminishing interoperability is never good for a company with a small market share. Can work for a market leader like Adobe these days or Microsoft in the old days and Apple sometimes.

1 Like

There’s really no reason that keywords couldn’t be stored in both files. ( see you conveniently left off the last word in my statement, “too”.) If there’s an XMP file then the XMP file should be updated. If there’s no XMP file then store in the DOP. Or store in both. If there are keywords in both files then take the XMP keywords over the DOP ones.

Or… as I said, and you seem to have ignored, perhaps the DOP file can be dispensed completely and all the DXO edits stored n the XMP file. The standard is designed to be extensible, allowing users to add their own custom types of metadata into the XMP data. So why not?

1 Like

Yet more proprietary data in XMP files would be really bad IMNSHO.

XMP as the standardized exchange for user provided metadata, application specific sidecars for the raw developer.

With a reasonable DAM, it’s no problem to rename or move these file sets around.

1 Like

Regarding the original poster’s topic, I can do nothing but advise to strictly separate what is done in each of the application instances that are used on each computer.

With PhotoLab 4 and its current limits, it seems to be okay to cull and rate images on one computer and also change a few fundamental items like WB and exposure. Everything else should be done on the “main” computer imo. As of today, keywords “don’t travel”, so don’t waste your time keywording on the “aux” computer.

Maybe that DxO will provide better means for a more-than-one computer way of working, something that most customers who travel would certainly appreciate.

1 Like

Why? Adobe does it…
The standard expressly supports it.
Why is DXO not allowed to do what others do?

Mike, you seem to like to deal in absolutes or in random. The XMP file specification includes detailed information about how to store and exchange keyword data, rating data and copyright data. There’s limited support for cropping (nothing like what is in the full Viewpoint), white balance and luminance. .dop files make sense for proprietary data related to image processing.

I’ve looked a bit deeper. Quite a bit of processing data can be put into XMP, according to Thom Hogan:

Moreover, things change in the raw converter world fairly often. Adobe has changed its underlying demosaic engine several times. Moreover, one source of recent complaints from Nikon shooters is that Adobe is now working with Nikon to produce raw conversions based upon camera settings (for the D780, Z6, Z7, and Z50). Those are coded into the EXIF as XMP data for exposure, highlights, shadows, luminance smoothing, luminance noise reduction detail, luminance noise reduction contrast, color noise reduction, color noise reduction detail, color noise reduction smoothness, sharpness, sharpen radius, sharpen detail, sharpen edge masking, contrast, saturation, and Picture Control. Note those last three. They pretty directly change color (though so do the other things and how white balance is set).

I would still suggest that DxO Photolab only read from these settings not try to shoehorn their own process into XMP. However meta-data should never be stored in .dop files, only image processing data.

A high degree of interoperability makes minority market share software more attractive.

Agreed. It is difficult enough trying to read simple metadata like Rating or Keywords when some files may contain them, some may not, some may have XMP sidecars, etc.

It is already bad enough that image editing data is stored in the PL database as well as in DOP files, causing synchronisation issues when files are moved from one computer to another.

Like several others, I do not want that problem but, even if I elect to use DOP files, PL insists on writing it to the database, thus forcing me to regularly delete the database in order to avoid confusion.

I’ll say it loud and I’ll say it clear -

SPOD !

(single point of definition)

Otherwise known as a single source of truth, I cannot emphasise just how much anguish synchronisation of multiple “truths” can cause.

There’s a difference between DxO being allowed to do something and DxO wanting to do something :stuck_out_tongue_winking_eye:

Also, storing anything in the DOP is only going to be useful to DxO apps. Nothing else reads it and, from my experiments with them, nobody is likely to want to - it is a non-standard layout that cannot be easily parsed by any of the standard mechanisms like JSON and XML

1 Like

Adobe is no reference. They do what they want because of their market power, not because they have particularly good ideas.

It’s not about “allowed” but about doing the right thing.

1 Like

If you ask me everything should go in the XMP file. I also agree a single storage location is best. (And DXO supports this if configured properly.) The database is mostly useless and frankly corruption risk means if something goes wrong you lose everything. The XMP standard includes a provision for unstructured data or custom data. All the contents of the DOP file could be placed in the XMP file with key elements pulled out into the standard XMP fields (or not).

I’m still not sure why some advocate for two different sidecars when all the data can be stored in one industry standard XMP sidecar.

Anyway DXO can and will do what they choose.

i suppose one problem is that DxO editing data is non-standard and can be quite voluminous and, on top of Adobe’s that would make for a very large sidecar that takes longer to parse every time you want to access the image.

1 Like

The parsing of the largest XML file you can imagine would be a tiny fraction of the parsing of the RAW file attached to it.

I am glad you and others are interested in this topic. I have never had any problemslike this with free Nikon software ( View and Capture and Studio) from 2006 through 2021. If Nikon can figure out how to avoid these problems, I think DXO should be able to too. I have always used a two computer workflow.

Here is an update I just received from DXO Support Team 1 on July 28th:

"I was checking those points with our team, and I can confirm that .DOP Sidecars do include star ratings but DO NOT include keywords.

Keywords are kept in the database and they cannot be moved to another computer in DxO PhotoLab 4. So that’s the reason for your issue here.

However, this will be improved in DxO PhotoLab 5."

When I received this I emailed to Support thanking them and asking them to address my specific Problems in (1) and (2) that deal with Master and Virtual copies and Star Ratings that they have not yet addressed as far as I can tell.

Given that something will be done in the next DXO update, if any of you have good suggestions to offer to DXO, I would let them know what they are.

1 Like

Thank you for your persistence in pushing these issues forward with DxO and thank you for the update on current status.

Separation of metadata into XMP files and image data into .dop files makes perfect sense and would preserve the largest possible interoperability. The ability to read crop information from incoming XMP/image pairs (until the .dop file is created) and all would be right in the Photolab world.

Well, almost. Nothing should be stored exclusively in the database. There should be an option to simply disable the database and store metadata and image processing data only in .xmp and .dop files for perfect portability.

The only value in the database from my perspective is the management of the image cache (for performance optimization)

2 Likes

If You have source images on one memory, that you switchet, dop file have every informatiom about edit this file.

Case with database may resolve sharing it via cloud. In preferences You could change the path where database is stored. For each computer You type the same cloud path and database is the same for each instace and database aggregate all action.

I posted a new thread about whether I can allow both my Desktop Mac Mini computer and my MacBook Pro could both access a folder with the photos that came from both places. It was suggested that I come here to this thread. I read the following, and a lot more:

I don’t use PL5 for anything other than editing. No need for keywords. I think I’ve come to the conclusion that if I delete the PL5 database on both computers, this idea of one large folder “somewhere” would work, but it’s a bad idea.

If that is true, is there a problem with copying the entire folder structure from my MacBook Pro, and copying it to the appropriate area on my Mac mini?

I think the safest way for me is to start a new “2022” master folder on both computers, and over time, move anything I add to the MacBook Pro to the folders on the Mac Mini. Then I can delete them from the laptop, or just leave them in storage in a folder on my external drive.

I think the keywords in the dop sidecar file has been solved with 5.0. Seems the windows version doesn’t retain advanced history like on the mac. (This should also be saved in the dop sidecar.)

Aside from that the actual database becomes mostly useless as far as I can tell except for “projects” (maybe the database is used for cache tracking too?)

Probably you can delete the database on startup each time and not have any issue sharing a folder between two computers. You may have to do some tests to see if it works for you.