Thank you for digging.
It’s not your fault if it is hard for me to follow up on some topics.
@JoPoV I will try to summarise things wherever possible, if I undertake more testing/investigating.
In the meantime be careful with that second table in my post because I need to review it for accuracy but not today!
My DOPs haven’t disappeared. Rediscovered now.
I had some kind of database problem a while back and Under ADVANCED HISTORY my photos all say “Imported on Nov 27th 2023”.
As far as I can see, DxPL doesn’t retain the detailed edit history once you’ve closed it.
The whole thing seems a bit of a jumble. Different bits of information are stored in different places, in some way dependent on parameters, and have different retention policies.
My printed User Guide (from an older release a while back) says very little about sidecars, DOPs and the database, and what it does say is postponed to the very last chapter “Menus and key shortcuts”. which is odd for something quite fundamental. I see the current version, not available as a pdf, has a bit more including some useful FAQs, but still insufficient I think.
My current settings are:
I’ve never touched the metadata and sidecars menus in the third screenshot
The documentation for this product is generally pretty good, but this area ought to be clearer. (Preferably rationalised in the software first)
P.S. Thanks so much for such helpful and useful replies / discussion
1 Like
The primary place is PhotoLab’s catalog a.k.a. database. DOP sidecars contain most of what is in the database, but a few things are not in them and this depends on whether one uses PhotoLab for Mac or Win operating systems and on the major release of PhotoLab.
What is included and what isn’t has been written over and over again in the forum, search and you might find!
Thanks. I’ll do a search of this forum then. It would be nice if it was in the user guide rather than having to search forums . And not everything written in a forum is correct …
Afaik, there is no alternative guide to PhotoLab (other than the one I link to below) and I suppose that the user base is way too small to justify the effort it takes to write such a guide. Moreover, features evolve over time…which has also brought DxO to not provide a PDF of the current DPL. Nevertheless, the site below exists and is kept alive by recurring help provided by the respective contributors.
1 Like
And, one might add, follow your own advice … 
(Apols - I just couldn’t help myself 
)
Have you checked the source for undortunately? 
It was an exact copy of BHAYT’s post, and I haven’t seen this typo, I just related to the sense-upside-down of the whole sentence.
As for the superfluent dash: you’re probably not very aware about writing in another, non-native language as you already enjoy the convenience of never need to countercheck a sentence in a language translator. I wonder how you’re writing skills in French, Spanish or German are 
? Just remember, this site is run by a European company.
“Very much depending on the translator-app’s quality”? I thought so. Thanks anyway for taking the trouble.
Oops … Ahhh - - You’re correct; I did miss that !
I do that all the time - as per here, and above … Does it cause a problem ?
@RobEW As @platypus wrote, the edits and the metadata are held in the DxPL database, which is actually the primary storage mechanism for DxPL.
The DOP is effectively a portable copy of the database entry for the image, including metadata but proprietary to DxPL. For metadata to be visible to other software it must be written back to the image, either as embedded or sidecar xmp data.
DxPL only writes the metadata for a RAW file to an xmp sidecar file, either an existing one or it creates a new one and only when it has been “given permission” to alter that data.
That “permission” is either via setting ‘Option 1’ as shown in the table in my post above Newbie - sidecars or catalog? - #40 by BHAYT, which will read and update the image metadata in DxPL when changed externally by another program and also update the image metadata if it is changed by the user in DxPL.
The alternative is to leave Option 1 off (not set) when data will only be written back to the image using the ‘Write to image’ command, but will still be included in any exports made unless the export options are used.
So with AS(ON) (Option 1 set) if the metadata is changed within DxPL the new data will be written to the database, to the DOP and to the embedded metadata for a JPG, TIF(F) or DNG and to the sidecar file for a RAW.
With DxPL you cannot have AS(<-) without AS(->) hence AS(ON) means AS(<–>). So its either a two way automatic operation or a manual operation using ‘Read from Image’ and ‘Write to image’ commands as and when (if) the user chooses to use those commands.
The database contains data about ‘Projects’ which have no external presence, i.e. lose the database and you will lose all the ‘Projects’ data on both Windows and Mac.
On the Mac, DxPL also maintains the ‘Advanced History’ for an image beyond an editing session and that is also maintained only in the database so will be lost if the database is lost.
On Windows, ‘Advanced History’ is only maintained for the current session “somewhere”, i.e. not in the database and is “lost” when the current DxPL session is ended!
So no issue with losing the ‘Advanced History’ if the database is lost because on Windows it is not so ‘Advanced’ and doesn’t survive from one session to the next anyway!
I believe there has been changes in the way DxPL works, possibly at some point in PL6 but certainly present in PL7.
-
A DOP is not immediately created after discovering a new image and applying the default preset. So if that is all a user does then the directory will contain no DOPs until an image is edited in DxPL when a DOP will be created for the edited image only (tested on Windows).
-
If the metadata is imported with AS(ON) then DxPL will not write back to the external metadata until a change is made to the metadata within DxPL. Although that change might be as simple as changing a ‘Rating’, the write back will apply the DxPL hierarchical keyword formatting (determined by options 2 and 3/4) which may well change the format of the images keywords (particularly if assigned by another software package).
@JoJu and @John-M Undortunately I have switched to using Chrome (from Opera GX) because I seem to have a memory leak problem on my main computer which appears to be exacerbated when using Opera GX (but still occurs even if I don’t).
I hadn’t turned spelling checking on in Chrome (I have now) and I have developed a worrying habit of hitting the adjacent key, d instead of f, in this case!?
That does not excuse me missing “not” from the original statement, now edited in the original post.
One db thing to be aware off if its not unknown to find a problem using the program needs the db to be deleted due to corruption. Less so now but at one time the first thing support had you do was delete it. In my case I dont use it and copy imiges between laptop and desk pcs with no problem. But I use a separate dam that can create project’s if needed.
@John7 As you well know moving image and DOP data between one computer and another and back can cause problems, although I have done that successfully in tests and DxO could provide simple options to avoid the problem entirely if they so chose.
However, I have tested using one set of data, e.g. on a NAS, and accessing that data from two machines successfully providing a directory is only ever open in one copy of DxPL at any one point in time.
My tests had DxPL active on both systems throughout the tests but being careful to never open the same directory on both machines at the same time, otherwise “Unwanted Virtual Copies” are an immediate consequence (if I remember correctly).
However, that does not address the issue of using a laptop during a field trip, transferring edited images to a desktop (complete with the DOPs) to continue editing and/or exporting. That should always work but the potential risk is when those images are returned to the laptop when a mismatch can cause “Unwanted Virtual Copies”.
However, as I stated above I have tested that and proved to myself that it works, i.e. the receiving system (the desktop in this case) uses the UUID that identifies the entry in the original database (the laptop) from the DOP and does not allocate a new UUID unless that UUID is already in use on that system!
Hence, in most cases the UUID in the DOP does not change and that DOP will be accepted back on the first system without any issues (according to my tests)!?
I suspect, but cannot prove that DxO changed a strategy of always allocating a new UUID to an existing DOP when first discovered, to one of using the existing DOP UUID unless it is already in use on the receiving system at some point in time?
Luckily I have never had any of the problems copying both ways
Thanks - they look useful resources.
Thanks for that explanation. I think I’m getting a better mental model of how it works.
I hope you are having better luck than I am trying to fit a replacement shower hose! Plus I think I left all my washers with my son, 55 miles away!!
Another excellent feature of .dop/Sidecars (making them very “resilient”) is that they’re impervious to filename changes … that is;
-
One may have processed an image named, say, DSC00001.RAW with PhotoLab
– and PL will create an associated Sidecar file named DSC00001.RAW.dop -
Later, if one renames BOTH files consistently then PL will happily accept and apply all correction details in the Sidecar file to the associated image file
– Provided the (re)naming is consistent, such as, say; ABC00001.RAW & ABC00001.RAW.dop
2 Likes
It might work if you rename the file within DPL, but will it work if you rename from the OS level? In the DOP file there is the ‘Name’ field which points to the source. Maybe it’s not used? I didn’t have time to check it…
Yes - no problem. PL simply updates the “Name” stored in the sidecar/.dop file.
However, if renaming at the OS level then it’s safest to do so with PL NOT currently running.