Suggestion for Keywording improvement

I would like to see PL expand the keyword capabilities to:

  1. allow the creation of a hierarchical structure of keywords, present the structure under keywords heading and allow the assignment of multiple keywords to a single image by selection from the hierarchical list.

  2. place the chosen keywords somewhere in the image so that if the image is exported to picked up by any other photo processing app, the keywords will be there.

Currently ACDSee does this nicely and will embed the keywords in the image so that other ACDSee users looking at the image will see the keywords. However, other photo editors do not pick up the keywords. e.g. PhotoLab does not see the keywords imbedded in images by ACDSee.
PhotoLab could make its product a more complete DAM by doing this.

  1. Allow the import of an exported keyword list from another editor into PL and keep the hierarchical structure.

This would allow users of PL to view it as a complete solution for editing and digital asset management.

see the screen shots following for examples of hierarchical structure used to assign multiple keywords to a single image.

the first link is for the image - flamingo which is a bird.
the second is for a part of the keyword hierarchy used to assign some keywords to the image
the third link is more of the hierarcharchy used to assign further keywords to the image
and the 4th link is the resultant embedded keywords for the image in ACDSee’s metadata. this information can be seen by another ACDSee user if the image is sent to them. These keywords do not appear in PL for the image.

I can export the entire hierqarchy to a text file that can be imported and used in ACDSee, and I export it after updates to the list as a backup in event a recovery is required.

this is how keywords should be improved in PL to make it a better DAM.

What do others in this forum think?

keywords 2

keywords 3

Here we go again - I am curious about the replies you get.
I am in the camp of “Dxo should not become another lightroom” but focus and staying the best raw-converter.
I am sure others look at the world differently.:slight_smile:


I’m all for it.
And it isn’t adding a function but improving the already existing one.
For the moment I add the keywords with Adobe Bridge or XNViewMP which has this functioning, and it is much easier to assign keywords to an image.

1 Like

There very many ways in which DxO could become a better DAM, but it is highly unlikely to every become a good DAM - they are just too complex. Any development in that direction will mean diverting cash and effort from enhancing image processing capabilities, which is DxO’s strength. As many of us have said before.

But, having started adding DAM functions, DxO should now find a sweet-spot between additional income from attracting additional users (presumably there is some) vs expenditure on DAM development, then go no further.

I agree with Franky here. The basic functionality for adding keywords is already in PL. would be bonus to have it expanded to make it more useful and much easier to accomplish adding multiple keywords. To be able to import and save a text list of keywords in a hierarchical structure and store them in some “universally accessible by any post processor location” cannot be that hard since the basic functionality is already there. Just a further thought.

And BTW, thanks to all who chimed in on this.

1 Like

You have my vote. Hierarchical Keywords management in PL is unfinished job.

I use Photo Mechanic for keywords because of their brilliant hierarchical keywords. The keywords are stored on XMP sidecar files and transfer perfectly to PL which sees them as hierarchical keywords.

Hi KeithRJ…

thank you for responding. I have just downloaded Photo Mechanic (trial) and am trying to use it first for resolving geo-tracker log file to turn the contents to GPS coords. I tried to follow the help for PM but it does not seem to match the program. I just joined their forum to get help with that, I also want to explore their keywording to add there and see if the Keywords would carry over in the images when passed to PL. Life is getting way too complicated. :slight_smile:

The last thing I want is software that modifies raw files.

For one, these aren’t documented formats, and even if most of them are more-or-less TIFF, there’s no knowing what damage buggy software can do. Sidecars exist for a reason.

For two, modifying the raw would mean having to backup these largish files instead of small sidecars. That has a big impact on incremental backups, which is the reason I detest Lightroom’s refusal to write sidecars for DNG and TIFF files.

Otherwise, I think the DAM features in PL are a bad fit given DxO’s approach to backwards compatibility. Every PL upgrade has introduced changes in the way existing edits have been rendered after the upgrade; that is, do work in your existing version of PL to arrive at a rendering you’re happy with, upgrade, and then see that the rendering in the new version of PL isn’t identical. The changes have been small (eg. I had blue skies that were a little more saturated in PL3 compared to what I edited in PL2), not all images are affected, and I’m sure that DxO tries to minimise the changes, but it’s seemingly best effort rather something like a process version you find in C1 and LR (for two). If I have to export my images to retain my current rendering then PL is a tool for producing raster files, not for maintaining edits across a number of software upgrades.

If PL is going to become a more full-featured DAM, then respecting the rendering of edits performed in previous versions of the software is a prerequisite IMO.


Unfortunately, I don’t think the folks behind PL see their product as a full featured DAM. It would be nice and something that I would like if no no other reason than to have 1 product that does a great job in editing and managing of photo assets.

That being said your comment about upgrades to PL not respecting prior version edits (rendering) is definitely something to be concerned about, and that is where PL will most likely focus their limited resources if this is the case.

I still believe though that improvement in handling keywords along the lines I suggested .should be easily doable considering the basis is already in PL, and retaining the keywords within any file type and being able to see them regardless of what editor a picture is passed /exported to, would put PL in a good position to expand on DAM capabilities in the future.

I’m not holding my breath based on previous threads where this has been discussed: DxO either doesn’t want to acknowledge the problem or thinks that trying to patch issues as they arise is good enough. It is if you just use PL to export raster files and don’t necessarily expect the rendering to be unchanged when you revisit the image in a future version of the software, but I’m not so sure that this is what many expect when they start seeing features that remind them of Lightroom.

Good morning,

I’ve also voted because I would like to see improvements within the photo library.

Particularly the search function for essential camera and lens data isn’t well implemented

I wonder why the theme doesn’t get more votes during the time…

Tanks for any vote

Like Keith I use Photo Mechanic for keyword management, and activating XML sidecars in PM integrates with PL for raw files.

However I’d like to see PL reciprocate. So adding a keyword in PL, in addition to updating the database, updates/creates an XML sidecar for raw files or updates JPEGs etc.

Whilst PL is light on DAM features this might bridge a gap and retain integrity with external DAM software.

Interesting statement you make about patching when problems arise. In a former life (before retirement) I was a developer in a business environment. Many times I came to “blows” with manager who had the same attitude - dont worry about bugs until they are reported, then address them. We need to get the product out to the users as soon as possible.

I could not develop in that fashion when I encountered the bugs as I was testing the programming. To me it was ludicrous to ignore a known problem then have to worry about fixing it months or years down the road when it showed up - especially since in all probability, me, as the original developer had my name attached to it, would be tasked to fix it. In the meantime other changes to the program by others after put in production, could very well make the obvious fix at the time I encountered it, be a far more complex fix than in the beginning.

It made no sense to me to ignore the obvious and build a buggy system than to try to get it as close to bug free as possible. Needless to say, I ignored my manager and did my best to ensure my software was as bug free as possible before putting it into production

Just a reflective thought you awoke in me! :slight_smile:


Agree too. We should add multiple keywords. As Franky I have also keep a hold version of Aperture to assign keywords. It will also nice to edit major IPTC infos to be complete.

How did I miss this thread?

A question to those people who are in the “PhotoLab should stick to being a RAW converter” camp — what other commercial software can you name that follows this model?

I have to believe that the existing DAM capabilities in PhotoLab were added because DxO felt the market wanted it. All of the other software I have used — Lightroom, Aperture, Luminar, ON1 — have a DAM and with the possible exception of Luminar, all of those products have a more capable DAM.

The idea of “don’t make it another Lightroom” seems strange to me. I could agree that maps and slideshows and even printing do not belong in PhotoLab (though all of these features have been asked for in this very forum) because I, myself, wouldn’t have a use for them. But I think we can agree that if Adobe changed their pricing model, a lot of people would just use Lightroom because it has everything under one roof, as it were. Like it or not, Lightroom is the competition.


An alternative with an equally short answer might be to name an integrated product that has a good DAM. Compatible with Photo Supreme / iMatch / Daminion.

Personally I’d rather choose a ‘best of breed’ approach, using DxO’s high quality processing software + separate highly functional DAM (Photo Supreme in my case).

My own concern was (and is) that DxO’s time and cash will be spent in adding mediocre DAM features, with constant requests for further enhancements, rather than concentrating on adding enhanced image processing functions. Which, in some cases, we’ve been waiting for for years.

It might be interesting to read some of the other arguments from when the topic was first raised - for example here.

I hope that was the right call, and that the expanded user base at least covers the costs.

Hence the need for DxO to maintain a distinct USP. Unless there’s enough cash to be able to out-compete Lightroom across the board, feature-for-feature.

Fair points, but I still believe that a little extra work on the DAM — writing them to sidecars, a keyword manager pane — would make it a solid offering.

I see that Photo Supreme goes beyond its remit, too, including image processing options the are covered by any product like PhotoLab. I guess they do this because some people want some basic but solid functionality in their DAM. Sounds familiar.

1 Like

It’s a matter of scale. Adding a feature - red eye reduction, say - is relatively simple and well bounded, with limited ongoing maintenance.

Writing and maintaining a DAM, properly, requires years of work and ongoing maintenance.

Just take a look at all the release notes for iMatch (currently up to 1,322 enhancements, changes & bug fixes) or Photo Supreme (currently on build 3,389). That’s a serious amount of work.

Am on the same page