I don’t understand the difference between DOP and XMP sidecar files. At the moment I only have DOP files. Should I turn on the XMP setting if I plan on using image management software? Are image previews stored in either sidecar file, or only in the database?
Than you.
Dop contains the editings. Xmp contains the metadata.
George
DOP files are native PL files with all corrections, adjustments etc. etc. you do in PL.
XMP is a standardized (sort of) file that can contain Keywords and other metadata and can be read by many different softwares.
Typically, in the directory I store my RAW files I have at least 3 files for each RAW file. One XMP, one DOP and the RAW file and maybe I JPG if I have exported.
PhotoLab doesn’t create persistent image previews. They are generated on the fly
Joanna, how do third-party image management programs deal with this?
Thanks, George.
The following text in the PhotoLab Settings window for Metadata doesn’t appear as succinct as your description:
Metadata synchronization:
Enabling this option will keep metadata synchronized between DxO PhotoLab’s database and image files (and their XMP sidecars).Please note: For a master image, metadata from .dop sidecar files will be ignored; metadata from xmp sidecars will be used instead. If not already present, xmp sidecars will be automatically generated for RAW files.
I think that’s left from former times. As you can see
Xmp can be a side car file or a part of the image file itself.
If you want you can read both files with a normal editor. You can see for your self what it contains.
George
There’s the main image, the preview image and a thumbnail.
In PL the main image is used to create the preview every time you open the image. During the first opening of an image the BW thumbnail of the file is shortly used during the time that PL creates its own thumbnail. That thumbnail is stored in the database and reprocessed every time you do an edit.
You can find out yourself too. Take a raw image with your camera in black and white. When first opened in PL you’ll see a BW thumbnail and shortly after that a colored thumbnail and colored preview. Quit PL and start again. Now you’ll see a colored thumbnail immediately.
Using PL as a raw converter.
George
Let me start by clarifying how DxO manage their editing workflow.
- All image edits are stored in the database.
- They are also optionally stored in DOP sidecar files
- All metadata for RAW files are stored in the database
- They are also optionally stored in DOP sidecar files
- They are also optionally stored in XMP sidecar files
This methodology violates SPOD (single point of definition) and can cause confusion when moving image files, when the database can become out of sync with the DOP and XMP files.
I, personally, regard the database purely as a cache and rely solely on the DOP files for image editing data. Whatever you do, don’t attempt to edit the database without expert knowledge. Failure to obey this advice can cause great pain to the brain 
PhotoLab refuses to allow writing of metadata directly to RAW files, based on the unnecessary assumption that the original RAW file should be treated as a “negative” and, thus, should never be edited. This is one of the reasons PL uses XMP sidecar files, so that metadata can be transferred between PL and other editors.
Well, I use Nikon a D850 camera and have the option of using Nikon’s own NX Studio app for their NEF files - but I don’t because it is nowhere near as good as PhotoLab.
However, it serves as a useful comparator for how metadata can be safely stored in RAW files, without affecting the image data.
NX Studio safely and securely writes both image editing and metadata directly to their NEF files, creating a proprietary [NikonApp] section in the NEF file and obviating the need for external XMP sidecars by including the metadata in the exported TIF or JPG file.
No matter what the RAW file type, it can contain anything between one and three JPG preview images of varying sizes and quality, alongside the RAW image data block.
These are used to create the thumbnails that you see in the filmstrip. The full size image in the editor is decoded on the fly from the RAW data block in the RAW file. If you see a slight flicker when the image is loaded, this is because PL uses the full size JPG whilst the decoding is happening and then replaces it on completion. Depending on your computer’s performance, this can be more or less obvious.
In summary…
I use DOP files for image editing data because it means that they can be moved, along with the image file, without fear of database corruption and to avoid errors when moving files.
I use my own external metadata editor to write directly to the RAW files but, if you want to work with certain other editors, you may have to use XMP files to transfer metadata. I don’t regard PL’s metadata functionality to be sufficiently mature or reliable.
Canon DPP also stores edits and metadata into e separate group alongside all the other things that reside in a .cr2 or .cr3 file.
Agreed. Therefore, I do all things metadata in Adobe Lightroom Classic.
I’m not overly fond of subscriptions though. But from an asset management point of view, PhotoLab is simply not reliable enough.
@FrancisM Think of xmp as a kind of Esperanto. XMP has been designed to enable the exchange of metadata between different applications.
In NX Studio there’s an option ‘Save adjustments, labels, and ratings to an adjustments (sidecar) file’ not touch the original NEFs and save edits in separate .nksc files in NKSC_PARAM subdirectory. Bugs happen (as it was the case with CaptureNX2, NX Studio predecessor, which could corrupt the raws), so you’ll be safer with that option enabled, or you’ll have to make a backup of the originals before starting to edit. See https://nikonimglib.com/nxstdo/onlinehelp/en/save_80.html
Joanna,
Thank you very much for your detailed explanation. I was aware of some of the information you provided, but not all. I appreciate the time you’re taking to help me out.
I am now clear on the function of the sidecar files.
Thanks,
Francis
That’s a perfectly clear and concise way to understand PL’s flexibility in working with its database and/or sidecar/.dop files.
I leverage this capability quite literally;
I start PL from a “wrapper” that first deletes all database files (and related thumbnail/cache files) before invoking PL itself.
I rely solely on sidecar/.dop files for image editing data retention.
This approach works very well for me, because I don’t care about features that are not retained in sidecar files … such as Keyword association - nor do I use Projects - and I care not one iota about Stacking !
…dop files contain info for virtual copies. So VCs aren’t lost with the DB.
True - and that’s another great annoyance about auto-Stacking - - pointless Stacks are RE-created each time PL encounters a sidecar/.dop containing VCs … Grrr !!!
Grrr too !
I have several times created variants of some pictures and I don’t even know how to suppress those*.
Neither I am able to compare the variants for the settings.
*I tried to apply recommandations read on this forum…
There must be something about stacks. Neither PL nor Lr can be set to NOT ALWAYS stack images. Painfully boring limitation!
Rename the copy you want to keep, then edit the .dop sidecar file and delete all the entries NOT concerning the keeper. For a less esoteric approach, copy the settings of the VC to the master and delete the VCs. Deleting the VCs will also remove the stack.
You’re not alone in this. To check settings, flip images to and fro. Filtering for active tools can help.
Once upon a time !! - the quick/easy solution was to use the option to Sort by “Virtual copy number” … and then select all the VCs subsequently grouped together for bulk deletion.
HOWEVER, the introduction of annoying Stacks has “broken” the Sort function - because grouping by Stack overrides grouping by the selected sort-sequence … 
For this special purpose, can’t you …
???
Yes, but … that’s a special workaround for a feature that’s been “broken” by a new feature.
Perhaps diligent beta-testers pointed out to the PLv9 dev. team the issues and implications of auto-stacking VC members, but;
perhaps there was so little opportunity for meaningful interaction between beta-testers and their handlers that the downsides of this decision was not properly appreciated by the dev. team;
and/or perhaps the PLv9 design team chose to proceed regardless.
Who knows ?!
