Colour labels no longer successfully read from Lightroom

DxO PhotoLab
1

I opened PhotoLab to a recent folder and was a little confused why the little squiggle was present suggesting metadata had changed externally.

The image in question had a green colour label. I clicked the squiggle and confirmed a reload of metadata and the green label disappeared!

Oddly, I tried fetching metadata for images in a different folder and they retain their colour labels.

I next looked inside the (DNG) files. As far as I can see, Lightroom is writing the labels as it always has, as XMP-xmp/Label with a simple colour name like Green or Yellow.

I have tried multiple reads in those two different folders — the older folder leaves everything with colours, the newer folder will not retrieve the colours.

This will be disastrous as I use Lightroom to catalogue my photos and colours are an important part of telegraphing information between it and PhotoLab.

2

@zkarj , which versions of PL and Lightroom or Lightroom Classic are you dealing with?

On my Mac, colour labels have never worked well or at all with the versions of PL and LrC available since DxO had added the feature. This was due to language differences caused by my non-all-english setup.

Some exchange was possible with Capture One though.

3

Lightroom 14.1 and PhotoLab 8.2.1.

I’ve been setting the labels in Lightroom and reading them into PhotoLab for as long as I can remember.

What puzzles me most is that the images already had the green label and only when I re-read the metadata did they disappear.

4

I don’t suppose that PhotoLab now features destructive readout. Maybe it’s a question of timing (sequence) of the synching steps. Instead of reading the label value, PhotoLab writes its own (nil) value?

How do you sync metadata? automatically and/or manually? Some leftovers in a cache that is not purged when it should be?

5

And what language do you run Lightroom and PhotoLab in?

6

Just a general remark on how Lightroom Classic v13 and PL 8.2.1 write their label tags:

In Lightroom, the label is just a line the rdf:Description block

   xmp:Label="Rot"

In PhotoLab, the label is a separate tag

         <xmp:Label>Red</xmp:Label>

We also see that Lr writes localised label text and adds “” while PL sticks to English.
When I set LR to have its UI in English, the label text is still localised.
I’d need to set at lease my user account to English (or even the system)

Anyways, looking at things from this somewhat technical side does not show anything that looks different from what I remember from earlier tests. My lesson learned is to not use the colour tags to transmit info between Lr and PL. Also, from an IPTC point of view, the label tag is intended to contain personal notes in free-text and limiting this to just a few values, the exchange of which cannot be guaranteed is somewhat ho-hum imo. And it doesn’t help that all apps do it.

Note that, if I edit the text in the xmp file, PL shows the label colour as intended.

7

I have just tried with PL in French and macOS in French.

I use Exiftool to set the Label tag to “jaune” and PL reads it as “unknown” (grey). Changing it to “yellow” using ExifTool and re-reading the metadata then shows the expected yellow colour.

You could say that this is yet another of those annoying UI bugs, but the xmp:Label tag is officially just a text tag that can be assigned anything. But Adobe, amongst others have “abused” it to signify a colour.

In my opinion, there would be a ColourLabel tag, which takes a numeric value from 0 to 7 and which refers to a localised lookup table for the actual colour name.

8

As always, there is a workaround that I just checked on my Mac with LrC 13:

In Lightroom

  • Select the color label set item from the metadata menu
  • Create a new set (which im my test was just a copy of Lightroom’s own set)
  • Rename the labels to correspond to DxO’s and to make them stay in English
  • Set Lr to take colour labels from the new set e.g. “DxO Colour Label Set”

Please note that there are a few limitations

  • Lightroom handles 5 tags only and their shortcuts are fixed
  • No additional tags or shortcuts (according to my current sloppy research)
9

Both in English.

This may be a lesson for me now, even though it has been rock solid for many years to now.

I just tried another experiment. I set the colour to Yellow in PL, then asked it to read from the file. It removed the yellow. So its interpretation of what Lightroom has written is that it has no colour at all.

I also note that all images in this folder now have a 1 star rating. In LR, no images have any stars. I never use stars in LR at all and rarely in PL.

I think there is a fundamental, and new, disconnect in how PL is reading metadata.

10

Things like these is the reason why I never ever use Swedish in my applications. It is just to ask for problems like these.

Another reason is trouble shooting. If I get a problem with a Swedish set application I will be on my own but if I use English a lot of others can help me often.

I understand Swedish is a fly fart in the air spoken by 10 miljon but French ang German is a different thing.

11

I have filed a support request.

1 Like
12

Well I got a slightly baffling response, but it is apparently a known issue from 8.2.1. Meanwhile, I noticed today that images are again picking up the labels so I wonder if it was only images that had detected the change before the upgrade but refreshed after.

13

I’m a little surprised by reading of these problems today but when I have been working with my own integration between Photolab, Capture One, PhotoMechanic and XnView even I had to make sure to secure the Color-mappings by editing them where it has been possible like in PhotoMechanic and XnView.

In the nineties when I was a Technical Product Manager for Windows software at a distributor I was among other things responsible for solving the problems we had in many American Windows-applications with our swedish characters ÅÄÖ and åäö both in the applications and in Windows printerdrivers that we had to rewrite to be able to print those characters.

Especially communication emulators and replication software for IBM mainframe and minicomputers like the IBM AS-400 / I-series platforms were a big problems. In a software called Crosstalk we found it worked with three incompatible character sets which created a real hell a few years. We got IBM EBCDIC from the minicomputer on the screen, the clipboard of some reason used ASCII and when we write in the emulator it used Windows ANSI.

Later I set up a Data Warehouse that got delayed more than 6 months because IBM and Vision Solutions struggled to solve our character problems too in their software Symbiator. I got a lot of shit for that personally because I trusted IBM.

There was a joke in the Swedish IT-industry where people said the biggest employer in the industry was ÅÄÖ. A few years the whole industry had these problems and they was the main reason WordPerfect lost it totally since their first Windows-version didn’t use Windows printer drivers but their old MS-DOS-drivers that was not compatible with Windows character set for Sweden.

In theory I support Joannas suggestion using numbers insted of the English or the local words for the different colors but it is too late for that now. It is the english for the different colors that is the standard and that works.

14

Lightroom created this file for PhotoLab Default label names:
PhotoLab Default.lrtemplate.zip (797 Bytes)

Add the file to where it needs to go (…/Lightroom/Label Sets/) and edit its name if you want it to be different from what I used. Please remember that LrC handles 5 different labels only.

15

I know AS/400 and IBM i very well. It’s still a going concern and my job revolves around it. I think IBM have a good handle on internationalisation, but few software vendors do.

These days, Unicode at least makes it possible to allow for most languages, but software vendors don’t seem to understand it either. Add in loosely defined conventions such as colour labels and it is mess.

16

Way back when PhotoLab didn’t handle keywords, I wrote my own Mac app to handle adding keywords, along with Finder Tags, star ratings and descriptions.

In fact, Mac users have always been able to use Finder Tags, which can either be a word, a coloured dot or a combination of the two…

Capture d’écran 2025-01-04 à 11.05.23
Capture d’écran 2025-01-04 à 11.05.232556×994 121 KB

Tags are stored as a structure in files, by the OS, and can be searched for in Finder. The colour part of the tag is an enumeration of eight cases…

   static var allCases: [FinderTag]
  {
    return [.aucun, .gris, .vert, .violet, .bleu, .jaune, .rouge, .orange]
  }

Here, in my code, my internal “names” are in French, but these are mapped to whatever region the OS is running in.

From my app…

Capture d’écran 2025-01-04 à 11.03.52
Capture d’écran 2025-01-04 à 11.03.52770×1140 175 KB

… you can see the basic colours, tags that are only words and tags that are combined with a colour.

The eight colour names are only ever shown in the “native language” but tags with the same colour can have different names.

Here is a search in Finder, which includes both the Rouge colour tag and a combined tag, which adds in any files that contain a red dot with the name “red”…

Capture d’écran 2025-01-04 à 11.24.15
Capture d’écran 2025-01-04 à 11.24.152244×1424 164 KB

… and here is the same search in my app, with the Jaune colour tag as well…

Capture d’écran 2025-01-04 à 11.28.31
Capture d’écran 2025-01-04 à 11.28.311762×1756 145 KB

In fact, by using Finder Tags, you don’t even need separate keywords, as these can be replaced by text-only tags.

Obviously, Windows doesn’t have this system of tags and so, none of the currently available DAMs, that run on Windows, can use this ready-made Mac facility and have taken to hijacking an EXIF tag that was never meant to be used purely for colour names.

Unfortunately, this is not a problem that can be solved by DxO alone as it is going to take changing metadata specifications for EXIF data as a standard, followed by software authors then adopting that standard.

1 Like
17

Talking about DAM-workflows:

When I worked in Stockholm (more than 10 years ago) it was said to have around 35 000 computers in its network. Officially the City had standardized on Windows (Windows XP at that time) but there were exceptions on the museum I worked because the people working at the museums photo department had got a doubtful dispensation from that rule… and there were also at least three of the photographers that actually used Windows and Camera Raw and Photoshop for Windows.

For a while it worked, because they lived in their own little bubble but when we built the Digital City Museum using the FotoWare DAM (Norwegian spelling :-)) we suddenly got aware of the fact that MAC OS of those years had a character set that was different from Windows ANSI. So, it happened from time to time that some MAC “garbage characters” got the whole flow in the DAM to freeze until someone deleted those characters manually. As long the MAC-users stuck to the characters of our alphabet it worked. Mostly I think those characters we had problems with got into the flow by archivists cutting and pasting text they had found in some Internet sources. So, I agree with @zkatj that Unicode has been a blessing solving a lot of these problems.

18

When I once tried to get Photolab, Photomechanic and XnView to communicate with even the labels I managed to get it to work with the colors I use but it was impossible to get it all right with XnView’s None+9 colors colors i remember, Since Photolab has None+seven colors. Still, that was fine for my needs. It is no problem though to get Photolab and PhotoMechanic match perfectly but in PM they use something called Color Class that seems to be a separate set since it is an active choice to synchronize it with IPTC and XMP. The interface as it looks in PM below:

image
image1128Ă—397 14 KB