@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.
