Is it finally possible to have the XMP-files as the metadata master?

DxO PhotoLab
21

But if I may just clarify… The metadata may not be written to an XMP file, but it is certainly written to the DOP sidecar, as well as the PL database, thus ignoring SPOD rules.

But once PL has read from the DNG, it then writes its own interpretation to a DOP sidecar and/or the database and ignores anything that was in the original DNG file, constructing its own version of reality which, from then on, has priority.

Unfortunately, neither PM not PL adhere totally to the common MWG guidelines, so, allowing more than one of them to write metadata is to invite chaos, unless you deliberately and religiously adhere to MWG guidelines the entering metadata.

22

As does every other package as far as I can tell so they are all as “good” or “bad” as each other.

Or persuade one of them to use my keyword formatting strategy, which I presume @joanna that you are building into your own utility as I am building into my Python program!?

None of us are going to abandon our favourite software, particularly given the current price of most of them. I purchased IMatch at Christmas at a bargain price but prefer DxPL for its simplicity, or rather preferred it up to the change in PL5.2.0! But with my own utility I can create whatever format my heart desires and fix whatever “rubbish” DxPL or any other package “spits out”.

Given that all the major packages use an SQLite database, DxPL has gone one step further by preserving its edits in a proprietary file that also preserves the Virtual Copy metadata until PL5.3.0 and now also uses it as a source of data for the [M]aster as well.

I will fix the second spreadsheet later today!

23

Using my app, which strictly follows the MWG guidelines, gives…

[XMP]           Subject                         : a, m, b, x, y, z
[XMP]           Hierarchical Subject            : a, a|m, a|m|b

… where only keywords that participate in a hierarchy are mentioned in lr:hierarchicalSubject and all keywords mentioned in lr:hierarchicalSubject are written, flattened, to xmp:subject

Files marked according to this standard can be read from every app I have tried it with.

24

@Joanna Please see my reply just before yours and is your utility freely available on the Mac and I know it isn’t available on Windows and although it may be the most conformant if I don’t like what it does I have no alternative to modify the layout, i.e. you are better than the others by having better compliance and as bad as all of them for not providing any (or many) alternatives!

We need the ability to interwork, not simply replace, which is what my design does!

25

Argh my head hurts. :crazy_face: :face_with_spiral_eyes:

For most people who arn’t using PM but a cheap one like adobe bridge.
1 i can’t leave bridge yet because there interface is having advantages like templates and file extention filters.
2 it seems that bridge and dxo writing different in a xmp. Which isn’t a big deal IF the READ it the same!
3 But that seems to be not the case.
4 Plv5 did auto update metadata on selecting the folder or by command refresh metadata. So uncheck sync does only prevent writing without your permission in the xmp…
5 plv6 should be working the same right?

The only thing i do inside PL is add somethings in the iptc like gps data from google, edit comments. If i need to change keywords i return to bridge.
So i assume i am safe syncing xmp as long as restrain myself to change keywords inside PL.

Correct?

26

Any metadata change will cause PL5 and PL6 to have a “desire” to write the metadata back but that “desire” is controlled by the option. If it is not selected DxPL won’t write back to the image but will write the updates to the database and the DOP and to any export.

PS:-

If you mix a non-‘hr’ aware program with an ‘hr’ aware program all manner of problems can follow if the ‘hr’ aware program gets to write to the image. Data will be written to the ‘hr’ fields. If you then delete in Bridge the data will be removed from the ‘dc’ fields but left in the ‘hr’ fields and the ‘hr’ aware programs will start re-writing it into the ‘dc’ fields, potentially!!??

27

Yes so i can’t transport this update in a folder. Xmp isn’t update by migration.
I can selectvand manual provoke a writing action to the xmp.
This is what i was doing lately.
Downside is you have a great change to forget this action after editing a folder which doens’t show up in dxopl because it’s running on the database for that.

28

@OXiDant Agreed which is why I have been moaning to DxO to “finish” the ‘Conflict Resolution’ @Musashi it should in my opinion (not humble) be finished as follows

  1. Signal change to image with ‘S’ - completed
  2. Signal change to DxPL with ‘S’ - missing
  3. On new discovery with AS(OFF) when metadata will be taken from DOP signal with ‘S’ - absolutely missing! Use of date timestamp use optional
  4. Use the heads of the ‘S’ to indicate in which direction the mismatch occurs (could be both!) - optional but would round out the product nicely!

Chance of getting this relatively straightforward task …

29

This exactly is my fear.
Does it write only the changes which is safe or does it behaves as a “Master” and overwrite all old data even when it’s partly the same.
And does it see timestamps of change and act acoordingly?

30

[quote=“OXiDant, post:29, topic:28657”]
Does it write only the changes which is safe or does it behaves as a “Master” and overwrite all old data even when it’s partly the same.
And does it see timestamps of change and act accordingly?
[/quote

@OXiDant All as far as I can tell! The database in DXPLDb has no knowledge of what cam from the original image nor what has been added in DxPL, a keyword is simple or part of an hierarchy and will be output (back to the image metadata or in an export) as the database and the DxPL rules dictate.

If you can seen the second spreadsheet you will see what DxPL does to Bridge keywords.

DxPL “hangs” on an operating system construct that alerts it when change occur. DxPL then checks the “Date Modified” against some internal “clock” and accepts or ignores the event as it sees fit!

31

It will be available, not freely but for a reasonable price, as soon as I have gotten rid of some bugs (unlike some software writers, I am not going to release buggy software)

As you can tell now, with alternatives comes confusion. The reason why we have the metadata nightmare is simply because everybody seems to want to do their own thing, thus forcing all other software writers to write reams of conditional code “just in case” someone does something stupid.

There are only five characters that have to escaped when writing keywords to XMP file…

original escaped
" "
’ '
< &lt;
> &gt;
& &amp;

Apart from these, all other characters are considered valid as part of a keyword, including spaces and other punctuation.

So, a|m|b is a valid, single, keyword that just happens to contain the ‘|’ character.

It is only when certain software decides it wants to interpret such a keyword as having hierarchical structure that is can be used as such. But not all software does that and so, in order to be compatible with as many apps as possible. I only read and write without “interpretation”.

If I were to type a|m|b into my app’s entry field, it would automatically be written as above and you would only see the three separate letters in the entry field, with the hierarchy being written to the file’s metadata behind the scenes.

Addenda

The <, >, and & characters can be written directly to an image file, as long as they are surrounded by either single or double quotes. Whichever quote character is not used to enclose the others can also be used - single within double or double within single.

This allows for keywords like Black & White or L'art de l'eau

32

@OXiDant I am sorry I lied, not deliberately! The way that I have Bridge currently setup it puts simple keywords into the ‘hr’ fields just like DXPL and most of the other products and when I delete the keywords in Bridge they go from both the ‘dc’ and ‘hr’ fields.

I was remembering my original configuration where that did not happen so Bridge and PL can co-exist and that particular problem, of orphaned ‘hr’ entries, should not occur - sorry about my erroneous comments!!

Here are three test entries I created with Bridge, ready for tests that were not necessary

image
image1870×298 27.7 KB

PS:- But it does happen with ACDSee, unless the very latest version has suddenly “discovered” hierarchical keys and the ‘hr’ fields (my licence is for the 2022 version). ExifPro and Zoner, unless that has just acquired … (my Zoner licence just expired and I didn’t renew it).

33

@BHAYT Simple flat keywords is fine for me and the replication works fine for me what I can see so I´m fine really. As they are writing XMP is now the master and that was not the case in version 5 and it´s not the master in Lightroom either because that is the database, so that IS a big improvement.

There are så many vocabulary standards out there and Lightrooms is not the only one but since DXO´s integration with Lightroom has been their main concern and target for so long it´s really strange that they havn´t succeeded long ago with the structured keywords.

I saw the differences between PM and PL very early so the choice at that time was a very simple one. That´s was originally one reason why I never took the structured keywords in production.

34

Is this version of the spreadsheet any more readable?

Copy of meta data setting _09-03_xlsx_1
Copy of meta data setting _09-03_xlsx_11920×2716 391 KB

I think that it is but only if clicked on enough times!

I need to check but believe that PL6 rows will be identical to PL5.2.0 rows and the table shows what PL5 does with the metadata that it is presented with from the various packages which will then be reflected in a write back to the image metadata (if any) and for any exports from DxPL.

1 Like
35

The major difference: The most important difference in version 6 compared to 5.X is that XMP in the files are now officially declared as the “master metadata source” (regardless if the XMP is written to headers inside XMP- compatible filformats like JPEG, DNG and TIFF or to XMP-sidecars for master RAW-images).

References: (if we check to check box in the sync section of “Preferences”)

"Enabling this option will keep metadata synchronized between database and image files (and their XMP sidecars)

it continues:

“For a master image metadata from .DOP sidecars will be ignored. Metadata from .XMP sidecars will be used instead.”

As you might recall from metadata discussions we had earlier around version 5.X many of us agreed on just that the fact that the XMP in the files had to be the XMP-master, including Alec Kinnear not the least.

Note:
“Even correction settings are now optional via a couple of other check boxes”

**To me it now seems that DXO is beginning to “play down” the importance of the . DOP-files, not just for the XMP-metadata but also for other settings and the source is now the image-files and in Photolab the database has now replaced the .DOP-files as the applications one and only storage for both XMP and other settings and editing metadata. That is a very big difference compared to version 5 where no one really knew how all this was handled. .DOP will be kept mostly of backward compatibility reasons. **

This is the reason we now have to switch focus to version 6 and take the rest from there. Because first we have to accept and agree on that a significant change really has happened with how Photolab 6 interact with other XMP-metadata editors.

The case with the structured keywords is a question of it´s own but that has really nothing to do with the synchronisation mechanism in the product. It´s easier not to eat the elephant in smaller slices.

The reason to why I started this tread can be found in the headline: Is it finally possible to have the XMP-files as the metadata master? … and I think I have got the answer, haven´t we?

I also think we finally might have got a synch-solution that admits us to use it as an automatic one way solution for replicating metadata from an external XMP-editor like Photo Mechanic.

Some more testing has to be done but I think it looks really promising.

36

As I have written already this concerns the .DOP-files and that is explicitly written in the “Preferences” in version 6 for Windows. Now it seem to be optional to use the .DOP for “settings” and I guess that´s because Photolab now has a database like for example Lightroom always has. The .DOP-files are redundant now and might be preserved mostly of compatibility reasons.

37

As far as I was a are, DOP files were always optional.

Losing DOP files would make it very difficult to collaborate on editing an image with someone else on another computer.

Well, they are certainly not redundant here - they are my main way of collaborating on shared drives.

Just separate out metadata.

38

That is not the case when using synchronizing anymore. Not even “settings” are mandatory anymore since there are check boxes that gives you the possibility to ignore the .DOP even for that. Read the texts in “References”.

I think even you are stuck in the version 5 world that doesn´t seem to be what it was in the new version 6.

Photolab needs nothing else than the database now.

synk metadata dop
synk metadata dop1504×256 69 KB

39

That’s always been the case for settings, even in previous versions

40

I have checked a few other things vid the sync between Photo Mechanic and Photolab.

In PM there is a mode where you just see one image representation of a RAW+matching JPEG. Two images are represented by one. In the Preferences you can specify whether it´s the metadata from the RAW or the JPEG that will be seen and edited.

I tried to update it and had RAW selected. When I updated it the sync system in PL immediately updated both the RAW and the JPEG. When I deleted a text i the Header element/field the data was deleted also in both files in Photolab. A “bravo” for that because I have seen other DAM-systems having problems with that. I start to be pretty confident that the sync in PL 6 will really work for me.