I have over 300 family raw files that I edited in PL2. I’m now using PL3. I wanted to check that they export correctly in the same way they exported in PL2.
Everything looks the same apart from about 15 images that have healing source point errors. In other words the area that PL2 must of automatically sourced from doesn’t get carried over correctly. I had 1 photo where my subject had a spot on her forehead that I healed in PL2 but when opened in PL3 there’s actually a 3rd eye on her forehead where PL3 has sampled the healing point from her eye instead of the forehead. It’s obviously a big bug.
Thanks for the reply. Yes, but a spot in the middle of the forehead is quite some distance from an eye. That’s a huge difference. Surely PL3 could quite easily sample from the same spot as did PL2?
Effectively, the healing done to images in PL2 when opened in PL3 is unusable. I’m going to have to go back & redo all the healing.
I can reproduce some bad behaviour. I just repaired an image in PL 2 that PL 3 rendered quite badly (on another computer, after copying raw + sidecar), but the rendering also changes when I move to another image and back. Sometimes just momentarily, but even if I export from both PL 2 and PL 3, the result is different.
Hopefully it’s just an unintentional bug and/or inadequate testing, but when I’ve asked support about backwards compatibility in the past I’ve received the fairly unsatisfying answer that it’s possible that there may be changes in rendering, even though they try their best to avoid it. (ClearView Plus in PL 2 was an example if I recall correctly.) If there’s really no better guarantee than that then this seems quite weak compared to Adobe, Capture One, and Exposure (for three), with their process versions.
Well, in most cases the migration of Repair correction (Repair mode) is adequate (a little bit different due to a new algorithm as @Pieloe said but still good enough). So we are interested in your image+sidecar from PL2 to investigate this behavior.
So if it’s possible, please upload them to upload.dxo.com under your forum name instead of “support ticket number” and let me know when ready.
I can appreciate new/better algorithms on newly edited images, but “a little bit different” on editing performed in previous versions of the software isn’t great backwards compatibility. Isn’t there a better guarantee than best effort that the rendering of previous edits will be unchanged after an upgrade; like that significantly changed processing will be a new tool, or that the rendering of previous edits (which Photolab can identify since a version number is written to dop files) will go through an old code path?
I just want to know what to expect. If there’s no guarantee then dop-files should be seen as specific to the version of Photolab that wrote them, and it’s up to me to always export images to a raster format if I want to retain the current rendering. That’s fine, but it negates the advantage of saving small sidecars (with their editing history) vs large tiffs, and I would expect Photolab to at least produce a warning when it reads a sidecar whose rendering it may not be able to respect.
Edit: Although, come to think of it, a warning isn’t sufficient, since by the time I notice a problem I may no longer have access to the old version of Photolab.
Sure, but that’s not the problem. The problem is that discovering that something has changed requires reviewing a potentially large number of images after each upgrade, and adapting to the changes requires work.
Yes, I think you need a better solution for this. If Photolab doesn’t guarantee that existing rendering will be preserved then it’s just a glorified raster editor, since editing has to be saved in a raster format to preserve rendering over time. I think it’s a fundamental property of any editor to be able to open work saved in a previous version of the software with an identical result, and if dop files aren’t a format that can provide this guarantee then it should be brutally clear in documentation and the behaviour of the software that these are version-specific.
Edit: Presumably the database is no better since it contains the same information as the dop files, I assume. There’s something fundamentally wrong if migrating to a new version of the software means that previous work can be rendered differently. It would be more honest to not migrate anything in that case, automatically at least, so that each new version is a clean slate.
This problem has been raised before and got nowhere. Other programs ensure protection as far as they can for edits for pri version edits. Clearly DxO hasn’t taken this on board and needs to listen to customers over this as well as much else. To turn off sidebar saving isn’t very helpful as on occasion the data base needs deleting, indeed there are many experienced PL users who say sidebars not data base is the best option. Indeed there have been users in this forum who have had to delete it to solve problems. What’s needed is to ensure backward compatibility when changes are introduced if other programs can do it why not PL?
Indeed. As it is now, Photolab can’t decide if it’s a raster editor or a DAM. It has a browser and migrates edits as if it were DAM-ish, but if the rendering can change then it can’t be used as anything but a raster editor. (Unless you’re a glutton for punishment and actually enjoy reviewing/re-editing images from version to version …)
Has there been any feedback on or resolution of this? I haven’t heard a thing in the support case that I opened two weeks ago. (Well, except that they couldn’t find my files and could I please upload them again …)
It won’t be a quick fix as you expect to. It will require the change of the significant part of the behavior so you’ll have to wait. And until that the workaround with the manual fine-tuning is the best way out.
The problem is that discovering that something has changed requires reviewing a potentially large number of images after each upgrade, and adapting to the changes requires work.