Is it finally possible to have the XMP-files as the metadata master when integrating with for example Photo Mechanic, if I click the box in the metadata section of “References”??
Has anyone tested this yet?
That’s already an option in PhotoLab 5 and it does write .xmp files, but I haven’t tried it to sync IPTC metadata or ratings with other software (such as Photo Mecanic).
As has been pointed out many times - simply don’t attempt to sync metadata with more than one app.
If you are using Photo Mechanic, don’t even attempt to change metadata in PL - or vice versa.
This is not just a problem with PL, metadata handling seems to vary from app to app, even though there are meant to be standards like the MWG (Metadata Working Group) guidelines.
Do not check the sync button in preferences otherwise PL will possibly stomp over things you don’t want changing. If you really want to write out metadata changes from PL, there is a manual menu item on the File menu, but you have been warned 
6 Likes
No it’s not because it’s not a sync but a semimanual process in all cases but Lightroom.
What i mean is that changes made consistently one way from Photo Mechanic should be read automatically by Photolab 6 and that it should not be any updates propagated from Photolab to XMP if that box has been ticked in order to avoid a metadata inconsistency mess.
With PL 5 there were problems with structured keywords comming from PL with Photo Mechanic. Another thing was that Photo Mechanic is/was forking data in a way PL 5 didn’t. I wonder if anything in PL has changed because what i read in Preferences XMP is now even the PL metadatamaster and at least that seems to be a change.
I think most people integrating Photo Mechanic Plus and PL are very aware of how to do it. It works very well as long as you stick to PMPlus as the metadata owner and use nonstructured keywords. What I was interested in is if PL now is reading the updated XMP and update it if it has been updated in PMPlus. There should in that case be no problem if you stay away from updating metadata in PL.
Ideally there should be implemented a check box more to set if external software should own the metadata. In that case they could block the data from being updated by PL by inactivate all the XMP-fields in PL.
Read above what the text says. I wonder what Photolab does when I open a folder with images that has got their metadata updated in Photo Mechanic and the sync is activated. From what I know the XMP metadata has always been propagated to exported JPEG-files (even in Photolab 4 and 5). If Photolab initially reads and updates the database too with XMP metadata it might not do any harm if the same metadata would be checked or even synced back because it ought to be the same data as long as there is no manual updating going on i Photolab.
The reasons to test this is that some people will definitely forget to manual update Photolab with the XMP metadata changes that has been applied in Photo Mechanic causing inconsistencies. It´also equally important to update the database/catalog in Photo Mechanic with the changes made to the images in Photolab (for example exported JPEG-files with the metadata they have got from the RAW-files. I think I will have to test the sync in version 6 with some testdata in a PM Plus testdatabase.
I have never seen Photolab making something strange with reexported metadata in either RAW+ XMP, DNG- or JPEG-files and even in TIFF-files as long as nothing has been updated in Photolab - and I´m not doing that.
1 Like
@Stenis I am sorry to read this topic because it appears that much of what I have written about keywords and what PL5 has and has not done to users metadata appears to have fallen down a crack in the space time continuum! So I might add some more details later and try to set the record straight for one last time!
In the meantime I used some photos you kindly supplied to run some tests on PL5.5.0. So my configuration does not have the ‘Metadata Synchronization’ ‘Preference’ option set.
-
Set up the test environment and remove protection options on the photos and the xmp sidecars (obviously I forgot this bit initially!)
-
Open PL5.5.0 and navigate to the images in question (images + xmp sidecar + DOP sidecars present).
-
Open images in Photo Mechanic and change two IPTC fields by adding “(Test)” and add my “favourite” keyword options of animal, mammal, bear, animal|mammal|bear but in shorthand, i.e. a, m, b, a|m|b!
-
PL5.5.0 immediately signals a change with the “Conflict Resolution” ‘S’ icon.
- Clicking on the ‘S’ icon offers the option to ‘Read from Image’. Note at this point metadata is flowing only from PM!
- Clicking on ‘Read from image’ gives the following
This is the workflow to follow if you want to protect your image metadata
- But I chose to “emulate” the option you wanted to select so I changed the ‘Rating’ (and the ‘Tag’) and then ‘Write to image’ to transfer the new ‘Rating’ to the image metadata!
- The result is the post PL5.2.0’s (PL5.2.0 and onwards) more “economical” metadata being transferred to PM
For more details of the differences between the various packages in “COLOSSAL” detail please look at Win 10 PL5.3.1 - Use Keyword Format Templates instead of just reverting to the pre-PL5.2.0 keyword format but be prepared for a long read, however the start of that post goes as follows
So from the test above PL5.5.0 with the option left “OFF” is ideal for handling a single source of metadata BUT the metadata still needs to be exported and the exported data will obey the PL5 formatting rules!
Prior to PL5.2.0 PL5 was compatible with Lightroom and IMatch (with one option set) and has remained unchanged since at least PL3, i.e. why did everyone start complaining during the PL5 release when the exported metadata has conformed to the same pattern for so long!?
It is now only compatible with IMatch with another option configuration!!
Please also remember the change made in PL5.3.0 where initial discovery of a new image will use the DOP as the SOLE source of the metadata, the SOLE, the ONLY source of the metadata any embedded metadata will be ignored, any sidecar data will be ignored!
Except I might be overstating the case when it comes to EXIF metadata (is GPS data xmp, or EXIF!?) and possibly some IPTC data @sgospodarenko, @Musashi, @alex now is the time for DxO to actually start giving us definitive answers to questions like this! Testing every possible combination is next to impossible but a code inspection could clear up the issue in hours.
Now I need to return to repairs to the lean-to and occassional Python coding, testing PhotoLabs has consumed way too much of my time (and to little purpose, it sometimes seems)!
UPDATE - 01:-
If all the elements in an hierarchy are selected than the pre PL5.2.0 and PL5.2.0 keyword formats are the same and conform to Capture One output
and look like this in PM
UPDATE 2:-
Please note that the above behaviour only works when the Preferences option is unselected. To restore the PL5 behaviour to that from before PL5.3.0 then
- Discover the new images/directory etc. by navigating in PL5
- Select all images just “imported” (“discovered”)
- Update the metadata from the image (embedded and sidecar metadata) using ‘Files’/‘Metadata’/‘Read from Image’. This will overwrite the data in the database, which has been read from the newly discovered DOP, with the metadata from the image.
- The DOP reflects the database contents and will be updated with the new metadata values on the next DOP update cycle (every 20 seconds).
1 Like
@BHAYT
Thanks for your efforts! You are a real tech mind that always goes to the bottom with it!
… but dear Bryan, I gave up on structured keywords in PL 5 and now I will focus on the behavior of PL 6. I suggest you do that too, because PL 5 will vanish on many users computers now. I have uninstalled it already.
I have had a working workflow with PL 5 and PM Plus 6 for a long time where PM strictly has owned the metadata. No updates at all in PL and only using a flat keyword structure. PL 5 has not been ready for anything else in my case. I have realized that I have to adapt to the limitations in PL 5 and live with them if I shall get something done.
The reason I started this tread is the text I read in “Preferences” in version 6 att the sync check box. What I wanted to try but stlll haven´t is to turn on the sync-function in PL in order to test if PL will read updated file XMP-data automatically. If it does it would be a step forward if it´s possible to use it one way only at least with a flat keyword structure at least. I don´t mind that because the keywords are really of no importance in my images outside my own PM catalog. On the net I have far better revenue of the image description and the other XMP-elements. Since I use to import the metadata manually even to PL, I sometime use it to verify that the metadata really is present and sometimes a perform searches in PL too but that is about it.
@Stenis I believe that at the moment PL6 does not differ substantially from PL5. There are some promised changes, a reversion to the pre PL5.2.0 handling of hierarchical keywords and the ability to have all levels assigned by default but not a lot else I believe.
I have PL6 installed as of yesterday but don’t hold you breath for some major changes, in truth the work flow that I have shown from 1 to 6 is what you need and if you think that doesn’t give you what you want then please state where it falls down while you wait for me to repeat the tests on PL6!
The Sync checkbox has been there since PL5.3.0 when DxO changed the rules about not using the PL5 DOP on “discovery” (importation) and reverted to the pre PL5 (PL4) era where ‘Rating’ and ‘Rotation’ were stored in and read from the DOP; keywords were only ever stored in the database and “sank” with the “ship” if the database was lost!
The PL5 change was that all the metadata was now stored in the DOP but pre PL5.3.0 was never read from back from the DOP for the [M]aster but was read back from the DOP for all VCs! The item you are looking at is not new on PL6 here it is from PL5.5.0
I did not say it was something new I just read what they were writing in the text and it might be the case that it workes a little differently in version 6 than in 5. That´s all I am saying. We can´t assume - we have to know!
(From the text in “References” - Synchronization
"Please note: For a master image, metadata from -dop sidecar files will be ignored; metadata from .xmp sidecars will bw used instead.
Also look at this video: (about 5 minutes into the video he talkes about metadata and the data exchange between Photo Mechanic and PL). It´s this I think I have to check up and I want to know. It seems from the video that for example color markings gets updated between these two softwares automatically.
Noisy High ISO Photos? Do this! (NEW DxO PhotoLab 6 featuring DeepPRIME XD) - YouTube
After that I have tested to activate synch in Photolab and it works. Both updating corresponding XMP elements in PM Plus and rating and markup color - it seems to work!!!
I tried even with XMP-compatible file types like JPEG and it worked.
First I updated an image in Photo Mechanic Plus 6
and then the updated fields in PM where immediately updated automatically in Photolab 6
Please note that both rating and color marking was updated as well as all the other elements updated.
Please observe also that the changes does not work the other way since the updating of PM Plus catalog is manual.
@Stenis With AS(ON), the original name for the ‘Metadata Synchronization’ and the way that the feature is described with the warning prompt when you select the box, so I use AS(ON) and AS(OFF) to describe the settings, the metadata is read from the image (embedded or sidecar).
and this was originally true for AS(ON) and AS(OFF) in the first discovery case.
But as of PL5.3.0 that was changed for first discovery so that from PL5.3.0 onwards
First Discovery:-
-
With AS(ON) the metadata is taken from the image when an image is first discovered and entered onto the PLDb.
-
With AS(OFF) the metadata is taken from the DOP and the existence of a PL5 DOP effectively blocks most if not all metadata (to be confirmed by DxO @sgospodarenko) coming from the image. Blank or non-existent fields in the DOP will effectively result in blank fields in the image, regardless of what is actually held in the image. (Note that this is not or should not be true for earlier DOPs, i.e. PL2, PL3 and PL4 where the DOP would only ever contain ‘Rank’ (‘Rating’ and ‘Rotation’) so for those DOPs PL5 and PL6 should take the remaining data from the image).
Metadata Changes:-
- With AS(ON) any changes made to the metadata in another applocation are generally detected by PL5 and PL5 propagates any metadata changes made in PL5 to the image. As you have discovered!
BUT with the AS(ON) feature comes a sting in the tail, PL5 also writes back the metadata to the image but with keywords in its own format and this may well be an unwanted side-effect.
- With AS(OFF) PL5 detects changes made externally to the metadata and sets the ‘S’ icon and the user can then ‘Read from image’ to fetch the metadata updates made externally, if desired. Any changes made in PL5 will remain there until a ‘Write to image’ is executed and PL5/6 will not signal the differences with an ‘S’ icon.
If you don’t mind DxPL reformatting your keywords then set AS(ON) and the keywords will be changed in the image to the same as they will be set in any export and you will have all the benefits of the automatic exchange process (and it is good but …).
The very long post that I referenced was an attempt to de-mystify the whole issue of formatting with hierarchical keywords and propose a strategy whereby DxO could emulate the formatting of any other package, both for writing back to the image and for export, but no-one is interested @Musashi.
1 Like
Bryan you are absolutely right and I discovered the problems with structured keywords too in version 5. I have no idea if they have corrected that now but for ny sake it works since I long ago decided to keep it simple and use a flat structure instead. It has worked perfectly fine for me since I started to integrate PM and PL.
… and from what I can see there are no way to import and export vocabularies either like in Photo Mechanic. So from what I can see the only migration way is that Photolab reads the keywords and build it´s own keyword list from what it finds in the images. That works really well with my flat structure but is probably not so straight forward if you have a hierarchy.
@Stenis I am sorry but simple keywords don’t help!
This is the image after adding a, m and b to the existing keyword in PM
and this is what happens after PL6 has read and written the metadata back to the image
PL6 (and PL5) write the simple keys to the hierarchical fields as well. Does this really matter …???
May I please ask how you achieve this in PM Plus? Is it a setting somewhere or is it normal behaviour. I’ve been using PL and PM Plus and haven’t found a way where I’m truly confident that I can ensure that PM Plus has total ownership of all metadata changes - I have trouble understanding the wording of the process in both DxO and CameraBits manuals
The simple answer is, as has been mentioned before, disable any metadata synchronisation in PL, ignore PL’s “out of sync” warnings, and rely solely on PM, or other DAM, to do all your metadata work.
This way, you can even use hierarchical keywords as you wil be both creating and modifying them in the same place. Otherwise, PL will attempt to rewrite your keywords in a different manner, which could then confuse your DAM.
This includes not using PL ratings or colour labels, since even just writing those to your files can cause all metadata to be revised.
1 Like
Thank you - I know it’s been discussed at length in various places on the forum though I still find it hard to get my head round it.
Let me explain, my settings in PL are as follows:
-
I import photos from my SD Card and make all my metadata changes in PM Plus to the original OOC Leica DNG (RAW) file. I have no interest in how either package handles changes to TIFF/ JPEG images. No extra XMP files are created, so all metadata must be embedded within the original RAW container.
-
I edit the image in PL and a DOP file is created which contains those edits and some metadata. I have no interest in what metadata PL stores in either the DOP or the DB as long as PL makes no changes to what I’ve done already in PM, I make no metadata changes in PL and I get PL to display what it can (I’m not precious about how it interprets what it gets) by using “Read from Image”. I do not use “Write to Image”
From my research, I understand this should achieve what I want - metadata created and updated in PM (my single source of truth etc. etc.), embedded in the RAW file and unaltered by PL in any way whatsoever (in theory, if I hash the RAW file after it comes out of PM and once again after it comes out of PL it should be the same value - admittedly I’ve not tested this yet)
What confuses me is this part in the settings:
I have it ticked this way as it seems not to affect the metadata but the wording causes me a problem. Does this only relate to the edits and the reading and writing of DOP files (i.e. separate files) and the DB, or does it also include the embedded RAW data (commonly referred to as XMP sidecars) - if the latter, how does it differ from “sync”?
I’ve answered by own question, apologies I should have done this before I posted but I’ll leave it here in case in helps someone else.
@danielfrimley Correct you are preventing DxPL from reading and writing the metadata automatically and controlling the input manually and preventing any write-back automatically and manually!
Because your RAW file is actually a DNG (container) the “rules” for DNG metadata is embedded in the DNG not in a sidecar file.
This is the DOP and if you don’t set both you will not preserve and restore your edits, arguably those edits are what you bought DxPL for in the first place!
But the DOP will also contain the PL5 representation of your metadata as well as your image edits this typically does not matter in normal circumstances!
But please note what I wrote to @Stenis about the PL5.3.0 changes to DOP handling with respect to DOP data, i.e. with AS(OFF), your setting, then any new discovery of an image with a PL5 DOP then the metadata will come from that DOP and if there is any discrepancy between the values in that DOP (which will become the values in the database) and the values in the image metadata YOU WILL NOT, REPEAT WILL NOT, BE TOLD BY DxPL regardless of the fact that there might be PM changes that post date the date of the DOP, the later metadata will not be read and no ‘S’ icon will be created during this “discovery” (import).
So follow the discovery process with a ‘Read from image’ immediately after the discovery to ensure that the metadata is up-to-date with the image metadata
2 Likes
Will cause all metadata to be changed and keywords to be reformatted as per the PL5/PL6 “rules” which changed on release PL5.2.0. It must be stated that PL5 using ‘hr’ keywords for simple keywords is not unique to DxPL as the spreadsheet shows
Photo Mechanic is the only one of ‘hr’ aware packages packages I tested, that does not place simple keywords into the ‘hr’ fields but I feel its handling of hierarchical keywords is too limited and shuns any hierarchical keyword elements being placed into the ‘dc’ fields!
This is what PL5 (and I believe what PL6) does to the keywords “lovingly” formatted in a wide array of different interpretations of what hierarchical keywords, in particular, should look like
1 Like