Rotation not kept in dop’s why?

[Joanna (Joanna Carter)]

@BHAYT

The big change is in the reading of that data which for PL5 is now replaced by reading such data from the embedded or sidecar metadata for the [M[aster copy and not from the DOP ! The Virtual Copies continue to rely on the DOP for storage and retrieval of metadata.

I have just done a quick test, prompted by what you wrote.

I took a JPEG, made four virtual copies of it and rotated each one once, twice, three times and four times.

This gave me five rotations in the DOP file, the last being the same as the first - as expected.

All five rotations were also written to the database.

Because I used a JPEG file, the orientation for the master was also written to the original image file.

I then closed PL5, copied the JPEG file and its DOP to a new folder, deleted the PL5 database and reopened PL5 with the new folder. The master and all virtual copies appeared correctly rotated.

Finally, I closed PL5, used ExifTool to change the orientation of the JPEG file and reopened PL5. The rotations for all the virtual copies were correctly read, as was the altered rotation from the JPEG.

So, it would seem that the only WOM rotation in the DOP its for the original file - otherwise the other rotations are both read and written. My guess is that there is a template that says that something has to be written to the rotation in the DOP for every copy, including the master. It’s just that, whether the orientation gets written to the original file or to an XMP, from the first writing, the rotation for the master is only there for simplicity of maintenance and is ignored.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@John7 I am sorry about my “brutal” post to @platypus but he is simply re-hashing stuff that I have done before without referencing that work DxO Photolab 5 Image Rotation Lost in Backups - #3 by platypus.

I apologise for not responding to your original post earlier but I find it difficult to read a post and “fully see it for what it is” when I am already working on something else so I saw it but didn’t fully take in what it was about at the time!

My response to @platypus was that he had seen this before some of this before and repeated tests I had done back in February as if he was discovering this for the first time, without referencing my earlier posts. The rest of @platypus’s post is very much his own work and nothing I have attempted in any of my posts.

Now back to your concern that DxO have engineered a bug! They would argue that they have put metadata where is belongs, namely, into the image metadata (embedded for JPG, TIFF, DNG and sidecar for RAW)!

In fact prior to the February post there had been numerous arguments about why the PL5 DOP contained superfluous metadata at all which “violated” the “rules” of data separation and data “duplication”.

The original reason that the data resided in the DOP was because of the “so called” immutability constraints that DxO were following at the time. I believe that Capture 1 maintains such constraints and that all metadata changes for all image types are held in xmp sidecar files, only being “merged” back with the image when it is exported (or at least that is what appears to happen).

DxO decided to use their own sidecar, the DOP, and you have been using that feature as a useful tool, as indeed had some others. When DxO finally decided to handle metadata more like other programs they continued to store the now expanded metadata in the DOP but for the [M]aster copy that is never used as the source of the metadata, the source is now the image (JPG, TIFF, DNG & RAW) and the xmp sidecar file (RAW) which then completely undermines you carefully crafted strategy.

Others detected the problem because they conserved only the DOP in PL5 as they had previously in PL4 and discovered ‘Rating’ turned to 0 when PL5 read the PL5 DOP or rather didn’t read the DOP but read the metadata which had not actually been written or preserved (e.g. saving the xmp sidecar) . For any metadata changes made in PL5 to be preserved they must be written back to the metadata with AS(ON) in the ‘Preferences’ or ‘Write to image’ with AS(OFF).

@Joanna

I then closed PL5, copied the JPEG file and its DOP to a new folder, deleted the PL5 database and reopened PL5 with the new folder. The master and all virtual copies appeared correctly rotated.

@joanna as it should be, the [M]aster data is coming from the image metadata and the Virtual Copies from the DOP.

@Joanna

Because I used a JPEG file, the orientation for the master was also written to the original image file.

Only with AS(ON) or ‘Write to image’ I believe.

@Joanna

Finally, I closed PL5, used ExifTool to change the orientation of the JPEG file and reopened PL5. The rotations for all the virtual copies were correctly read, as was the altered rotation from the JPEG.

Thank you for adding that bit which confirms my statement and the little chart that @Musashi provided some time ago which is now in a FAQ on the website I believe!

@Joanna

So, it would seem that the only WOM rotation in the DOP its for the original file - otherwise the other rotations are both read and written. My guess is that there is a template that says that something has to be written to the DOP for every copy, including the master. It’s just that, whether the orientation gets written to the original file or to an XMP, from the first writing, the rotation for the master is only there for simplicity of maintenance and is ignored.

We are now on the same page but unfortunately it leaves some users bereft of a “feature” they have been using to their advantage.

Fortunately all the data is present in the DOP if DxO decided to change their minds and start re-using the DOP for the [M]aster but I would suggest that needs to be carefully engineered, preferably as a special option so that @John7 and others can use it to their advantage while others who have become used to the way PL5 currently works can continue to use the PL5 way of working without discovering any unwanted side-effects @sgospodarenko @alex.

I consider the implementation of the metadata changes made in PL5.2.0 to be a “knee-jerk” reaction to a genuine issue in an attempt to assuage the ire of some users, which didn’t fix the cause of that ire and actually had a retrograde impact on keyword management. It effectively de-implemented the current way of working and didn’t provide a facility to allow those who were using the product to choose which course of action they wanted to follow!

I don’t think I have ever seen such wanton, inexcusable “vandalism” in years!

[John7 (John Barrett)]

Where I am confused is if the information is added by PL5 to the jpg why on the 2nd PC PL5 doesnt read it and rotate rather have to do it again on the 2nd PC. If it did readf I would agree better to have the information in a form other programs could (but not all) read. But as I now have a wayu of avoiding the proiblem I am happy (sort off)now, just wish they had not createde a problem for some of us by not reading from the jpg.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@John7 Because of the change then two things need to happen;

1. The metadata needs to be written, either AS(ON) in ‘Preferences’ or AS(OFF) but use ‘Write to image’ if neither is used the metadata will not be written and the image will not have the data. But beware because PL5 can change metadata in unexpected ways, part of my rant about the “ire” of some users. So please tell me what your metadata looks like before it goes into PL5 on the first system.

2. If the data goes into an xmp sidecar file for RAW then that sidecar file + DOP + image will need to be secured and shipped to the other system

@John7

But as I now have a wayu of avoiding the proiblem I am happy (sort off)now, just wish they had not createde a problem for some of us by not reading from the jpg.

This has been the subject of other rants (particularly from me), the lack of communication from DxO about the potential impact on users workflow!

But it should read from the JPG if the data is there but beware if any PL4 DOPs are involved the ‘Ratings’ and ‘Rotation’ (and ‘Tag’) will be taken from the PL4 DOP and ignored from the JPG!

[platypus (Canon & Mac (Intel and M1))]

@BHAYT

I am sorry about my “brutal” post to @platypus

No worries, we’re all doing what we do for what ever our motivation might be. Mine is to progress PhotoLab and I try to comment in a way to make things lean, understandable and without bashing others.

I did the test at different times and in different manners, which brought up results that were unexpected and not always the same, We also have to note that DPL5 has seen a few releases since February and some of the differences might be attributable to changes in the respective releases too.

Anyway, DPL is not my main photo app, I mostly use it as an addition to Lightroom. I was tempted to drop Lightroom when it turned subscription about 6 years ago, but PhotoLab did not have the capabilities to replace Lr then, and even now, I find DPL to lack the capabilities to make it a viable replacement. The main gaps in relation to what I want are a) stability and b) metadata handling.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@john Just to be clear the following should happen.

For the data to be available of the second system it must have found its way into the JPG on the first system.

If the ‘Rotation’ (‘orientation’) data is coming from PL5 then it needs to be written back to the image metadata. If the mechanisms required for that writing back are blocked then it won’t be transferred back into the image so either

1. In ‘Preferences’, ‘Always Synchronize’ = '‘x’ i.e. AS(ON) when all changes between the image and PL5 will be trapped (but I have seen some missed) and written back (I have no evidence that the backward path hasn’t worked on all occasions)

2. with AS(OFF) in ‘Preferences’ then nothing will be automatically detected in either direction except that when PL5 first discovers a new image it automatically does a ‘Files’/‘Metadata’/‘Read from image’ (or equivalent) to pull the metadata from the image into the PL5 database (and thence to the DOP - never to be read again on any system for the [M]aster). The only thing that can block part of this metadata read is a PL4 DOP; if one exists for an image the ‘Rating’, ‘Rotation’ and ‘Tag’ will be taken from the PL4 DOP and the rest of the metadata from the image!

So for the metadata to be available on System 2 it needs to have been put there on System 1, if it hasn’t been written on System 1 it won’t be there to be read on System 2!

As I understand your old workflow you used Photo Supreme to ‘rate’ and ‘Rotate’ you JPG images from your phone but as we have discovered PS ‘Rotation’ (‘orientation’) data is not understood by other software (!!??) hence you second rotation in PL4 which was previously then stored in the PL4 DOP and carried to System 2!

With PL5 the rotation in PL5 must now be “flushed” back to the metadata of the JPG using one of the two methods I described above. This should result in any PL4 DOP being updated to a PL5 DOP, please note that if there are no metadata changes or editing changes made in PL5 then the DOP will not automatically be updated to PL5 I believe, i.e. I have seen PL4 DOPs survive after my testing when I have made no changes to some images!!

So in your case if you set AS(ON) or perform a ‘Write to Image’ then the metadata will be updated on System 1 and can be carried along with the PL5 DOP to system 2. I have not had a single situation where PL5 has failed to update the metadata when discovering an image for the first time (e.g. on System 2.

My occasional “missed” update captures have always occurred when PL5 is running at the same time as the software making the changes and (typically) the directory where the changes are being made is open in PL5 (or PL6 Beta).

BUT PL5 does make changes to the metadata and that has annoyed some users, me included, my complaint is that if I start with simple metadata in the ‘dc’ fields then PL5 automatically starts duplicating them in the ‘hr’ (hierarchal) fields as well! Others have complained about the “excess” creation of ‘dc’ entries for each element of an hierarchical key, arguably the correct thing to do, which PL5 changed on release 5.2.0 (in a way that it shouldn’t, in my opinion) but the main thing is that users want the metadata left exactly as their DAM placed it.

What this means is that to use and retain PL5 metadata changes may (or may not) have unwanted side-effects! Hence, my concern over what your metadata looks like!

There are two pieces of freeware that I use for peeking under the metadata bonnet in Win 10, Exif Pilot and Picmeta PIE but they do require some setting up!

I have a copy of Photo Supreme Lite installed on both my Main and Test machines and all my photos are taken as JPGs and RAWs so with a little effort I could reproduce you exact workflow and assess the implications on your metadata!

I hope that the above is not too boring and is understandable.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@platypus Thank you for your courteous reply my concern is also to try to get DxPL in a stable and usable (by all) state.

The following was intended for a Topic but I will start it here!

Some issues with the metadata launch were “blown out of proportion” “simply” because of the lack of information about the implications of the PL4 to PL5 DOP usage change and the others being mainly about the changes that PL5 can make, of its own accord, to the metadata, although some elements of that must have existed with the exports from PL4 (but at least the original image metadata was left intact)!?

The “DAM sandwich” approach suggested by some users should not be necessary, i.e. use a DAM, use PL5, Export, re-DAM the output to restore the desired metadata configuration.

Instead of the pass through approach DxO changed the product in PL5.2.0 to reduce the amount of ‘dc’ data generated for any ‘hr’ keys @Joanna !? This was arbitrarily executed with no option to retain the original working @Marie and doesn’t fix the problem so when they do listen to forum posts they arbitrarily change the product and de-implement something that users may have been using as a feature, i.e. a lose, lose, lose scenario (the third lose is for any confidence one may have in DxO)!

The PL5 Database cannot support anything more sophisticated with keywords:-

Unfortunately I am being a little harsh on DxO because like most of the other products the ‘Keyword’ structure is basically a simple repository of any keyword encountered in the image or created in PL5 with no distinction of its origin with respect to the fields it came from ‘dc’ or ‘hr’ or whether it was from the image or created in PL5.

So my request for a “simple” pass through is simply not possible (with the current database structure) because PL5 can’t tell one keyword from another and knows nothing about its “heritage”/“lineage”. Keywords are “flattened” and stored in a one dimensional structure with pointers that allow hierarchical keys to be recreated. @Joanna that should make searching keywords as simple as …

So when it comes time to export it is up to PL5 to decide what goes where, so my simple ‘dc’ keywords wind up in ‘hr’ fields @Joanna and all the keywords in a hierarchy wound up in ‘dc’ fields prior to PL5.2.0 which then changed the rules and only now includes the lowest level keyword of the hierarchy.

To provide a “pass through” requires PL5 to retain the origin of each keyword, i.e. image or PL5 + field location ‘dc’ or ‘hr’ or both and be able to use these to prevent “corrupting” the image metadata directly (AS(ON) and/or ‘Write to image’) or indirectly via the export option.

The issue of what happens if a user starts making changes within PL5 still applies, with AS(OFF) then the image should be protected and the data would “only” find its way into the export.

Use an Export option:-

I think it was me that suggested that retaining the metadata data could be accomplished by providing a metadata “take from image” option in the ‘Export’ options. At the time it seemed a little “off the wall” but it could be implemented without touching the database and would avoid the need for the “DAM sandwich” and all the effort that entails for the user @sgospodarenko.

There could then be another Export option to ‘retain metadata structure’ with the revised database design to allow DxPL to retain the essence of the original and add any new metadata in an appropriate manner (needs more thought)!?

EDIT 01:-

The current keyword structure on Win10 looks like this

The Id relates to the number assigned to the keyword, the ‘Value’ and ‘NormalizedValue’ are the actual keyword and the ‘ParentId’ provides the mechanism to reconstruct an hierarchical keyword.

The structure is accessed via the ‘ItemsKeywords’ which is a really “complex” structure linking an ‘Item’ (image) to its ‘keyword(s)’ and looks like this

Where ‘ItemId’ is a number allocated to an image and the KeywordId’ points to the keyword(s) in the ‘Keywords’ structure.

The suggestion I am making is that two fields are added to the ‘Keywords’ structure e.g. ‘KeywordOrigin’ (‘Image’ or ‘PL5’ or …) and ‘FieldLocation’ (‘dc’, ‘hr’, ‘dc’+‘hr’) or one for each type of field location ‘Fielddc’ and ‘Fieldhr’ and whatever else is appropriate.

When populating the fields for output (back to the image or for export) then if the “Global” or “local” option states ‘Preserve original format’ then use ‘KeywordOrigin’ to help locate/filter all ‘Image’ keywords for the image and the ‘FieldLocation’ or ‘Fielddc’ and ‘Fieldhr’ to put the keyword “back” where it came from!

There is a potential issue with hierarchical keywords that can start out in ‘dc’ fields and with hierarchical keywords in general that are typically stored in PL5 in the same way as stored in most products that use a database, i.e. “flattened”!

Plus handling ‘dc’ keywords that can also come from the flattened elements of an hierarchical keyword, i.e. my favourite test of animal, mammal, bear, animal|mammal|bear arguably in my scheme you should wind up with 6 keywords in the database so when you delete ‘hr’ animal|mammal|bear the animal, mammal, bear in the ‘dc’ keywords should remain intactt which they didn’t when I ran a test with PL5 on this set some time ago @Joanna.

Most DAM software asks questions about ‘structured keywords’ and the elements of ‘structured keywords’ which PL5 simply does not do, so what you get is what you get, until they change it mid release @sgospodarenko!?

This needs reviewing but “normal” life (or divorce) calls.

[John7 (John Barrett)]

I am leaving PL5 alone as a DAM. Its to unreliable and as has happened keeps changing and with resulting unwanted effects on some of us. I think presenting PL with jpg images rotated and key words, geotagging etc. done allows DxO messing about to have the minimal possible effect. I still feel and more so now that it was a disaster to develop PL into a DAM its caused endless problems and I don’t think DxO will ever have the resources to make it fully work for most of those who want a DAM. My experience with Photo Supreme is I use only a small part of its ability’s, that its evolving faster than PL is and shows how much work is needed to keep up with the changing requirements of the manty sorts of users that a DAM has.
So for me its easy I just isolate PL as a DAM as much as possible and use it for what its good at (and without the going into the DAM would undoubtedly be better)RAW processing program and I just hope the DAM development doesn’t lead to the same fatale problems as the iPhone camera did!

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@John7 I understand your concerns but feel that some of the issues were actually in DxO’s power to avoid I also believe that some of the things that have been suggested by me and others are actually not that difficult to fix or implement but if you are short on resources then …

One of my biggest issues is an almost “paranoid” avoidance of adding anything to the ‘Preferences’ screen, it seems to be treated as “sacrosanct” and as if the “world will end” or a major catastrophe will be unleashed if any changes are made, while other DAM products provide many ways to customise the user experience almost all of which are missing from DxPL!?

It would be sad if DxO failed as a consequence of what they undertook and I would like to believe that they have learned lessons from the experience, in particular how to use their Beta testers more effectively, but I fear that little has actually changed.

In addition they may feel that they should “cut and run” at worst and “cut corners” at best with metadata handling but it is so close to being a really useful product that I feel that would be a shame!

I have used a lot of other software while testing PL5 metadata handling and it is the simplest product to use by a long, long, long way but one which still has a few wrinkles to be ironed out!

[Sigi]

@John7

I am leaving PL5 alone as a DAM. Its to unreliable and as has happened keeps changing and with resulting unwanted effects on some of us.

Hello John,
I am with you. I am also a user of Photo Supreme and when I read their forum you will read over and over again a statement from Hert - the key developer: “Never use multiple software to manage Metadata, if you do then at your own risk” Whatever you do with metadata:

• use only one piece of software
• and beware that the software you use does not lock you in so you can switch to another DAM application if needed

After years of dealing with DAM software for me it is not so much a problem of a specific software i.e PL causing problems but using multiple software to manage metadata which causes issues

Sigi

[Joanna (Joanna Carter)]

@BHAYT

Instead of the pass through approach DxO changed the product in PL5.2.0 to reduce the amount of ‘dc’ data generated for any ‘hr’ keys @Joanna !?

I’m not sure what you are getting at here.

I have just taken a RAW file, set the keywords to three hierarchical parent/child sets…

The XMP file shows…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Didier</rdf:li>
               <rdf:li>Flan</rdf:li>
               <rdf:li>Gilbert</rdf:li>
               <rdf:li>Nounours</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Nounours</rdf:li>
               <rdf:li>Nounours|Didier</rdf:li>
               <rdf:li>Nounours|Flan</rdf:li>
               <rdf:li>Nounours|Gilbert</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

… which is just as everything should be.

Then I export the file to a JPEG an, using ExifTool to read the metadata, I get…

[XMP]           Subject                         : Didier, Flan, Gilbert, Nounours
[XMP]           Hierarchical Subject            : Nounours, Nounours|Didier, Nounours|Flan, Nounours|Gilbert
[IPTC]          Keywords                        : Didier, Flan, Gilbert, Nounours

Once again, no problem there at all.

---

As long as I leave the full hierarchy checked, like this…

… then there is no problem. But, if I only check the leaf keyword…

… then I start to see inconsistencies when compared with the MWG Guidance notes.

The XMP file then shows…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Orange</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

1. the dc:subject tag is incomplete as it is required to mention all flattened keywords from the lr:hierarchicalSubject tag.
2. in order to support maximum compatibility with other software, the lr:hierarchicalSubject should ideally contain…

         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Entreprise</rdf:li>
               <rdf:li>Entreprise|Télécommunications</rdf:li>
               <rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>
   

Of course, the same incorrectly specified dc:subject tag is also propagated to any export from the file…

[XMP]           Subject                         : Orange
[XMP]           Hierarchical Subject            : Entreprise|Télécommunications|Orange
[IPTC]          Keywords                        : Orange

This essentially makes searching for any keywords in their full context impossible, since most other software bases their search on the dc:subject tag with no reference to the lr:hierarchicalSubject tag at all.

Unfortunately, for reasons best known to themselves, DxO have decided to base their searching in the lr:hierarchicalSubject tag, which might be fine if you are only using PL, but it is totally useless elsewhere.

---

@BHAYT

Plus handling ‘dc’ keywords that can also come from the flattened elements of an hierarchical keyword, i.e. my favourite test of animal, mammal, bear, animal|mammal|bear arguably in my scheme you should wind up with 6 keywords in the database so when you delete ‘hr’ animal|mammal|bear the animal, mammal, bear in the ‘dc’ keywords should remain intactt which they didn’t when I ran a test with PL5 on this set some time ago @Joanna.

I really think we should not be interfering in how DxO manages their database. If they want to do it the hard way, that is up to them.

What is most important is that the XMP files and exported versions of an image carry the correctly specified metadata.

Unfortunately, in my opinion at least, DxO have allowed database design to determine what gets written to metadata; rather than designing the database in such a way that it supports a correct implementation of MWG Guidance.

But what do we know? And, if we were right, are DxO willing to listen? That has not been my experience so far.

@Sigi

Whatever you do with metadata:

• use only one piece of software
• and beware that the software you use does not lock you in so you can switch to another DAM application if needed

And, if I may add

• don’t use PL to manage metadata if you are hoping for compatibility

[mwsilvers (Mark - New Jersey, USA)]

@BHAYT

I have used a lot of other software while testing PL5 metadata handling and it is the simplest product to use by a long, long, long way but one which still has a few wrinkles to be ironed out!

I am no expert on digital asset managers and don’t use any of the well known dedicated tools for that purpose. I am also no longer a user of Lightroom and therefore have no concerns about their handling of metadata versus DxO’s. Therefore, PhotoLab meets my modest metadata requirements admirably. I suspect it will fill that need for other PhotoLab users who do not also manage their files with some other third party software.

Comparing PhotoLab’s handling of metadata and general asset management has become a big issue here. It is being compared to a number of very mature stand alone products which have refined their. functionality over a number of releases. DxO’s metadata features are by comparison extremely new. While for a number of users here they are not ready for prime time, I would suggest we look at how far they actually have come in such a short while, and the potential of where they could be in not too distant future.

I am hopeful that DxO will continue to tweak and eventually satisfy most of its critics.

Mark

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@Joanna

I’m not sure what you are getting at here.

I have just taken a RAW file, set the keywords to three hierarchical parent/child sets…

@Joanna according to my tests the animal|mammal|bear will only get a ‘dc’ key of ‘bear’ now whereas originally all elements would have been allocated a ‘dc’ entry!

I have never seen the highlighting that you show.

@Joanna

Of course, the same incorrectly specified dc:subject tag is also propagated to any export from the file…

[XMP]           Subject                         : Orange
[XMP]           Hierarchical Subject            : Entreprise|Télécommunications|Orange
[IPTC]          Keywords                        : Orange

This essentially makes searching for any keywords in their full context impossible, since most other software bases their search on the dc:subject tag with no reference to the lr:hierarchicalSubject tag at all.

The whole point is that PL5 has no notion of the keyword type in its database just a lot of flattened keys, the “obsession” with ‘hr’ only takes hold when the data is output back to the image or as an export. Hence, the current keywords structure is “ripe” for searching but useless for putting the metadata back into the exact format it had when it was “captured” from the image!

@Joanna

I really think we should not be interfering in how DxO manages their database. If they want to do it the hard way, that is up to them.

I am not trying to tell DxO how to build their database but rather exploring whether my contention that certain things are easy (notwithstanding database upgrades) or otherwise and indeed they appear to be just that, if my “design” stands up to scrutiny. If my attempts at “design” somehow annoy or alienate DxO developers then that is unfortunate and would be very, very narrow/close minded!

@Joanna

What is most important is that the XMP files and exported versions of an image carry the correctly specified metadata.

Sadly I don’t believe that to be true because of the position PL5 holds in the users workflow some/many don’t want it fashioning the keywords in any way whatsoever, they want what their DAM gives them to be perpetuated be that right or wrong (in many cases wrongish)

Personally I want PL5 to be my DAM so I want it to be able to spit out the keywords properly formed but as well as keeping the other users happy!

@Joanna

And, if I may add

• don’t use PL to manage metadata if you are hoping for compatibility

Have you really studied that spreadsheet I produced and this very topic is about the “wonders” of Photo Supreme ‘Rotation’ (‘orientation’) and its compatibility or rather lack of it.

I could snipe at the laborious import procedures and the various wrinkles that mean that certain combinations of product do not work as they should (and I mean should) and don’t get me started on GPS!!

The topic is actually about a cunning detour to a problem with Photo Supreme (I believe) which no longer works because DxO changed the DOP handling amidst a “deafening” dearth of information, possibly because DxO didn’t understand what users work flow might look like (because they didn’t ask).

If only DxO can fix the issues then they will get me off their back if nothing else and I can use a basic good middleweight DAM without the clutter the other packages manage to add, useful though that “clutter” it might be to some users.

@mwsilvers

DxO’s metadata features are by comparison extremely new. While for a number of users here they are not ready for prime time, I would suggest we look at how far they actually have come in such a short while, and the potential of where they could be in not too distant future.

I am hopeful that DxO will continue to tweak and eventually satisfy most of its critics.

In spite of the bugs I have encountered I have stated on a number of occasions how impressed I am that DxO managed to get the metadata handling this far but it could have been even further if they listened and if they had engaged with users during Beta testing.

I specifically “begged” DxO to reach out to selected users with DAM products to explore their work flows back in March 2021, during PL5 Beta, testing but no response and then they run into compatibility issues when the product is launched, who could possibly have predicted that!?

The only competitor that DxO has for DxPL being a good middle-weight DAM is DxO themselves.

[sgospodarenko (Svetlana G.)]

Good morning,

@BHAYT

Use an Export option:-

I think it was me that suggested that retaining the metadata data could be accomplished by providing a metadata “take from image” option in the ‘Export’ options. At the time it seemed a little “off the wall” but it could be implemented without touching the database and would avoid the need for the “DAM sandwich” and all the effort that entails for the user @sgospodarenko.

• To the attention of @Musashi

Regards,
Svetlana G.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@sgospodarenko Thank you for your attention.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@sgospodarenko and @Musashi my intention with the ‘Export option’ was to “protect” precious metadata from an “unauthorised” changes by DxPL and attempt to restore user confidence and avoid the “DAM sandwich”.

Needless to say I have been considering (not re-considering) my suggestion and it is clear from some discussions on the forum that some users make last minute adjustments to the metadata as well as the image editing!

A “blanket” copy of all metadata from the image (at its latest state just before the export) would certainly keep the keywords in order but might “undo” any last minute changes made by the user to the metadata e.g. ‘Rating’, ‘Rotation’ etc…

So rather than an “either/or” is it possible to consider a “hybrid” approach, slightly more complicated but it might go a long way to keeping more users “happy” than otherwise!

The current ‘Export’ options allow for customisation of what metadata is taken from the DxPL database and will be transferred to the metadata of the exported image. Could an additional option be added to allow ‘Image Data’ to be selected and the other (the current) options then used to designate what metadata, if any is to be taken from the database? An alternative would be to provide a pop-out to select the source of each metadata element rather than a simple selection box but that would require a bigger change to the UI.

However, if the facility to incorporate unchanged image metadata into an exported image is implemented I feel that the “hybrid” approach is worth a little more development effort to offer the prospect of keeping more users “happy”.

EDIT:-

Could the ‘Export’ process also be used to update RAW images, e.g.

1. Export a new RAW sidecar based on the “hybrid” approach above

2. If DxO ever considered updating embedded RAW metadata that could be “tested” or implemented via an ‘Export’ option, again with the “hybrid” option available.

It would be good if there was a “protect” option so that the existing sidecar or RAW file was automatically saved before the new version was created and that mechanism should be able to handle “duplicate” clashes automatically.

An alternative would be to use the suffix field to create new copies but in the case of just creating a sidecar file the original RAW would also need to be saved with a suffix as well as the new sidecar file. Using the suffix could provide the “protection” mechanism automatically but in both cases a DOP would also need to be output for the new RAW + sidecar or for the new RAW.

BUT please amend the warning message for duplicates so that the ‘Use unique’ was at least persistent for the session!

Or just use Virtual Copies and save a lot of disk space!

[Joanna (Joanna Carter)]

@BHAYT

@Joanna according to my tests the animal|mammal|bear will only get a ‘dc’ key of ‘bear’ now whereas originally all elements would have been allocated a ‘dc’ entry!

Bryan, I am having enormous problems decoding your posts, screenshots, etc.

In this screenshot, you are showing the Keywords tag, in the highlighted row, as containing different values than the Subject tag. What did you do to achieve this? Neither my app nor PL5 writes the Keywords tag to the either the original file or the XMP sidecar. However, PL5 does write it when exporting, even though it is not present in the original file.

In fact, the IPTC palette in PL5 has no mention of the iptc:Keywords tag that it goes on to create on export.

@BHAYT

I have never seen the highlighting that you show.

Which one? Both are possible, simply by checking or unchecking the appropriate rows in the hierarchy.

@BHAYT

The whole point is that PL5 has no notion of the keyword type in its database just a lot of flattened keys

Which is precisely what all keywords are - just a flat list. It is only when those keywords are organised into a hierarchy, that the need to record those relationships arises.

• In the database, a parent ID column indicates the parent keyword
• In an XMP record, the lr:hierarchicalSubject tag should contain the relevant hierarchy

At the moment, PL5’s handling of hierarchies is, to put it mildly, chaotic.

I created three hierarchies in my software…

• Couleur > Orange
• Fruit > Orange > Satsuma
• Entreprise > Télécommunications > Orange

Then I applied them all to a RAW file.

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Couleur</rdf:li>
               <rdf:li>Entreprise</rdf:li>
               <rdf:li>Fruit</rdf:li>
               <rdf:li>Orange</rdf:li>
               <rdf:li>Satsuma</rdf:li>
               <rdf:li>Télécommunications</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Couleur</rdf:li>
               <rdf:li>Couleur|Orange</rdf:li>
               <rdf:li>Entreprise</rdf:li>
               <rdf:li>Entreprise|Télécommunications</rdf:li>
               <rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
               <rdf:li>Fruit</rdf:li>
               <rdf:li>Fruit|Orange</rdf:li>
               <rdf:li>Fruit|Orange|Satsuma</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

And, opening the file in PL5, the palette shows…

Unnecessary duplication of keywords in the keywords field but the hierarchy looks fine.

No problem at all.

However, if I remove some of the parent checked items in the hierarchy…

… I get something altogether wrong in the XMP file…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Orange</rdf:li>
               <rdf:li>Satsuma</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Couleur|Orange</rdf:li>
               <rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
               <rdf:li>Fruit|Orange</rdf:li>
               <rdf:li>Fruit|Orange|Satsuma</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

Unless I use PL5’s own search mechanism, there is no way I can search for files that contain a specific hierarchy. The only externally searchable keywords are Orange and Satsuma.

Added to which, using the PL5 search, it is totally impossible to search for Orange as part of multiple hierarchies.

[BHAYT (Bryan [WIN10, PL7, VP4, FP7, G9 & EM1 Mkii, RTX 3060])]

@Joanna

@BHAYT

@Joanna according to my tests the animal|mammal|bear will only get a ‘dc’ key of ‘bear’ now whereas originally all elements would have been allocated a ‘dc’ entry!

Bryan, I am having enormous problems decoding your posts, screenshots, etc.

In this screenshot, you are showing the Keywords tag, in the highlighted row, as containing different values than the Subject tag. What did you do to achieve this? Neither my app nor PL5 writes the Keywords tag to the either the original file or the XMP sidecar. However, PL5 does write it when exporting, even though it is not present in the original file.

In fact, the IPTC palette in PL5 has no mention of the iptc:Keywords tag that it goes on to create on export.

@Joanna can I take this an item at a time!

Sorry about the screenshot clarity or lack thereof! All the tests that I did for my original spreadsheet were

1. Add keywords to four images in an application (PM, LR C1 etc. etc.) of
   1 - animal, mammal, bear
   2 - animal|mammal|bear
   3 - animal|mammal|bear|brown bear
   4 - animal, mammal, bear, animal|mamal|bear
2. Then use PL5 to discover the metadata (keywords) put there by the respective software and export those images as JPGs.
3. Compare and contrast the keywords inserted by the software compared with the keywords output from PL5 as part of a standard JPG export (i.e. the outputs from step 2) and do this for PL5.1.4 and PL5.2.1.

What happened pre the change was that every keyword in a hierarchy would be output by PL5 as a ‘dc’ keyword and as a consequence an"hiatus" “raged” in a least 2 topics with complaints that PL5 had created all these extraneous keywords! So PL5 changed the keywords created so that after the change only the “lowest” key is now placed in the ‘dc’ key on Win 10! Sadly this is not going to fix the complaints nor is it going to meet your requirements for what should be in the ‘dc’ keywords!

I reran the tests using Photo Mechanic to create the keywords in a JPG and PL5 accessed this original JPG, i.e. in this case I did not export from PM, arguably there are two sets of tests that need to be done here;

1. The original image with keywords added by software.
2. The image exported by the software after the keywords have been added.

I believe in the spreadsheet I used method 1 for all except C1 where I had to export!

In my snapshots from both PIE and Exif Pilot the ‘keyword’ column relates to ‘IPTC’, ‘Subject’ is ‘dc’ and ‘Hierarchical Subject’ is ‘hr’. Although I have doubts about where PIE and Exif Pilot locate the 'keyword fields, I just checked with XnViewMP in its ‘Exiftool’ column and it shows the data exactly as do the other two programs!

I repeated the test twice using a different option in PM ‘preferences’, the second test uses the “_AB” image and the ‘Preference’ change removes the hierarchical keyword from the ‘dc’ entries!

Hopefully this snapshot is clear enough to show the two images “keyworded” in PM and the outputs from the two versions of PL5 and the changes to the ‘dc’ fields in particular!

[Joanna (Joanna Carter)]

@BHAYT

1. Add keywords to four images in an application (PM, LR C1 etc. etc.) of
   1 - animal, mammal, bear
   2 - animal|mammal|bear
   3 - animal|mammal|bear|brown bear
   4 - animal, mammal, bear, animal|mamal|bear

OK. Let me stop you right there. Apart from the first item, the “keywords” you are adding are not and never have been valid for adding to the 'dc:subject` tag.

animal|mammal|bear is one keyword that just happens to contain pipe symbols. It has no implicit hierarchical context unless that context is inferred, written and read by one particular software. It has no place in correctly defined metadata, regardless of the software as it doesn’t comply with MWG Guidance.

From that point on, all your tests become irrelevant and DxO has no obligation to consider reading, editing or writing anything derived from such “keywords”.

Amazingly, PL5 does, sort of, cope with animal|mammal|bear…

… but it certainly does cope at all correctly with animal, mammal, bear, animal|mamal|bear…

… with the database looking like this…

As you can see, and as expected, the database bears no resemblance to the full list of keywords placed in the dc:subject tag.

Do you really expect DxO to expend time and effort catering for non-standardised inputs from other software? There is an old acronym - GIGO. Any app that allows separators like <, > or | in the input field, without parsing it into separate keywords before storing it isn’t worth considering.

PL5 might parse text like animal|mammal|bear correctly, but it still doesn’t write the flattened keywords from the lr:hierarchicalSubject tag correctly to the dc:subject tag.

[Photoman43 (Joseph Smith)]

John, I have not yet read all of the responses to your question/issue, but I have had NO SUCCESS with DXO in past support requests to undertake what is needed for DXO PL to reflect processing (and other) changes made to images in the same file folder when that file folder of images is used and processed on more than one computer. In my case it is a win 10 laptop and a win 10 desktop. DXO has told me that this is not a need for most photographers. The only recourse you and other DXO users have is to launch an effort to get this major change incorporated in newer versions of DXO PL.

Others with a more technical background can explain why you are having these problems. The best I can do is to state that .dop files created on one computer are not (completely) transferred with the images when those images are processed and view on another computer.

The DXO software architecture requires me to limit my processing on my laptop (where I first view and cull the files.) And do the processing on my Desktop (my second stage processing.) I would like to move the file folders back to my laptop, but that is when I incur all sorts of cross processing problems.

I will state this. If I change the rotation of an image on my laptop, that rotation change is recognized when I view the image on my Desktop.

Your problem might also be related to a setting in your camera. For Nikon cameras, it might be under Playback.