You’ve found a “feature” in Capture one!
The original formats (templates) that I “discovered” were all from the use case of entering the data directly into the package and forcing the package to write that data back to the image (i.e. create an xmp sidecar for RAW).
The tests were repeated multiple times even when I was using the extended syntax of animals|mammals|bear|black bear and then yet again when I used the abbreviated syntax of as|ms|b|bb.
Throughout those tests, the original tests used 4 JPGs and 4 RAWS, the results were always consistent; so many tests because I was reluctant to “publish” anything that might be “flawed” or too badly “flawed”.
I was also concerned about my lack of experience with the various packages and certainly missed the Lightroom All assigned situation that @platypus found!
But the results were consistent and appear to work for the principle of matching the output that is equivalent to the given use case, i.e. the creation of keywords afresh by entering the data directly into each package.
So I believe that all is O.K. for using the templates to create exported files that match the outputs that the respective packages would create if the data was entered into those packages, via their own UI.
My intention was to keep users “happy” because their keyword layout was intact in the exports, I was not trying to create an emulator for the other packages, with respect to keyword handling!
It is rather sad that Capture One doesn’t seem to stick to to own “rules” when it encounters the situation where there is an hierarchical field that has no data in the ‘dc’ field. I repeated a number of tests and Capture One mostly but not completely leaves the originals alone, i.e. it adds “bb” to the ‘dc’ fields.
Adding an “x” does nothing surprising and is added to the ‘dc’ and ‘hr’ fields as nearly all the packages do, but which Capture One didn’t do when it decided to “liberate” “bb” from the hierarchical keyword, if it was following any rules shouldn’t the “bb” also have wound up in the ‘hr’ fields!
Deleting and re-inputting the “as|ms|b|bb” keyword into C1 results in the return of the original format!
Similar “anomalies” in behaviour might exist with other packages when confronted by data that has been externally generated. In fact on Friday I put my development of a Python “converter” to one side and started to look at the development of an xmp sidecar generator.
The “generator” would take any keyword combination and generate a “labelled” xmp sidecar file for each of the formats I have currently documented. These could then be associated with any RAW image to undertake the kind of test you undertook using manual intervention, in order to speed up the testing process! I need part of that code for the convertor anyway!
My coding skills are still raw (pun intended) but now that I have abandoned the IDEs for a combination of Hippo Edit and IDLE I am not trying to fix errors flagged by the IDE’s that are perfectly acceptable to Python!!??
That brings me to my biggest concern, or rather biggest concern after the complete indifference on most of the users who complained in the first place, namely using this technique to format the metadata written back to the image.
With AS(OFF) such a ‘Write to image’ would have to be user initiated. The existing DOP and database would continue to generate the same formatted keywords without being updated but if a KFT (keyword Format Template) formatted ‘Write to Image’ is made then that should be followed either by an ‘S’ icon or by an automatic ‘Read from Image’ as appropriate and now we have the situation of a changed database structure in-line with the KFT “rules” then being subjected to the KFT rules again in any subsequent export or ‘Write to image’, which bears a slight resemblance to the Capture One case you cited @Joanna.
Arguably users would only ever need to write back to the image if they had used DxPL to make metadata changes but even a simple ‘Rating’ change that the user wanted to keep will currently change the format of the image keywords, the whole crux of the problem (or so I thought)!
So to summarise
- I don’t think this “sinks” the KFT “model” for exports at all.
- I am concerned about the lack of consistency with Capture One and what it might tell us about the reliability of software to have rules that they consistently use.
- The issue of exporting using KFT formatting back to the image and the implications on the process either immediately or when such images are “discovered” anew by DxPL (I think I am overthinking the dangers but …)
Once again @Joanna and @platypus thank you for your testing, I still believe that KFT “has legs” and do intend to complete the sidecar generator and the format convertor because they will be useful tools should I ever bother to test keywords again and getting back into coding is interesting, but me and IDEs don’t seem compatible!?
