Are these sidecars the DOP files as opposed to the XMP sidecars in the Metadata tab? Both are called sidecars, none are called DOP.
1 Like
Most raw developer applications store settings and metadata in associated files in order to keep the raw files untouched. Those associated files mostly have the same filename as the raw files they are associated to, and extensions differ and depend on the raw developer app writing the associated file.
Instead of “associated file”, "sidecar file"or “sidecar” is used for simplicity. Sidecars should always stay next to their parent files, like the sidecar attached to a motorcycle.
As usual, you can read about such things in the Internet, e.g. here: Sidecar file - Wikipedia - and it is quite alright to search for info outside of this forum 
DxO uses “sidecar” specifically for their own .dop sidecar files which is unfortunate, because the .xmp files you can find is also a sidecar file.
Here, on the forum, some use sidecar and whether it’s about the one or the other needs to be taken from context, others use the sidecar file’s extension, e.g. .dop, to specify which sidecar they are talking about.
I’m pretty familiar with sidecars (.xmp, .dop, .on1, etc.). It is the confusion between sidecar = .xmp and sidecar = .dop that had me puzzled.
On to some testing…
Sidecar in this context is descriptive, not definitive. A “sidecar file” is any file intended to accompany a primary file.
DxO record values for proprietary algorithms into their .dop sidecars, rather than fitting into the “standard” XMP files. I suspect this is purely because it makes it easy for them to change stuff around as they see fit, and they don’t have to worry about other software potentially writing stuff in there that they would have to at least be able to ignore successfully.
I did the same, other than switching OSs, and got the same result. The keyword was recognized when the .dop file was imported.
This leaves me puzzled as to why an image/.dop keyword from someone else was not properly recognized. Or why @Joanna saw the strange behavior she did in her video.
The test with I ran is fairly deterministic in that I disabled automatic actions and therefore simplified all the logic that acts behind the scenes with metadata that can be in the source file, database, .dop and .xmp sidecars.
As long as one manages keywords and other metadata in an other app than PhotoLab, it is best to handle sidecar import/export manually and to restrict oneself to READ only. This can only fully be controlled by the respective menu items.
Activating automatic read/write/sync increases the risk of messing up metadata.
That suggests to me that PhotoLab has some problems in de-conflicting metadata between possible sources. Maybe even bugs.
Even if there were a way to perfectly decide what gets read and written by what and why…
I have to rephrase: Conflicts cannot be resolved automatically.
For believers in technology: Conflicts cannot be resolved automatically yet.