Provide a way to import and export the keyword structure

DxO PhotoLab Feature requests
1

Some keyword hierarchies are difficult to create. Consider a set of keywords for birds, Organized first by groups and then by common names. These lists exist and can have thousands of entries. An existing list could be massaged into whatever input format PL might use, but would be extremely painful to enter by adding keywords in PL.

With keyword structure imports, lists could be shared.

Adobe Bridge has a simple structure: one keyword per line with tabs indicating the hierarchy level. Use that format and PL users could share lists created by Adobe Bridge users.

The other side of the coin is the ability to export the structure. I would again recommend the Adobe Bridge format (so that existing structures could be shared or saved). I would also recommend exporting the structure as an HTML file for easy inspection.

One basic use: If I have PL on two machines, I could share the keyword structure by exporting from one and importing into the other. I believe this ability is currently extremely difficult (one could re-create the list by having the two machines index the same set of files). This would not capture the entire structure, but only the parts of the structure that have been assigned to at least one image.

2

I had a complete machine crash 1,5 years ago. Since I could migrate the old disk to a new machine, I managed to save the image folder structure and that way managed to recrerate a flat keyword-file matching the metadata in the images.

It is possible to migrate even to and from Photolab as is but it takes another software that can recreate a keyword list from the files and export a keyword-file, but that is possible only with a flat keyword-list since it is not that easy to create a hierarchy from the non hierachic keywords in the XMP-files and it´s even more hopeless with IPTC. In the first case it takes som SQL-skills and in the IPTC-case I think it is impossible.

My problem was that I use PhotoMechanic and PM can import both flat keyword files and hierarchic ones but since Photolab can´t export the keyword list I first had to create a new keyword list by importing them from Photolab to Capture One. Capture One has the keyword-file export feature we are missing in Photolab.

After exporting that list from CO it was no match to import it into PM and then I was back on track again. Before I settled for a flat structure in the first place, I even tried to use a hierarchic keyword-file from Lightroom and that was no problem at all but it was far from matching the hierarchy-struture I wanted to have. I also found if I should edit it in PM it was better to export it as a TAB-textfil, edit it and reimport it that to build the structures in PM.

After my tests I realized it is a fare more fault tolerant setup using a flat keyword structure. I also realized I don´t want to end up with a lot of images I have tagged with a hierachic keyword table not being able to reverse engineer a new hierarchic keyword table that matches the images keywords.

So instead of adding keywords by selecting structures in Photolab or in PM I have batched a top level structure of to my main catalog of the 26 000 images I have developed so far (PM can have as many as you like simultaneously). It took me two days and it has really given my Photo Archive i PM a fantastic efficiency boost.

Another good thing now is that it is very much more efficient to add second-level keyword through out the archive when I don´t have to walk through the whole archive but just the images under any of the top-level keywords. For now I use a pretty short list of top level keywords: People, Building, Construction, Art, Sport, Transport, Nature, Animal, Business, Religion and Military

Adding hierarchic keywords in PM is a real pain compared just to use the flat keywords.

I write this because I think this is kind of a third way to do it. It shall also be said that I use a very simple image folder hierarchy. A top folder and “session”-folders below containing RAW and 4J JPEG-files in two different folders. PM can automatically see all files under a session-folder (but Photolab and CO can´t). After these updates are done in PM I use to make and “Initial manual synch” in Photolab, first by deleting the existing database file and then by indexing the image catalog from the top folder. Then Photolab will build a new keyword list automatically that is in synch with PM and the files.

The last thing to do is to turn on “Synchronization” in Photolab. After that everything changed in the metadata in PM will instantly be updated even in Photolab if both applications are opened simultaneously (which is best practise). If Photolab isn´t up and running the updates will occur when it is.

3

It’s a bummer you had a crash, but I don’t understand what happened after that. You were able to recover the image files but not the keyword structure?

Right now, with PL 7.3 (older versions had some differences in behavior), I can delete my Photolab database, re-index all my images, and get my original hierarchy restored. This assumes, of course, that the files have the correct dc:subject and lr:hierarchicalSubject tags.

Presumably, Photo Mechanic works correctly, and so any hierarchy in PM should be reflected in the images, and should be easily recoverable by Photolab by re-indexing (and by PM as well?).

The XMP lr:subjectHierarchy tag supports keyword hierarchies.

I’m not sure I’m following. A hierarchic structure is just as fault-tolerant as a non-hierarchic one.

It now sounds as though you are saying that flat keywords are more fault-tolerant, but you are using a hierarchic system anyway.

Sorry, there’s a lot I’m not following. I guess the only important thing though, is whether you are in favor or importing and exporting the keyword structure in Photolab.

FWIW, I have a keyword export tool for Photolab, that generates Adobe Bridge-compatible keyword structure files as well as HTML versions of the hierarchy. I don’t have an import into Photolab, though. If you’re interested, send me a PM. My tools are best suited for people who are comfortable installing and running command-line tools.

4

That is a proprietary element in a Lightroom namespace of XMP.

Yes, you might have built a migration tool but that is proprietary as well.

A flat structure Photolab can manage today but it can´t build a hierarchy-table today, as is the case with any other software I use.

My hierarchy is pure manual and on paper. All my keywords regardless of hierarchy level are stored in one single data element in the files regardless if it is stored in XMP or IPTC. There is no way you can build a hierarchy from that. What is yet to see is support for automatically creation of hierarchic keyword lists reverse engineered automatically at import from the files. So as long as that isn´t in place flat keyword lists are far more resilient and migration friendly than structured ones regardless of which softwares you are using.

… but if I might guess DXO will always prioritize the Lightroom integration and a real integration/migration-path will have to handle hierarchic keywords both ways including automatically build hierarchic keywords lists if that is demanded and/or export them as a TAB-separated text file.

There is no coincidence both Photolab and CO kan handle and exchange flat XMP-metadata in a migration task and no surprise they can´t do the same with hierachic data. There still is no way to do that in IPTC and still the metadata interface in both PL, PM and CO is an IPTC and not an XMP-interface despite the data exchange is handled by XMP. This is still a mess with a lot of proprietary solutions and lr:subjectHierarchy is just one of them. I don´t know if I shall see that element as kind of solution or just an expression of a greater problem - a lack of standard that works and that developers and users are respecting.

Using flat keyword-lists have saved me a lot of migration problems and a lot of time since they are so much faster and more efficient to use.

The risk with the hierarchic keyword lists is that a crash or a forced migration will leave you with a lot of images where despite the former hierarchy in your look up tables leaves you with all these keywords of yours in a flat comma separated list in a “Subject”-element in your files.

In fact, we are a few here that have asked for a keyword-table export for both flat keyword structures and structured ones in TAB-format like Lightroom uses since Photolab got a database. That works fine even for PhotoMechanic. It is a must to be able to export controlled vocabularies between different applications and DAM-systems.

5

If you mean that Photolab can’t import a keyword hierarchy directly, then you are correct; that is why I created this feature request.

If you mean that Photolab can’t create a keyword hierarchy from a set of image files (and possibly associated XMP files), then you’re incorrect.

I’m glad that you’ve found a method that avoids migration problems for you. I don’t personally find flat keywords either fast or efficient, but my keyword structure is likely very different from yours.

I mentioned before that I can delete my Photolab database, re-index all my images, and restore my keyword structure. In addition, when I began using keywords in Photolab, I had a number of images that had been tagged using Adobe Bridge back before 2020. Photolab was able to restore the keyword hierarchy I had created back then.

Based on this, your claim above is incorrect

This particular post is a feature request to import and export keyword hierarchies. Controlled vocabularies are a whole other topic and, as far as I know, unsupported by the current dc:subject and lr:hierarchicalSubject tags.

While a tool (or a user) could impose some control over vocabulary, images are not obliged to support this. You could have a carefully controlled vocabulary, index/import an image into your tool, and wind up with a polluted, uncontrolled vocabulary. The lack of true controlled vocabularies is why I would like to dump the current keywording system and replace it–not that that’s going to happen.

6

When I tested it, it didn´t work at all and images updated with Photolab didn´t look good in PhotoMechanic at all but that is certainly not the big problem now.

The really big problem now is that I have had to go back to Photolab 7.0.2. because the last two updated versions have ceased to “Synchronize” metadata automatically between PhotoMechanic and Photolab.

When it comes to maintaining the integrity of keywords I have no problems really since it is just my own inputs that builds the list. One thing I do have wondered about is how people manage to avoid contamination using AI to automatically add keywords. I realize even I have to be extra careful when adding images taken with smartphones. I wouldn´t like these images keywords to pollute my data when reindexing.

7

I reported one bug where PL failed to update the XMP files.

One approach that seems to work for me is to select all the images that I want to make a change on. For instance, if I want to rename A to B, select I search for and select all images tagged A and then do the rename.

I think I’ve mentioned that I have a diagnostic program that can spot when the data in PL’s database doesn’t match what is in the DOP/XMP/RGB files. Using the above approach, my tool has been reporting that everything is OK.

8

@freixas
I never use PL to update XMP (unless for trouble shooting) since I normally always update in PhotoMechanic. PL is updated through the auto “Synchronization” in PL. It stopped working completely in the version that replaced version 7.0.2. that is the last one that seems to read the XMP-data automatically and not just automatically really because I couldn´t even get it to work with a manual read via File.

I don´t need to analyse anything really because it is perfectly sufficient to check whether PL updates its IPTC-elements or not after a change in PM Plus. These changes are instantly updated even in PL in a second or two normally.

The synchronization between PM and PL has been rock solid för a long time before DXO fucked it up with the last two updates of Photolab. So now Photolab 7 is playing in exactly the same league as Capture One when it comes to a none working XMP-metadata synch with PhotoMechanic, because their isn´t working either.

I´m still waiting for DXO to fix this together with all the rest we are waiting for.