@stuck That might need to be modified to English in order to not insult a sizable chunk of the Welsh, some Scots and some Northern Irish!
@platypus I think you published something like your post above before and I am sorry if I appeared to ignore it I didn’t but I did, i.e. I ran some tests of my own which had differing results between the tests I ran and then reran and because I could not come up with a definitive strategy I failed to publish, sorry for apparently ignoring you previous post!
So I will try to document what happened to my tests here but must emphasise that I have run into yet more problems when I attempted to repeat my tests for this post.
Unpublished Post in response to forum.dxo.com/t/kludge-how-to-make-a-master-of-a-vc-on-mac/38581:-
I have always felt that DxO could have provided coding to completely prevent the “Unwanted Virtual Copy” scenario!
I also believe they have changed the product somewhere along the way so that the product does not automatically assign a new UUID to an image when a DOP is present unless the one being presented is a UUID already in use (I would expect this to be extremely rare but not impossible).
This makes “round-tripping” an image with edits, e.g. from laptop to the desktop and then back to the laptop, less likely to result in “unwanted VCs” but they still crop up from time to time!
However, a simple test in DxPL with a request to the user to make a choice instead of automatically creating a VC, could avoid the current fallout from the problem.
With respect to the old scheme that @platypus remembers (as described in this topic and the reasons behind it in your post above) I am not sure that will ever return, so simplifying a collection of edits by deleting is only going to work easily for the VCs and the [M]aster is always going to remain intact or be completely deleted from the database and disk.!
Any attempt at “external” adjustment would lack the main feature of being able to actually see the images rendered which is essential to aid the user to make the decision as to what is going and what is to remain.
The best scheme that I can suggest is to leave the [M]aster intact and create VCs for editing and creating alternatives. When the time comes to “thin” the edits down then copy the best corrections to the [M]aster and delete all or most of the VCs.
To swap corrections between VC’s or between a VC and the [M]aster an additional VC is needed to provide the required “swing space”, i.e. copy edits, Iptc and keywords from A to “Swing” VC, copy edits etc. from B to A and then copy edits etc. from “Swing” to B and delete “Swing” when no longer required…
Because both your proposed technique and @platypus’s technique are excruciatingly boring and tedious as is the process I have outlined below, when executed manually.
However, the process can be automated with the help of coding and that makes it possible to run through an entire directory of hundreds or thousands of images as and when required, e.g. when an entire directory becomes full on “unwanted VCs”!
@platypus Why bother to destroy the database!?
Here is a test directory complete with [M]aster and VC[1]
and also complete with projects
The way that the data is arranged in the DOP is as follows
All the metadata and edit data are to be found after the “Album” heading in the DOP, that includes all the metadata, so having ensured that DxPL is not using the directory to be adjusted and having secured a copy of the database before potentially “trashing” it by accident, it is possible to fiddle with the DOP before it is then re-discovered in DxPL.
Intentionally trashing the database would destroy any projects and on the Mac, advanced history as well. If it is possible to avoid any unnecessary destruction of the database or DOPs etc. then I believe that to be the better course of action.
I did the following with DxPL(Win) running
-
Extract the [M]aster details
-
Extract the VC[1] details
-
Create a new DOP containing the Header, VC[1] details,[ M]aster details, + the Trailer
-
Swop the UUID between the, now re-located, [M]aster and VC[1} entries so that the (new) [M]aster contains the VC[1] data but with the [M]aster UUID and VC[1] contains the old [M]aster data but with the UUID of the old VC[1]
-
Adjust the 'Modification time" up by 1 (I need to verify that this really triggers DxPL to reload the DOP when automatic DOP loading is set in the ‘Preferences’).
Rediscover the directory and hope for miracles.
Via the ‘Projects’
with the “BaseLine” directory still showing the original layout
By retaining both copies it is possible to review the outcome and easy to delete [1] which was originally the [M]aster entry or not!?
Now all I need to do is write the PureBasic program to automate the function., including securing the database and the DOPs before starting the switch for all images that have two entries in the DOP!
Update, with an update to that:-
However, during that test I managed to hang DxPL but on restart got the swap that I expected and have achieved in the past.
I then tried to repeat the tests and go further but made the mistake of reversing the images because I felt it looked more appropriate to have the muted image as the [M]aster and the brighter image as VC[1] but that just made things even more complicated,
I also created additional image copies, i.e. copy the image with a new name and take one of the VC entries to create its DOP by adding the header and the trailer.
That appeared to work at the time, however I failed to repeat the results I got with the DOP swop and gave up.
Update to the update:-
I tried again with the example I used at the beginning of this post, with the ‘Ratings’ altered slightly so they go from 0 for the [M]aster to 4 for VC[4].
I then created 5 images from the original one image and 5 (hand) manufactured DOPs and got
The edits look to be intact but the ‘Ratings’ etc. are there in the DOPs but not in DxPL after discovery, even after clearing the database and locating only that directory!?
So that will remain as is for now while I get on with the program to do the DOP manipulation automatically (it is way to prone to error doing it manually) to see if I can discover what I have done wrong or which fields are causing the metadata to be ignored, i.e. there isn’t much to cause problems other than the date fields (or my formatting)!?
Sidecar = {
Date = "2024-08-11T07:15:39.8424695Z",
Software = "DxO PhotoLab 7.8",
Source = {
CafId = "C61004c",
Items = {
{
Albums = "",
CreationDate = "2024-08-11T07:14:01.5966400Z",
IPTC = {
contentHeadline = "[M]",
}
,
Keywords = {
}
,
ColorLabel = "Red",
ModificationDate = "2024-08-11T07:15:39.8384705Z",
Name = "P1-0.RW2",
Orientation = 1,
OutputItems = {
}
,
ProcessingStatus = 1,
Rating = 0,
Settings = {
I even changed the image name in the DOP, I have previously believed the field is basically “ignored” by DxPL(Win) but without any success.
