I recently expanded my NAS storage and just decided I should use it as the target for my photo archiving (a copy-never-delete version of my photos to guard against accidental deletion of the originals).
I’m running a command in the zsh terminal on my Mac to copy each year over. As it does this, all the file names whizz by.
While this is happening, I am noticing that every DNG file has a matching DOP file. This is new! I use a very similar backup process to the cloud where I often found I had new DOP files on old photos, because I’d go and edit them.
I don’t think I have even opened every folder in PL9 and there are certainly many thousands of photos I have not edited, ever, yet everything seems to have a DOP.
I wonder if this is a change in order to remove reliance on the database?
I’m not seeing this on my Win 11 laptop running the trial version of PL9, which is a device that’s never had any other version of PL on it. The only .dop files on this machine are for those images that have been edited by PL9.
The archive command was listing every file as it copied. The vast, vast majority of the time, it was dop, dng, dop, dng, dop, dng, dop, dng, dop, dng, and so on.
I was just thinking that I have exported every photo, to create a low quality JPEG of everything. Perhaps that did it? Does that implicitly apply a default preset?
PhotoLab has to DO something in order to produce a JPEG. And if auto.i/e of .dop files is switched on, that should trigger the export of the .dop files. At least that’s what I see on my Mac…
That is why I set PL to not sync metadata and auto-i/e sidecars.
PL (n) is also very stubborn in NOT accepting dop files from PL (n+x) - what a way to say that sidecars aren’t backwards compatible - even though most settings transfer downwards when I change the version numbers in the sidecar files.
If PL (n) would simply ignore settings from PL (n+x) that it can’t handle, sidecars would be much more useful for people working with different versions of PL…something that is highly necessary now…with the somewhat shaky state of affairs in PL9.
It sounds simple, but it’s a level of complexity — and therefore a source of bugs — that would serve so few people that it’s just not worth it for them.
Also, how can they predict what feature changes may come in the future? How does PL8 know what to ignore if PL10 has yet to be even planned?
For example, PL10 may introduce a change to the interpretation of parameters for some setting (such as recent change to “intensity” of Lens Softness correction) - which PLv8 would not know to ignore.
Essentially, whilst PL’s current approach may be “annoying” … it is “fail-safe”.
Imho, a recipe for disaster. Imagine the database is lost and your backup is quite old.
In theory, newer PL8.x and PL7.x minor versions could have added support for PL9 dop format. Is it worth the effort, risking introducing new bugs? Just curious, what would be the reason to use PL8 on PL9 edits? If there’s a fundamental problem with new release, just rollback to previous minor version (requires keeping previous installation files, but that’s common sense).
@zkarj Exports are logged in the database, that shouldn’t/doesn’t create a DOP for the exported file but, as has been stated, the export action is also logged in the DOP of the source image, hence the creation of a DOP regardless of whether any other or no other edits have been applied to the source image!?
If those exports do not contain any meaningful edits, i.e. they were “just” exports, then you could “simply” delete those DOPs but if you rely on DOPs to preserve your edits then beware deleting image DOPs that also contain real edit data.
So we have two quick exports of a JPG to a JPG and and the Win10 DOP
I use PL as a plugin for Lightroom Classic. And as long as PL has no sensible maintenance functionality, I won’t switch. And Time machine gets me regular backups.
As for sidecars: DxO could improve the situation by giving the sidecars a name tat refers to the maj. version of PL. Overwriting seems rude, specially during trials.
Inner workings: They change occasionally indeed, but I’ve not come across difficulties so far when I made sidecars backwards acceptable. Values in the UI might change, but often enough, this is compensated by parameters being stored a floating point numbers in many cases.
