@Stenis In an “ideal” world the workflow you are proposing should and would be followed and no issue would be experienced, unless
-
You decide to add additional metadata in DxPL to the [M]aster or a “random” VC
-
Discover when you get to DxPL that you are not happy with the metadata you inserted with Photo Mechanic, or whatever software you use, and decide it needs amending. This is still fine if no VCs have been created and the change could be made in DxPL and written back to the image or vice versa. But if VCs, with their own individual edits, have been made from the [M]aster or from another VC they will have “inherited” the metadata at the time of creation!
The DOP metadata Trap:-
The procedure I outlined above will work, unless you fall into the trap neatly created by DxPL which I have written about many times before and I “fell into” when preparing the above post with the snapshots!
Firstly I must apologise to and/or thank @MikeR because I “stole” his image that was part of his post about Anyone notice big difference in final image brightness between PL6.1 and PL6.2. @MikeR kindly supplied a test image and a DOP for others to try to reproduce the problem!
My machine currently has the ‘Preference’/‘Metadata settings’ set to AS(OFF) (Auto Sync OFF)
This is the opposite setting to the one referenced in your last sentence above where you are using AS(ON)
So in this case, with AS(OFF), I am responsible for retrieving any metadata from an image and writing any changed metadata back to the image!
BUT the option comes loaded with a known “feature/side effect”! When AS(OFF) is chosen, i.e. Auto Sync is not set at all, then when DxPL (post the PL5.3.0 release) discovers an image new to DxPL then the metadata is taken from the DOP and not from the image (embedded or sidecar metadata), in truth for large amounts of the metadata the DOP effectively “blocks” any metadata that may or may not be in the image (Xmp embedded or sidecar).
In this case @MikeR did not supply an Xmp sidecar file because it was not pertinent to the problem under investigation but having copied the image & DOP to a new directory for testing and then created a VC the metadata was added to the DxPL database from the DOP on discovery and then carried over into the VC when I created it for a test for this topic.
I then set ‘Rating’ and ‘Colour label’ in FRV and executed a ‘Read from image’ to show that only the [M]aster is updated!
BUT,BUT,BUT the only metadata in the image was what came with it out of the camera (Exif, GPS etc) plus the ‘Rating’ and ‘Colour label’ in the sidecar file, newly created by FRV.
So all the IPTC data in the [M]aster image was “wiped out” by the ‘Read from Image’!
The good news, in this case. was that I had created a VC and the metadata was still intact in the VC and could be copied from the VC to the [M]aster!
I have hated the implementation of this feature (not necessarily the ability to obtain metadata from the DOP but the way it has been implemented @Musashi ) since its introduction and before, i.e. in Beta testing.
I have written that if metadata is coming from the DOP in this scenario then it must be written back to the image BUT that risks destroying image metadata that might post date the DOP metadata and I forgot to remember my own advice in the “excitement” of conducting the test!!
I have also long complained that the ‘Conflict Resolution’ ‘S’ icon is only used when a “potential” change to the image metadata is detected but if the user makes changes with the image metadata in DxPL then with AS(OFF) there will be no automatic update of the image, but no ‘S’ icon will occur!
Similarly if an image is newly discovered with AS(OFF) the metadata will be taken from the DOP and no checks made to see if the date/timestamps of the DOP and any image metadata (none in this case!) differ so no ‘S’ icon to warn of possible mismatches.
Hopefully users will not fall into the “trap” that I fell into!!