It seems I read here some saying Photolab is “reverse ?” compatible.
I have to revert from V8 to V6 because I have a job to deliver and V8 crash incessantly even after deleting database and repair.
EDIT : and uninstall, clean everything possible, and reinstall.
But when I open work done in V8 even with tool existing in V6, I only get right virtual copies number but no settings done in v8.
Any thought ?
Sorry to see what you’re going through with PL8. Hope it gets fixed soon.
The terms “backward compatible” and “forward compatible” require context to be correctly understood. I prefer plain examples. As you’re seeing, taking work that was done in V8 and opening it in V6 does not work. V6 can’t read the edits from the sidecar, but probably does create a virtual copy in order to preserve those edits in case you open the work again in V8. (So I’ve been told.)
V8 will read sidecar data created by an older version (V6) and will usually render it the same.
@JoPoV DxPL is forward compatible not backwards compatible between major releases.
So neither the database, DOPs nor presets will travel backwards between releases.
Forwards compatible is OK
@Egregius Not in any tests that I have done!?
I’m probably remembering that bit wrong, then. 
@Egregius I believe that you are but I am concerned about the comment from @JoPoV
Again I get nothing just an empty [M]aster with the opening preset applied. As far as I know DxPL ignores a DOP it doesn’t recognise completely, will test shortly.
PS:- If the DOP actually came from a previous release and was never edited or exported in the later release then it can travel back because it arguably never travelled forward!?
Test:
4 images with 3 VCs for each in PL7:-
Discovery and export from PL8 which failed to create PL8 DOPs:-
Soft Proofing turned off which forced DOP update to PL8:-
Re-discovered in PL7 but with PL7 database still intact (Soft Proofing still present), DOPs ignored and data taken from DB:-
PL7 database emptied and PL7 rediscovered the PL8 DOPs but ignored and all VCs and edits missing:-
What happen is :
When work done in V8 is opened in V6 I get the same number of virtual copy than what has been done in V8, but settings are default V6 preset (optical corrections only for me).
Then I did not do any modification on this directory in V6. I just see I couldn’t take over the work shown to the customer in V8 from V6.
And so when I opened the same directory in V8 again after that, no work done in V8 was lost. Settings are what has be done in V8 (and I deleted V8 database in the meantime - so it is a sidecar memory).
PS: the dops came from V8. This has begun as a fresh new V8 project.
Test this first with copies of files:
PL8 edits recorded in . dop files can often be made to work in PL 6, if we edit the . dop files with a text editor and decrease the two version number entries by 2.
Please note that new feature edits will be ignored. Exporting PL6 settings to . dop sidecars will delete the new feature parts in the sidecar.
Again, test with copies snd be aware that this workaround is not officially supported by DxO.
@JoPoV Not in any test that I have ever done, if my aging memory serves me correctly. (Please provide snapshots for any examples you have if possible).
The basic structure of the DOPs has not changed as far as I can tell, for some time at least! I have only been playing with the internal working of the DOP since PL5, but each copy is started by the “Albums” entry and terminated by the UUID.
Actually there is a “{” at the start before the “Albums” entry and a “}” after the UUID. So we have
So it is possible for a previous version to recognise that VCs exist but in all my tests the Version fields seem to control whether the version of DxPL will even acknowledge the existence of the DOP, i.e. its behaviour seems to show that it does not.
So I tested between PL6 and PL8,
PL8 discovery of directory with PL6 DOPs:-
PL8 after adding a VC to image 1 and 2:-
PL6 after discovery with empty database:-
If I didn’t clean down the PL8 database then PL8 ignored the PL6 DOPs and showed the contents from the previous PL7 tests.
If I didn’t clean down the PL6 database it ignored the PL8 DOPS and continued to show the state before the DOPs were altered by PL8 from the database. The new state of PL6 was not reflected in the DOPs, they remained as they were before the PL6 discovery, i.e. two PL8 DOPs and two PL6 DOPs
If you open the same directory at the same time in two versions (copies) of DxPL you typically wind up with some unwanted VCs.
I will test what happens between PL6 and PL8
Set all entries to DP XD in PL6
This is the state of PL8
I will repeat what I’ve done and will take snapshot, but later. I’m still in a hurry.
In my experience that is generally the case.
However, I have come across one circumstance where the syntax of a tag was changed rendering the file unusable.
This was with a specific camera and tag, but may be more generalized.
The eventual solution from DXO was to edit the offending tag manually. It worked, but is a PITA if you have many to re-edit.
The change was from ‘xxx’ to “xxx” or vice-versa, I have it recorded somewhere…
Richard
That is kind of the same i have in my database.
https://forum.dxo.com/t/big-mess-in-database-with-new-version-and-old-version-installed/41150
I opened the same directory in V8 and later in V6 again, now my DB is messed up. Virtual copies over and over, 2 or 4 for each image.
Did not tried further until now, but this is really a bad upgrade path, to install it in parallel. I also did not found any documentation from DXO how exactly a upgrade from old to new version should be done.
The troubles started when i discovered that all my projects did not appear in the newer version…
Bruno
Unfortunately, you haven’t followed an upgrade path. You have followed a rollercoaster path between versions. This is never going to end in anything but tears.
There is one inviolable rule - if you want to revert to using an earlier version, move or copy the files to a different folder. Both the DOP files and the database are unidirectional.
can you show me a link to a documentation about the upgrade path ?
I did not see any…
thanks
Bruno
Not really but, although you can use different versions simultaneously, it’s going to cause confusion to regress files.
There might not be any official documentation but there is one simple rule - don’t ever use an earlier version on a folder that has already been touched by a newer version
not 100% sure, i think, it begun after i imported the V6 DB into V8.
How did you solve the problem that in the newer version, the projects are not shown ?
Again, if automatic export and Import of sidecars is disabled, the VC issue should go away Going back to earlier versions of PhotoLab is possible - and switching to and fro in combination with sidecars raises VC hell.
Try the procedure I outlined above, it works on Mac and might do on Win too.
HI, @BHAYT
I tried to reproduce what I describe before, so I created a test directory, and it didn’t procuded the same result. It produced what you get.
But I have ABSOLUTLY no doubt of what happened when I did it. But I don’t have the strengh to find what difference is between creating this test project and operating on the real project I had (I’ve finished my job but this has been a nightmare and I’m exhausted and don’t want to go any further).
So, sorry, I can’t give you any clue.
@JoPoV I didn’t set out to prove that you were incorrect in your description but rather to find out whether what I thought should happen actually does happen.
It is so often the case that a situation arises where taking snapshots as you go would help no end but by the time you realise that fact it is too late and transient problems are difficult to test because they are just that - transient.
What I reported and documented fits with my belief that DOPs from a later release are always ignored, except to read the DOP “header” i.e.
Sidecar = {
Date = "2024-07-18T17:08:26.7999682Z",
Software = "DxO PhotoLab 7.6",
Source = {
CafId = "C54817a",
Items = {
and/or “trailer”
}
,
Version = "18.6",
}
,
ShotDate = "2024-06-10T19:08:35.9200000+00:00",
ShouldProcess = 2,
Uuid = "710ADFE5-D9E4-403C-B273-B143A7815B04",
}
,
}
,
Uuid = "ABB8D485-4109-4A64-8C3D-3F4E9489B137",
}
,
Version = "18.1",
}
and decide that the DOP was not intended for that release and ignore it.
As @platypus has suggested if the Version fields above are adjusted then an earlier release can be “fooled” into at least reading the DOP contents from a later release.
The risk is that the later release may have new edit features (commands) which the earlier release will not recognise and will ignore (guessing) or existing commands that have changed in format or command response which could well and truly play havoc with the earlier release.
These tricks have their place but it is important to take dumps of the database frequently.
Arguably the biggest problem with testing a new release is the fact that the new DOPs are not really compatible with an earlier release which makes going back to a previous release problematic to say the least.
This is “easy” for the database (providing dumps are available) but the user is left with incompatible DOPs from the later release, unless copies have been taken of the DOPs prior to testing the new release. Effectively the DOPs are now a liability because they are incompatible with the database.
Possibly the better strategy is to copy the DOPs and remove them!
Open the old database and force the DOPs to be recreated from the database using the export command
If the later DOPs have not been removed before executing the DOP Sidecar Export command then the following warning will be issued
so there is a way of overwriting the later DOPs at this point and realigning the DOPs and content with the re-instated database.
New releases introduce new features and these might be the reason to get a new release in the first place. Whenever I edited dop files, new features were always ignored except in one case a few releases ago.
PhotoLab’s programmers have been smart enough to make PL act gracefully on such hacks. Thank then for that.
In general, I set PhotoLab to neither export or import dop files and I always test with copies in a single test folder. I also keep the old release and/ or its installer for a while before switching. macOS let me do that easily and it also provides backups of the DB. On Windows, these precautions might be more difficult to implement.
