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.

9

Warning: Proceed at your own risk
Exercise caution.
Do not work on your live DB
Make multiple copies of your database OUTSIDE the original location to avoid accidental overwrites and database corruption

To export:

  • Download SQL Lite DB (https://sqlitebrowser.org/)
  • Make a copy of PhotoLab.db (Win: %APPDATA%\DxO\DxO PhotoLab [version #]\Database)
  • Open the file, click the Browse Data tab and from the pull down select the Keywords table.
  • From top menu, select File > Export
10

Or you could use the SQL I posted at Some database querying tools that you might find useful to get a human-readable version of the keywords using the SQLite browser.

Or, if on a Windows system, you could use the exportKeywords tool I provided at PhotoLab Keyword Tools to generate various human-readable versions of the keywords (including an HTML version). No SQlite browser needed and there’s a matching importKeywords tool.

11

Happy the next person that finds this thread will be able to get the answers all in one place!

12

Of course, for one image, you could always create/edit an XMP sidecar file with the same name as the image…

<?xpacket begin='' id='W5M0MpCehiHzreSzNTczkc9d'?>
<x:xmpmeta xmlns:x='adobe:ns:meta/' x:xmptk='Image::ExifTool 12.11'>
<rdf:RDF xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'>

 <rdf:Description rdf:about=''
  xmlns:dc='http://purl.org/dc/elements/1.1/'>
  <dc:format>image/x-nikon-nef</dc:format>
  <dc:subject>
   <rdf:Bag>
    <rdf:li>Keyword</rdf:li>
    <rdf:li>Fruit</rdf:li>
    <rdf:li>Orange</rdf:li>
    <rdf:li>Satsuma</rdf:li>
   </rdf:Bag>
  </dc:subject>
 </rdf:Description>

 <rdf:Description rdf:about=''
  xmlns:lr='http://ns.adobe.com/lightroom/1.0/'>
  <lr:hierarchicalSubject>
   <rdf:Bag>
    <rdf:li>Fruit</rdf:li>
    <rdf:li>Fruit|Orange</rdf:li>
    <rdf:li>Fruit|Orange|Satsuma</rdf:li>
   </rdf:Bag>
  </lr:hierarchicalSubject>
 </rdf:Description>

 <rdf:Description rdf:about=''
  xmlns:photoshop='http://ns.adobe.com/photoshop/1.0/'>
  <photoshop:SidecarForExtension>NEF</photoshop:SidecarForExtension>
 </rdf:Description>
</rdf:RDF>
</x:xmpmeta>
<?xpacket end='w'?>

This is just an example but all you need to do is replace the keywords in their appropriate tags and save the file next to the image.

Then, when you open the image in PL, you just import the metadata.

13

PhotoLab might ignore/fix this if it’s an inappropriate format, but best to leave it out.

I think you meant this as a placeholder, but since the other entries are specific examples, it’s probably best to omit. Without testing, I have no idea if PhotoLab would create a keyword called “Keyword” or not since there’s no matching entry in <lr:hierarchicalSubject>.

Relative to the OP, one could import an entire keyword hierarchy by picking an arbitrary RAW image, manually creating an XMP file for it containing every keyword desired, and importing it (File → Metadata → Read from image). One could export the entire hierarchy by selecting a RAW image in PL, assigning it every keyword, and exporting the XMP file (File → Metadata → Write to image).

This is indeed a work-around, but not one that should get DxO off the hook with respect to this feature request.

14

Of course this kind of detail would need adjusting. I just created an example, based on my camera.

It was just a test keyword that was not hierarchical.

There is no need to add standalone (non-hierarchical) keywords to the <lr:hierarchicalSubject> tag. Note this behaviour is based on the MWG guidance, which ensures better cross app compatibility, and is different to how PL writes keywords in their DOP files.

On the other hand, all components of a hierarchy must be decomposed and placed, as individual keywords, in the <dc:subject>tag, which is what my example shows.

I have used four keywords but only three of them participate in a hierarchy.

15

Importing and exporting keywords feels like something that could make sense in early moments of using PhotoLab instead of any other app. Then again, we end up with a fully populated keyword list that is not connected to any image.

In order to make sense of importing keywords, there should, imo, be a service that can copy the keyword structure including all the relations to the respective files from the source app to PhotoLab. And as long as such a service doesn’t exist in PhotoLab, we can only transfer keywords and relations through sidecar files. :expressionless:

Restoring a PhotoLab database from a e.g. Lightroom Catalog backup could do the trick, at least for all the items that are a) written to sidecars by the source app and b) PhotoLab can handle. First step: Metadata, second step: Development settings.

16

Internally, PhotoLab does not support subject keywords, thus my comment that I don’t know, without testing, whether PhotoLab will or won’t create a keyword called “Keyword”. If it does, the keyword will be hierarchical (i.e. included in the <lr:hierarchicalSubject> tag on output).

Most of the keywording tools I know support the concept of having hierarchical keywords that are used for organizing and are never output.

17

Import/export of the keyword structure is not just something useful when first using Photolab.

You import the keyword structure to speed up creating special hierarchies. These are often called “vocabularies” and there are people who actually sell these. In my case, I might import a list of birds names organized by families. You export the keyword structure to share with others, or for other purposes (e.g. you could save the structures over time and use a tool to check for changes).

These operations are useful at any time.

As for a service to transfer keywords from Lr to PhotoLab, feel free to add your own feature request. This request is not part of the feature I’m requesting in the OP.

18

If you are talking about in the DOP file, it would appear that PL has its own peculiar way of writing standalone keywords.

But, if you look in the XMP pile it generates, here is what PL writes for two non-hierarchical keywords…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Surfeurs</rdf:li>
               <rdf:li>Vagues</rdf:li>
            </rdf:Bag>
         </dc:subject>

And this is what is written to the XMP by PL if I then add my fruity hierarchy…

Capture d’écran 2025-08-11 à 21.18.20
Capture d’écran 2025-08-11 à 21.18.20618×810 89.1 KB

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Fruit</rdf:li>
               <rdf:li>Orange</rdf:li>
               <rdf:li>Satsuma</rdf:li>
               <rdf:li>Surfeurs</rdf:li>
               <rdf:li>Vagues</rdf:li>
            </rdf:Bag>
         </dc:subject>
  … 
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Fruit</rdf:li>
               <rdf:li>Fruit|Orange</rdf:li>
               <rdf:li>Fruit|Orange|Satsuma</rdf:li>
               <rdf:li>Surfeurs</rdf:li>
               <rdf:li>Vagues</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

Strictly, there is no need to add the non-hierarchical Surfeurs and Vagues to the lr:hierarchicalSubject tag but it does no harm.

When you’ve done as much research and work on keywording as I have, you will realise that even Adobe, who helped write the “rules”, doesn’t stick to its own standards. And other software can be equally non-conforming.

When I wrote my own software, I tested it against multiple tools, including PL and ensured that it was compatible with all the commonly available tools.

My app has a separate management window just for the purpose of creating and managing hierarchies without having to write anything to any image or XMP files. It also allows for the import of pre-written keyword lists that you can find in several places on the web.

1 Like
19

You are drifting away from the OP, Joanna. The OP is about adding the ability to import/export the keyword structure using PL. Your app’s ability to import keyword lists is nice, but irrelevant.

20

@freixas , @Joanna is just saying that a one nose company can do it - and she is well aware that “easy” has nothing to do with writing software that actually works.
:innocent:

1 Like