Hi,
only a short marker…we discussed all the things here Database Maintenance - #59 by George also the point with the Metadata User Guide.
So again a step backwards in the future 
have fun
@Guenterm I followed your link but then wound up on the database synchronisation topic and made the following “rash” post Synchronise PhotoLab - #23 by BHAYT.
Hi Bryan. I have done some research on ACDSee and found an interesting post in one of their forums…
There are two types of keywords in AcDsee
- AcDsee Keywords. Image->Properties->Keyword Tab. These are AcDsee keywords own keywords and you can have a Hierarchical keyword tree and a keyword list can be imported and exported. However, this information is only put into the AcDsee metadata and only AcDsee can see them (maybe a few other odd software packages) almost certainly the OS cannot see them. Additionally the Tools->Metadata->Embed AcDsee Metadata should be run to ensure the AcDsee metadata is written to the Image Metadata and not just stored in the database.
- IPTC Keywords. Image->Metadata._IPTC->Keywords These are where universally standard keywords are stored. Unfortunately the design standards do not allow a hierarchy (as far as I am aware) so keywords are stored in a flat structure with comma separation. The three little dots next to the keyword box allows you to edit the keywords and full keyword list used in all images. These keywords can be seen by most software including the OS
Therefore if you export an image, and look at the image properties. The only keywords you will see will be the ones used in the Metadata PTC keywords. The AcDsee keywords are not visible. However if you used the Tools-Metadata-Embed Acdsee keyword option the keywords will be there just hidden and some software may be able to see it
As we already knew, IPTC doesn’t support hierarchical keywords and any such keywords are written to ACDSee tags. But, if we look at the XMP-acdsee tags available, we only find one called Keywords, with nothing explicitly defined for the handling of hierarchical tags.
Then you have this…
ACDSee metadata is proprietary and not viewable in exif (normally it is stored in the database however when you embed it you are writing the proprietary metadata to the files themselves). To get keywords and other acdsee metadata to be readable in exif you need to create a metadata preset to add them to iptc
So, unless you use ACDSee, you are not going to be able to see the “true” hierarchical keywords because they are only written to the ACDSee database, not the metadata. But, I guess, people have instituted the workaround of writing something like animals|mammals|bears|black bears into the IPTC ApplicationRecord Keywords tag because IPTC doesn’t support hierarchical keywords either.
However, this is, to use a technical term, a kludge of the first order and is the reason why we see inconsistencies on interchange of hierarchical keywords so defined in ACDSee.
In summary, ACDSee does not support hierarchical keywords outside of ACDSee, so you are never going to get a perfect solution for compatibility with PL5, or many other apps come to that.
As for Zoner, I couldn’t find anything on their site about hierarchical keywords - they seem to use the concept of categories instead. But, once again, they seem to be more concerned with IPTC, so true hierarchical keywords are not going to be possible without “The Kludge™”
I couldn’t even find help or a manual for ExifPro and it looks more like an open source hobby project that only handles hierarchies by using the same kludge.
@joanna I was not using ACDSee keywording I was writing straight into the ‘xmp’ ‘dc’ fields and that is where the various programs discovered that data and acted upon it, i.e. the programs see the hierarchical data in the ‘dc’ fields and use that data but those programs remove the hierarchical keyword from the ‘dc’ field completely.
Please remember that the test was about using the respective packages to set up the keywords using their own interface and then “feeding” the sidecar files that resulted from that into PL5 and documenting the outcome.
I have since started two more test cycles, one where the package adds a key to the ACDSee 'xmp; sidecar and another where the package imports the sidecar data and is then instructed to write/output or sync etc with the photo (sidecar).
The latter tests tend to track the original tests well but the former were something of a surprise and showed the existing keys being treated as a single keyword to which the data was added (you had suggested that might happen).
So we have the ‘dc’ data being treated in different ways depending on what is being done with/to it. Watch this space …
This is just an FYI: IMatch comes with a number of ‘apps’, one of which is the Metadata Analyst. “This app analyzes the metadata embedded in image files, XMP sidecar files and the database itself and helps with identifying and fixing common metadata problems .” IMatch Help System
The app can be very helpful in tracking down metadata issues and problems. You could probably use it to ID inconsistent metadata handling in images from different programs.
@jch2103 thank you for that info, I managed to hang IMatch today!! It ius actually hung but it is stuck with “Updating” on the first two of the 4 files!
How do I run MDA!?
Go to the App Manager (in the lower right corner panel). It’s a tab in the same panel as Keywords, Map, Categories.
Good. You may also want to take a look at this entry in the IMatch Help. The entire topic has a pretty good discussion of the whole metadata mess, and may help explain why IMatch was having a problem updating those files.
Bryan sent me a mail and wanted to drag me into this discussion and I must say I´m glad I stayed out of it so far.
Still I have a few things to say:
We refer to standards when it comes to both IPTC and hierarchical keyword and some call them just that and others call them “structured”, so not even there to begin with we have any consensus.
IPTC exists in it´s own right and also as an embedded IPTC-namespace in XMP as does the old EXIF. Despite XMP exists, quite a few softwares seem to use the old non XMP-version when using the data. Some systems fork data in their own way as does others too - hard to get a standard there I guess. In the other end like the filemanager in Windows (still in version 10) isn’t reading IPTC but EXIF and it also does so by using a set of conditions like if that field is empty read another element instead. So this isn’t straight forward at all.
In Photolab ratings refers to EXIF as for example PM Plus but there in the variable list that variable is called “Rating” and is placed under the label “Camera” which i guess is another word for EXIF. Should we be surprised if people get confused even before we have started to populate all these fields.
I understood Joanna´s opinion about IPTC - after referring to a trustworthy source - was to urge DXO not to bother too much about it because it´s obsolete. Still both a lot of software and the whole newsindustry relies on this old standard still embedded in XMP or not.
The reason I have tried to stay out is this is that I think I have to live in the present to get my own workflows to work properly when it comes to “my own” integration of PM Plus as a metadata editor and image library. I´m extremely deformed by 25 years as an IT-developer always looking to solve problems as quick as possible with what i have and not by what I wish to come in a new version of some software some where in a future.
We have sorted quite a few things in quite a few treads in this forum already but I don´t really see that the DXO-staff participates in these diskussions active enough to get something to happen in a near future, sad to say.
What I have found is working very well for me is to let PM Plus manage all aspects of the metadata and using PhotoLibrary only to search and display metadata when using Photolab.
Never ever update anything in Photolab. The other condision is never ever use hierarchical keywords in either PM Plus or Photolab, because the exchange between Photolab and PM Plus 6 does only work with plain unstructured keywords today.
If I index my images “topfolder” with images that has got their metadata applied in PM Plus 6 with plain unstructured keywords, the images will get indexed and a flat keywordlist with aggregated total numbers will be created automatically.
When I have developed these images in Photolab 5 and export them as JPEG-, TIFF- or DNG-files and open them in PM Plus 6 I will see that Photolab has not messed up anything at all. All the metadata I had in in my RAW-files before the export will get exported to the derivate-files and it´s easy to check that up in PM Plus. If you do like this Photolab and PM Plus is a really good match. If we respect that we won´t get any problems from what I have seen.
Photolab has to be further developed to use structured keywords if you are thinking of exchanging data with other tools. Photolab also needs to get an interface to be able to import tabseparated structures from both Lightroom or other systems.
From what I have read these questions around structured keywords seem to come mainly from Lightroom users but try to consider that there are as many vocabularies out there (lists with bot structured and flat keywords) as there are business branches. Why shall we focus entirelly on the one from Adobe Lightroom?
I started myself importing a Lightrrom list in PM Plus and started to work with it but found it extremely cumbersome both to use and to maintain. I maintained it in by exporting it from PM Plus and imported it after I had updated it.
The last week I have posted a couple of stories about the decline of the graphical industries in Sweden with totally 37 images. Before I really started to add XMP/IPTC-metadata to my blogg- and portfolio-images in 20+ elements/fields, not very many of my images were found by Google. After it´s a really big difference despite just using a flat keyword structure but keywords are only one of these 20+ elements right?
Isn´t that what this is about? To get results? If I had got paralyzed by my structured keywords not very much should have happened and remember, for Google it’s just words to index and search. Sorry to have escaped through the widest hole but I really had a lot of problems getting any efficiency out of using structured keywords.
The compatibility in consuming systems are very much more likely to occur when having a simple flat keyword list that just creates a comma separated list that every other system can relate to in the simplest way. I have seen a bit of how time consuming the task of building vocabularies can be in the historical heritage world in my country and that has put me off a lot to invest a lot in efforts like that. First they had very high spirits and formed a committe and some work groups than then the years went by… I´m not criticizing just saying it´s really hard to build and maintain structured vocabularies. It´s a never ending job. How many will have the endurance to row a boat like that ashore? Not me!
With that said I really like when I can see in Photolab what a search really hit - IPTC - the text in Caption - or something else.
Photolab olso need a few correction in the “Referece”-screens that makes it possible to decide whether to just use Photolab as a selfcontained “DAM” where all metadata is maintained or whether it shall just consume and use data owned by a third party software.
Sorry for the extensive text. I guess the people that use to count the words in the texts needs to get something to drink. 
I use PM+ with structured (hierarchical) keywords and they appear fine in PL. Admittedly, I only use structured keywords in a very specific case where I classify my fish pictures with common name and scientific name. Other than that case I find it all works just fine.
One thing I do NOT do is specify each path separately so I only have ONE hierarchical keyword. This is what PM+ does by default.
The real problems occur if you by your own will or by mistake save metadata in Photolab to the XMP PM Plus is supposed to own and read because the structures from Photolab will get corrupted. You can’t use bidirectional flows and there is no fool proof way today that prevents oeople from doing so.
This thread is from the beginning about gosting ratings and we have a problem with us using software developed for photo journalists in the media world using IPTC AND EXIF simultaneously while the software only supports IPTC fully at the best.
In my case my workflow is perfectly fine as I use my tools today BUT there are three or four elements in Photolabs IPTC interface under the label “Image …” that doesn’t show at all despite I have filled “the picture taken”-elements in PM. Apparently Photolab uses other element for me unknown and frankly I don’t really care since the dataroundtrip is fine from the PM-horizon.
It’s my opinion Photolab isn’t really ready for structured keywords yet and the reason I have described above. There has to be a possibility to migrate not just the keywords you have used so far in the software you are migrating from but also importing the corresponding vocabulary you have used like in PM but maybee there is a posdibility to just place a tab separated file with a standard name on the right place on the disk as a work around.
I can also think of scenarios where people want to use different vocabularies for different databases or catalogs like you can in PM if you like but maybee that’s too much to ask for in an entry level library as PhotoLibrary. Still these are demands people will come up with in this DAM-like world. If a company like DXO now tries to reach them a hand they will expect at least to get an arm. So I guess the people that raised doubts when DXO went into this DAM-like world because they suspected this will slow the needed development of the image development tools might wake up finding they were right.
With that said I’m extremely pleased now to see that the metadata I add to my images today gets indexed by Google often in just one day. The first reason to put in the metadata work is to get a better order in my own image library but it’s a very important spin off that it really helps making my images more visible than before. To add metadata to the images is pretty time consuming activity and as retired I have the time but I really wonder if the people that could benefit the most from adding metadata really have the time.
A few thoughts/comments:
- Everyone’s got different needs re metadata or lack thereof (and as @KeithRJ points out above, some of us even have specific needs for particular subjects and not for other subjects!). Some people are fully content with just folder-based organization while others pay detailed attention to things like highly structured keywords, etc. That’s certainly fine (although a few folks seem to think that because they have certain perspectives/needs that everyone else should have the same…).
- To the extent possible, DxO should accommodate and not interfere with different needs. At the same time, DxO should avoid doing harm. They’ve taken some steps in that direction with the Metadata synchronization option in Preferences, but some more work by DxO is needed, especially for keywords and other metadata that’s copied (or not copied) to output files. The whole subject of metadata is a complex mess, and it’s not a surprise that it’s taking DxO some time to grapple with it.
- I’m in the ‘I want to manage my own metadata and do not want PL to interfere with it’ camp. As long as DxO doesn’t interfere with my management, I’m happy with whatever solutions they provide users who do want to use DxO’s metadata management. (I may still have constructive criticisms of what they’re doing, to help avoid issues for users.)
- A technical aside: IPTC has two basic ‘flavors’, the old/obsolete IIM flavor and the new XMP-based flavor. It’s confusing enough that these both exist (and that IPTC hasn’t deprecated the old version), but more confusing when users here don’t distinguish between them. (I’m pleased to see that DxO has fixed some IPTC-IIM issues for exports in the next release.)
I think the real problem with metadata is there are very few “hard and fast” rules and there are too many options for storing metadata differently. Not all apps support all these different ways of storing metadata. What one app does may be correct but may also not be what another expects and that is where the issue lies.
What you need to do is find what works for you and stick to that and hopefully you won’t have too many issues.
I used Lightroom from version 1 to 6 until it went subscription and used it’s Catalog system very effectively but not too complicated either. When I moved to PL I was happy NOT to rely on the database and that is what I still do. For my fish keywords I now use PM+ and as long as these keywords flow through PL to my final jpg then I am satisfied.