XMP-files gets F*cked up due hierachical mismanagement in dual management

DxO PhotoLab Windows topics
1

Ok, problem when photolab is xmp syncing.
It created “keywords” from SUBkeywords.
so i have “types”> then “museum” it does make a “new” plain Museum.
and it does this on every sub keyword i incidently change/ add in pl.

This messes up my original tagging and i can’t see my orignal tagging any more.
:rage:
lot of repairing to do. and i have to run AGAIN through all my images and repair the f*cked up xmp files
i just turned off “always synchronised”. which means i don’t use the iptc editing function anymore in DxOPL.
If it can’t keep my original structure in my xmp keywording hierarchie i will be forced to have a read only from know on. until it’s 100% safe and guaranteed a following structure system!
P1010262.xmp (8,3 KB)
For investigation.

For will be used again by me it must be changed.
1: always ASK before change a keyword. (structure)
2: never duplicate a (sub) keyword in order to create a new line (main keyword)
3 I need a Slave Master setting. Which means DXOPL is Slave. (asking before acting)
i can’t relay on the structure holding capabilities so then it’s useless as secondary xmp writer.
Sorry but i am pissed.
it even misform and corrupt my xmp when i only add location and gps data. which is un expected.
it delete structure even when i only add gps and location fields (No change in keywords or other tags.
Thus even blanc fields updating/writing does corrupt earlier work. That’s really bad.

2

You’re not the only one complaining about PL5 metadata handing, e.g.,:
https://forum.dxo.com/t/pl5-completely-messes-up-my-hierarchical-keywords-when-exporting

As you’ve found, in any event it’s not a good idea to use multiple programs to manage metadata.

Even with xmp syncing turned off, PL5 creates individual ‘keywords’ from sub-keywords in output image files. It shouldn’t. It’s creating additional metadata management problems for me every time I process files. At a minimum, PL5 needs an option to pass through keywords w/o change.

One thing about the current behavior is that it’s totally unnecessary. PL5 should already write keyword parts into the xmp-dc Subject tag, while also writing xmp-lr Hierarchical Keywords. Doing this should preserve hierarchical keywords while also allowing simple searches for any part/parts of the hierarchical keywords.

3

It should be no problem if the structure in xmp is one on one the same.
And that’s a problem apparently for company’s. i would say if you can read a certain xmp you must copy the writing manner. and do so accordantly when updating a xmp.

If DxOPL has a good UI in editing metadata and a full organising structure for keywords, iptc-templates, colortagging and ratings i don’t need “bridge” other then managing my other files as video.
but if “DAM” applications are corrupting each other as fighting allycats then it start to be redundant features.

in dual mangement i understand that if i start culling in FRV then an xmp is created. (only rating and colortagging (future) step 2 now in bridge because of the better overview and structure act I do keywording and location naming. (GPS is trickier because copy paste google coordinates doesn’t work well. (hours and minutes vs longitude latitudes.
Step 3 would be in dxopl, during editing adjust rating and maybe add or correct additional information.
This would work fine if dxopl adopts and maintains the hierachy and structure that bridge and FRV set up.
Then you wouldn’t have to go back to bridge for addtional iptc editing.

No it should just read and stop thinking when you add non.
(at this moment i need to drop google gps in dxopl and copy the translated degrees in bridge and continu in bridge in order to keep my xmp’s save.)
So that would be the only adding in the database. (and it is then doubled by bridge probable in an other line in the xmp… :weary:

anyway, my backup is useless because i just was in the middle of rearanging and adding iptc data. it’s easier just to start over and run the hole system again wile adding and cleaning.

My frustration is because of that there have been plenty of warnings during the EA testing time by people who really knew what they were talking about, iptc managment and metadata managment. tranfer and crosover those kinds of problems. I kept out of the details because user is something different as programmer but unfortunately it’s not really stable after delivery.

4

All this is a reason I use a ‘real’ DAM (IMatch, but only available in Windows) that observes metadata standards. And I avoid trying to manage metadata in multiple programs. Unfortunately, metadata is a real mess (more colorful adjectives could also apply). Things would be much easier for everyone if manufacturers and major players in the photo industry would cooperate and create useful standards, but this seems extremely unlikely…

1 Like
5

i hoped that that not be necessary for a simple home user and that “simple” systems would be play nice by using some form of standard.
But i start to wander off from that thought…

6

No wonder many didn’t want a DAM bring developed, I am pleased to have kept well away from it and will carry on doing do. If only it were a separate add-on and on not risking the main program or diverting so much effect away from the area’s most of being sorted or improved. When you see the amount of work the stand alone DAMs producers do in updates and sorting problems you see how DXO can never rival them, but it’s the complexity of the other DAMs customers are asking for when DXO can’t get the basic version they have produced not to crate so many problems for many people. They have people wanting everything in light room working in PL, at timer I get the feeling at time everything in all photo processing programs all rolled in into PL. Now add all the ability of the DAM and where will it stop, just to have a non-messed up RAW processing program is becoming too much to hope for !

7

yep, i know i only hoped it got a bit more integrated.
now i just keep “Bridge” open wile working in DxOPL and when i need a adjustment of IPTC i do it in Bridge only. i am cured. no “writing” for dxopl any more, unles its proven safe.

8

I too use IMAtch as my DAM software and also the reason I supported that PL focus more on developing tools such as photo stacking or improving their local adjustments sliders. When I realised my keywords were being corrupted in PL5 I raised the issue under
What does the Adobe announcement on LR mean for DXO and PL - #78 by akirstein
back in October where there were a reasonable amount of feedback. The disappointing fact is PL said they would get back to me but I am still waiting for a response. The best way to look after keywords in my opinion is IMatch as the developer knows his stuff and the platform is based on reconised structures. The best way to handle keywords in PL if you use another DAM software is turn off all syncing which unfortunately leads to double work as once you process the RAW file you then need to copy the keywords into the jpeg or tiff file. Really hope they either drop the effort (although I think this is too late and they may be wanting to compete with other developers such as Lightroom) or start getting it right like allowing us to use IMatch as a plugin.

9

This is making the workflow very stiff!
My normal workflow is:
1 FRV primary culling and rating one look keepers (the lucky few) and maybe of burst the few which are worth to look at more closely.
2 switch to DAM, Bridge for now, add taggs and keywords and gpsdata and text as subject.
3 start editing, in dxopl, and wile i am in that i could change my mind about rating (mostly raiting edit 2 vrating is often my last moment of change.) or something.
and here it goes wrong, then i need to reopen bridge and change it there (find folder find image) before i can go on.
wile a simple click shoud be enough Without any corruption of other things.

i don’t know if imatch is working the same or is it smarter?

Now i know why i actived writing in dxopl, Bridge does problematic in adding gps.
52° 19’ 30" N, 4° 36’ 19" E can’t be entered in one go, and 52.32507397711865, 4.605446382750082 doesn’t it understand.

10

So far, I’ve used a flat keyword list, which does not cause issues like you describe. Testing with hierarchical keywords and IPTC metadata showed, that some discrepancies in handling of .xmp sidecars exist. There is a lot of room for interpretation in how metadata can be written to the sidecars, the respective guidelines are not that strict.

I think that PhotoLab needs a few iterations to get things right. Until then, it is a good idea to switch automatic MD sync off and use PhotoLab’s MD functions for test images only.

11

I also did not want to see DXO try to integrate a DAM, but I’m afraid we are stuck with it unfortunately,

I have been using Photo Supreme for a while and had been planning to switch to Imatch next month when I will have my new PC completed. My present workflow is to cull in PS or FRV and have PS send the CR3s to PL5. At this point I have not done any tagging. I have syncing off in PL5 and do not enter any kind of metadata in PL5. When done in DXO I export as a jpg or tiff to the original folder. At this point I do all my tagging. Since the jpg is returned to the same folder as the CR3 PS makes it part of a Version Set. Any tagging I do to the CR3 (Master) is also added to the jpg so I don’t have the double effort that others here do.

Since I have been planning to switch to Imatch I am wondering if it also does Version Sets? If so is tagging done in the Original carried through to others in the Set?

(Added on Edit) I just did a quick Google and found some of Imatch’s very thorough documentation on versioning. Imatch Versioning
So it seems that if Versioning is used in Imatch that all the metadata would not have to be copied to the jpg’s or tiff’s. It will be done automatically like PS does for me.

12

Here’s my general workflow with IMatch and PL:

  • Ingest new images in a date-based folder structure (YYYY_MMDD folder names) in IMatch
  • Add metadata with IMatch to .xmp sidecar files. This is generally Description, Hierarchical Keywords, Location (Country/State/City/Location) and sometimes GPS coordinates. GPS data usually come from GPX coordinates generated from my Garmin watch. If GPS data doesn’t exist, I may add GPS coordinates using the IMatch Map features. I reverse-geocode images with GPS data to add location descriptions. For images without GPS data, I use stored metadata templates (e.g., United States/Colorado/Denver).
  • Add Ratings with IMatch. I use IMatch ‘Favorites’ to send selected images to PhotoLab date-based External Selections.
  • Edit images with PL. It does a great job, of course. I typically use ‘Reject’ to leave out images I decide not to process after all, but I don’t change the Rating in PL.
  • PL4 and earlier would copy metadata from raw images to output JPG images. It’s more complicated in PL5… IMatch provides workarounds.
  • I use IMatch to add keywords for any images I upload to my SmugMug site.

This takes less time than it might appear, using various workflow shortcuts in IMatch.

1 Like
13

I rarely comment on PhotoLab’s DAM because I don’t use third-party asset management software and this new PhotoLab feature has become very controversial. Most who post on the subject here usually express extremely strong negative opinions.

Everyone has different requirements, including editing the same images in multiple software packages or across multiple computers. However, when it comes to digital asset management functionality, many of us, like myself, have very simple requirements. For a lot of us, this first iteration of DxO’s DAM meets those needs.

I have no want or need for a standalone DAM. I cull frequently and do not have more than 15 or 20,000 images on my computer. I also do not edit the same images on multiple computers or multiple platforms.

I have a very clear folder naming convention which usually allows me to find what I’m looking very quickly visually. I currently only use DxO’s products for image editing, including PhotoLab 5, FilmPack 6, Viewpoint 3, and the Nik Collection 4, and therefore I am not concerned about conflicts caused by multiple pieces of software reading and editing the same metadata. As a result, this first version of PhotoLab 5’s DAM, although still rough around the edges, meets my basic requirements. I am sure future iterations will resolve some, if not all, of the issues people are having with it

At various times I’ve tested all of the better known DAMs only to find that they added an unnecessary level of complexity to my workflow. This is not a criticism of any of those software titles, or of anyone who uses them. They are just not for me. Even as a former Lightroom user I rarely used most of the included DAM features. After almost 40 years of being in IT, I have determined that simple solutions to meet my goals are quicker and in the end more satisfying to me! After all, that was one of the prime reasons I stopped using Lightroom in 2017 after acquiring PhotoLab 1.

Mark

5 Likes
14

I’ve looked at the XMP file you have posted but don’t know if this is how you intended it to be or how PL has written it.

Here’s what I see in that file…

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Architectuur</rdf:li>
               <rdf:li>Museum</rdf:li>
               <rdf:li>Type</rdf:li>
               <rdf:li>Vakanties en dagjes weg</rdf:li>
               <rdf:li>Vakanties en dagjes weg|Vakanties</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

According to the MWG guidance, this doesn’t make sense, as it says you have three keywords that do not belong to any hierarchy; such entries are not valid.

The last two entries describe a hierarchical keyword Vakanties, which is a child of Vakanties en dagjes weg; the first line describing the root of the hierarchy, the second describing the “path” of the child keyword.

In my keywording software, I interpret the MWG guidance by including all levels of only true hierarchical keywords, so my app would write…

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Vakanties en dagjes weg</rdf:li>
               <rdf:li>Vakanties en dagjes weg|Vakanties</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

… although the MWG guidance can also be interpreted that…

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Vakanties en dagjes weg|Vakanties</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

… is just as valid.

My instinct has been to stick to declaring the root keyword as well as the description of the “child” and, so far, no other software misinterprets that.

MWG guidance also states that all keywords mentioned in the lr:hierarchicalSubject tag must be mentioned in the dc:subject tag and so…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Architectuur</rdf:li>
               <rdf:li>Museum</rdf:li>
               <rdf:li>Type</rdf:li>
               <rdf:li>Vakanties</rdf:li>
               <rdf:li>Vakanties en dagjes weg</rdf:li>
            </rdf:Bag>
         </dc:subject>

… is totally correct.

In the last couple of years working on my app I have come to the conclusion that the two related tags dc:subject and lr:hierarchicalSubject serve two different purposes…

  • dc:subject → searching
  • lr-hierarchicalSubject - communication

Unfortunately, DxO’s current stance is that all keywords should be written as hierarchical and their search is based on such an assumption; which is why I am inclined to state that the XMP file you posted was written by PhotoLab :crazy_face:

This assumption is just plain wrong as it can contribute to both limited and incorrect search results in other software. For example, if I have some images marked Colour|Orange, some marked Fruit|Orange and yet others marked Enterprise|Telecommunications|Orange, PL5 does not currently allow me to search for all images marked with Orange, regardless of hierarchical context, because it seems to search based on hierarchy and not just the keywords found in the dc:subject tag. Which is why they are forcing all standalone keywords to be also single level hierarchies. This is wrong and incompatible with every other keywording app I have so far found.

At present, the PL5 search is woefully inadequate, in that it doesn’t allow searching based on OR predicates, only AND predicates, and then only for complete hierarchical phrases.

Searching for hierarchical phrases should not be done on the lr:hierarchicalSubject tag, it should be done by ANDing together the keywords that form the hierarchy in a predicate for searching on the dc:subject tag. For example, I should be able to search for Fruit|Orange OR Colour| Orange, something that is currently impossible.

Unfortunately, this misappropriation of keywords in hierarchies has also been propagated to both the DOP files and database and correcting this will now entail invalidating the very keywords that PL5 has already written. Hopefully, not too many people have started using PL5 for keywording.

1 Like
15

I have just reread your post and saw…

So, I now assume that you have a hierarchy Architectuur|Type|Museum

In which case, the correct hierarchical tags should be…

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Architectuur</rdf:li>
               <rdf:li>Architectuur|Type</rdf:li>
               <rdf:li>Architectuur|Type|Museum</rdf:li>
               <rdf:li>Vakanties en dagjes weg</rdf:li>
               <rdf:li>Vakanties en dagjes weg|Vakanties</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>
16

The problem is how do you get them to change, the history regarding getting DXO to do that isn’t great.

17

One can but live in hope that they don’t want to get a reputation for getting it wrong with metadata, otherwise all the effort put in so far could be wasted as people stick with what they know rather than moving to PL5. Effort that could have been put into making the image editing side of things even better.

1 Like
18

i will create a summary for you.
i pm you later.

1 Like
19

This is the case for most of the "more engaged " iptc users (xmp files by a older dam like bridge) and more professional dam software users would be mift if it “writes” self made iptcmetadata in export files as jpeg/tiff destilated from the xmp files of say imatch (even when "synchronize metadata is off.)

i have a simple and small database so a few day’s/weeks work to repair a corrupted dam system will be getting my mood in a dark place but it’s not work related so it doesn’t cost me money.
any other professional user would be not be pissed off but furious if it’s database is mashed to pieces.
Once bitten you tend to stay away to avoid a second time.
So that can cost you fanbase and users in the long run.

edit:
First modification step must be a "hierarchy of application set up in PL’s syncronizing xmp."
Very important!!!
So you can set which fields it is allowed to alter/modify and which are “read only” a selectivity box like:

setup
setup680×627 29.7 KB

me i would say write at:

my setup
my setup687×598 28.9 KB

and i can change every time i like to change in preference.
(this is at this moment database only when sync is off.)
this way i can control the influence the dam from dxopl has and protect my xmp files wile i can still use some of it in my developers stage so i don’t have to switch all the time between external dam and dxopl.
this gives dxo pl the time to perfectionize the dam wile every one can decide for them selfs how much it diggs in there xmp’s.

Second modification is IF xmp sync is set active the DB MUST be Slave: no visual differences even on the NOT selected preferences i described above.

20

The problem of metadata is that there isn’t 1 standard in how to write and read an xmp file.
The interface between two applications is randomly connected as it seems.
Depends on the interpretation of the reader (viewing corruption) and when you write back, full duplex sync, the risk of corruption of your precious metadata and carefully build iptc data is even bigger, So auto full duplex sync is without carefull writing the interface a hairy thing.
It just not write well in the xmp and the entrylines are meshed up. That’s a no go.
One problem is language, dutch towards english translation.
Lokatie => location, omschrijving => desciption, to connect the right fields it must have correct linking between fields.
And german english, swedisch englisch. Japanese, …
Adobe has far more UI languages and has therefore easier translation dictonairy.

Could be if you never used xmp’s and just start with them inside dxopl.
Then the change it works wel en has no problems is much bigger.
Problem is the UI for keyword ranking and setting is a bit wobbly.
The sync is good because then you can delete DB and re indexing to refresh and cleanout mistakes.

Yes building and maintaining is a dreadfull job. :slightly_smiling_face:
The gain is searchability in specific images, and quick project gathering in those by visualisation on selection.
Other gain is adding location and information on groups of photo’s like holiday and museums so you can see much much later what, where, who.

And this is immidiately the crux, when that data crumbles to a crisp people are not very “pleased”. So responsible software is then to blame even when it’s not directly to blame. Like kicking the dog because you stepped in its turd wile walking and looking on your phone at the same time. :sweat_smile:

1 Like