Meta data updates vs. virtual copies (PL6)

  1. Open DxO PhotoLab 6.x (I tested this with v. 6.2)
  2. Create a virtual copy of any image file
  3. Close PhotoLab
  4. Edit the meta data of the file using an external editor, e.g. ExifTool
  5. Open PhotoLab again
  6. In PL, read meta data from the image file, for the master and for its virtual copy

Result: The master shows the correct (updated) meta data, according to what was read from the image, however the virtual copy does not reflect any of the changes.

I set all my metadata externally in PhotoMechanic Plus and the virtual copy is never updated, I have to copy/ paste it from one to the other. Same in DPL5. If you do the metadata changes before you create the VC then it works, but once created it’s “stranded”

@juerg Why would it!?

You and other users may want the Virtual Copy to effectively be “connected” to the [M]aster but the Virtual Copy is effectively a snapshot at a point in time and from then on has an existence all its own!

In the DOP there is a copy of all the normal fields, including the metadata, for each copy!

The only way you can currently meet the requirement is to copy the metadata from the [M]aster and then paste to one or all of the Virtual Copies, either all the metadata or a selection from

The metadata from the [M]aster can be copied and pasted to all the related VCs at the same time but the risk is that if you neglect to keep the VC metadata inline with the external or [M]aster metadata, i.e. metadata changes made in DxPL to the [M]aster are not propagated to the VCs either, the exports from some or all VCs will not contain the image metadata created or updated (internally or externally) after the VC was created!!

From my perspective I don’t want the feature you are suggesting because I use the IPTC data to hold certain “metadata” about the various edits that I have made! If all were kept inline then I would lose that data every time there was an external metadata change which was imported or automatically detected!!

But if the feature was added to ‘Metadata’ ‘Preferences’ as an option e.g. a ‘Keep Virtual Copies aligned with [M]aster metadata’ option then we could both have what we want!?

1 Like

I think it is quite simple. If I do a “read meta data from the image file” for the virtual copy then I expect exactly that. Whether the virtual copy has an existence of its own does not matter because as a user I can freely decide for which existence I want to read meta data. If I don’t want meta data to be updated for a certain virtual copy I can simply not carry out that activity for that virtual copy. Straightforward.

@juerg Sadly I don’t believe it is going to work that way!

The following shows me setting ‘Rating’ and ‘Label’ for an image (in FastRawViewer) and then ‘Read image data’ to get that data into PL6.2.0 for the [M]aster.

But if I try to ‘Read image data’ with the VC highlighted both Read and Write are greyed out!

But I can copy the metadata from the [M]aster, having read that from the image or having input new values directly in DxPL, and pasted all or selected parts to the VC.

So effectively the only way to get image metadata into a VC is via the [M]aster! This is not a particularly complicated task but it cannot be taken directly from the image into a particular VC, or so its appears !

I also use PhotoMechanic Plus. The trick is to start applying the metadata before starting to create virtual copies in Photolab, So, if you don´t want to copy paste metadata afterwords you have to change your workflow.

I just tested to create a virtual copy from a master i Photolab after having applied the metadata to the master before and that works fine.

I have seen the same before after having noticed that some of my JPEG-files exported from virtual copies lacked the metadata too and that made me change the workflow. It´s much more efficient to start applying the metadata before editing anything at all in Photolab. Version 6 works really well together with PMPlus if the auto sync of the metadata is on in PL.

1 Like

@Stenis In an “ideal” world the workflow you are proposing should and would be followed and no issue would be experienced, unless

  1. You decide to add additional metadata in DxPL to the [M]aster or a “random” VC

  2. 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!!

For the record my setup doesn’t create XMP sidecars. So there was no sidecar to send. I had checked previously the IPTC data is stored in the dop sidecar and for me that’s enough since I don’t use another tool. I know when I export the IPTC data in the exported image matches what’s in the DOP which is what I want. I BELIEVE but am not sure that the IPTC data in the DOP also makes it’s way to the database for future exports if the image is every recalled I. A different location or with a wiped database. At least it should be other issue why even keep it in the DOP?


P.S. no problem to use my image. :slight_smile:

@MikeR The lead source of data in DxPL is the database, essentially the DOP is a copy of that data, essentially a snapshot of the last edit of the image or metadata etc… Without the DOP, DxPL will use whatever is in the database, if anything.

Without the database (entry) DxPL will use the DOP and it is largely for users like you that DxO reverted the PL5 release at PL5.3.0 to the behaviour used for PL4 where the (very limited in PL4) metadata was taken from the DOP in the same circumstances!

The reason for the style of implementation was either to preserve or restore the previous behaviour or because it was a very “cheap” piece of work (or both) but as I stated I have grave misgivings about what I feel in an incomplete development and there are some “bear” traps for the unwary!

Thanks for the data I had been using to investigate your problem and then hijacked to demonstrate the point I was trying to make!