Avoiding "Unwanted Virtual Copies" when copying Images and DOPs between systems

[BHAYT (Bryan [WIN10, PL8, VP4, FP7, G9 & EM1 Mkii, RTX 5060Ti])]

@John7 I don’t know why your workflow succeeds and does not get any Virtual Copies because if I understand it correctly it should @sgospodarenko and for the following reason.

1. Every image in a DxPL database is assigned a unique number (Uuid) when implicitly “imported” into the DxPL database by simply discovering the new images in the the new directory, i.e. the user navigates to the new directory. This is also the case for any new images added to an already “imported” directory. Any changed images re-discovered in an already “imported” directory (e.g. containing adjusted metadata etc.) will continue to use the existing entry in the database unless accompanied by a new DOP (see 4 below).

2. The Uuid from the image allocated by DxPL is then copied to the DOP sidecar when one is created (after almost any edit) or when the user selects to ‘File’/‘Sidecar’/‘Export’.

3. All edits carried out in DxPL are updated to the database and copied to the DOP, including metadata changes but from PL5 the much increased metadata list will not be copied back to the [M]aster image from the DOP.

4. If the image file, any xmp sidecar file (for RAW images only) and the DOP are carried to another machine and introduced to a another copy of DxPL it will be “imported” with no problems whatsoever providing that the DxPL database does not contain a copy of that image with exactly the same directory layout already. If the second system has already got a database entry for the image (not just the name of the image but the exact directory structure as well) then DxPL will compare the Uuid of the database entry with the Uuid of the DOP and if they do not match then the existing database entry will become the [M]aster and the DOP entry will become Virtual Copy [1] to protect the image and the DOP data!

5. There is nothing “sinister” about this action it is simply one way of automatically handling a potential duplicate clash (the only problem is that I don’t fully understand why you don’t experience the same problem!)

In responding to another topic Add an option to PhotoLab to turn the database functions on or off - #4 by BHAYT I proposed this as a “solution” that DxO could provide but in the meantime I suggest for those that experience the problem then use the transfer strategy that I have documented above!

@BHAYT

However, for users who have experienced problems moving data between systems and who don’t want the database “trashed” every time they want to move data back to a system after processing on another machine a less destructive approach would be, well less OTT!

Surely what is required is a switch (preference) that indicates whether the database or DOP is to be considered the “lead” data, i.e.

1. An option ‘Lead data’ = Database or = DOP or = ‘Ask’ (with the current “option” being ‘Database’, i.e. there is no option)

There are then a number of options that could be provided (particularly with 'Ask) or not

e.g when a DOP clash is detected present timestamp data and let the user choose (with a single or all option) which to accept as the [M]aster. This could be implemented with or without the above option but would fit well with ‘Ask’!

So when a DOP clash is detected retain the entry in the database or make the DOP the [M]aster as indicated by the preference or by the above (‘Ask’) dialogue and then either

1. Discard the other entry

OR

2. Make the other entry a VC

or any permutation that is deemed appropriate for a larger audience of users who might want to move data between systems but not discard all the other data in the database, which is effectively throwing everything away for the sake of importing some potentially duplicate data!?