Darktable 3.8.1 will not read star-ratings created in Adobe Bridge 2022

I’m used to and like Adobe Bridge. However, the star rating in Bridge will not import into Darktable (nor will Labels) . Is there a way to make them compatible so ratings or labels made in Bridge will be available to Darktable when importing?
If not, is there another way to mark or flag photos in Bridge that Darktable might be able to import?
Thanks.

Are you trying to alter ratings from images already in darktable? You need darktable’s option to look for updated xmp files on startup. That should work, assuming Bridge writes the standard ratings tag.

Labels are not standard and thus are not interchangeable.

In bridge, are you writing the xmp or dng with your edits?

darktable should read the xmp information if one is available. darktable will not read any bridge/Lightroom catalog/database.

@egerda Welcome to the forum! Giving us a sample file would help. :wink:

Hi g-man, I do not edit in Bridge, just organize, write metadata and rate those I wish to edit in Darktable. I’m just using Adobe built-in star rating. I assume it writes to the XMP but perhaps it doesn’t.
I need a system for importing into Darktable only those files I wish to edit. I tried rating both RAW and JPG files, and for some reason the ratings do not show in Darktable.

Hi paperdigits,
Thanks for the reply. I’m rating the photos in Bridge and I want to import into Darktable for editing only those I rated. In Darktable those ratings do not show up.

Disclaimer : I never used Adobe Bridge but :
if you are not sure what is exported, you should have a look into the xmp first. xmp files are text files and can be viewed and edited by every text editor application. In the xmp file you should find something like

xmp:Rating="1"

or similar. But as already said, differrent applications can handle ratings in different manner. Perhaps you can upload an Adobe xmp so others can have a look at the file. Trying to give you a well proofed answer is like “poking in the fog” if one is not knowing the content of your xmp

.

First thing would be to check if the xmp files are created and written, and if not, enable that…
Such xmp files would have the same base name as the corresponding raw file, and be in the same directory.

it should work because it writes xmp files Learn about Extensible Metadata Platform (XMP) standard and working with metadata in Adobe Bridge but of course if it’s not using the same field/type as darktable it won’t. doesn’t work for me in windows 11 marking a file as 3 stars in bridge, closing bridge, opening darktable with look for updated xmp files checked

As said, post an xmp in that case, perhaps there is something that can be done. But for that, we need to know how the rating is stored in the xmp…

Repeating “It should work” and “xmps should be written” don’t really help in advancing towards a solution.

1 Like

i stated that because OP said “I assume it writes to the XMP but perhaps it doesn’t.” and used that as a basis to suggest the reason it isn’t working is because darktable uses a different label or value, but i can just the fuck up if it’s not helping.

You also said

without posting any more precise information.

If you have such an xmp, it’s easy to check what’s in them (they are plain text files after all). So you could have posted (an exerpt from) one of your xmps showing the problem.

i thought OP would post their xmp, but sure, i can do mine (xmp from bridge, rating set to 3 stars)
P8016308.xmp (7.1 KB)

on line 74
<xmp:Rating>3</xmp:Rating>
i was going to upload the xmp from darktable but it doesn’t seem to be the most recent time stamp i changed the rating to 5 stars in dt. opened it for editing and changed a couple of module values then closed dt. refreshed the xmp file in explorer but still 1.5 hours ago. Maybe OP could upload their xmps so
P8016308–dt.xmp (3.4 KB)
looking at the next file in the series, dt writes the rating as
xmp:Rating=“1”
so assume the different syntax is repsonsible for the incompatibility?
P8016309.ORF.xmp (13.4 KB)

Thank you all for the valuable input. Here are some points:

  1. Bridge writes the rating into the photo itself, Darktable creates upon import a sidecar with the XMP data. Although I rated the photo in Bridge, the XMP sidecar Darktable produced showed xmp:Rating="0".
  2. I turned on Darktable’s option to look for updated xmp files on startup, but that didn’t seem to solve the problem.
  3. Finally, in an effort to make sure Bridge is writing the rating to XMP I used exiftool. This tool, showed that Bridge indeed wrote the rating into XMP (xmp:Rating="1"), so this pointed the problem back at Darktable.
  4. Surprisingly, after using the exiftool (only to extract information), and also changing Darktable Storage options to write XMP sidecar files only after edit, Darktable began to show the star ratings.
  5. My guess is, it takes some time for Darktable to read some of the XMP metadata. If Darktable is set to write sidecar XMP files upon import, it does so before it had the chance to actually read the star rating. Once that sidecar file is written, Darktable will read the XMP info from that file alone.
  6. So, in the case of a workflow that includes importing from Bridge, set the Darktable Storage option to write to XMP after edits and not upon import. I would also allow a bit of time after I rate in Bridge and before I import into Darktable.

Thanks again.

1 Like

Interesting. I will look up those syntax differences. By the way, how do you export the xmp data from Bridge into a file?

right click on the file and choose file info, then at the bottom choose export and select where to save the xmp

Cool. Thanks

@David_Prescott Thank you, that should help.

Indeed, darktable writes the rating as an attribute of the <rdf:Description> tag, bridge writes it as an individual sub-tag of the <rdf:Description> tag. Both are valid xml, and the choice isn’t always clear-cut (in this case, there can only be one rating, so an attribute makes sense).

Not sure if this is worth a bug report/feature request?

If that’s what happens, that might actually be considered a bug: dt should see (and read) the sidecar from bridge, and use all the information it understands from it (not necessarily all information, though).
See the sidecar section in the manual although that refers to Lightroom only.
(Let’s not restart a discussion about "standard file names for sidecars, please)

1 Like

Never filed a bug report. Can we just point them to this thread, or this must be reformulated separately?

It should be filed separately (it’s a system that allows the developers to keep track of all issues with dt), but you could wait to see if one of the devs has something to say about it here, e.g. what the exact bug would be (I can see two possibilities).

In any case, if you file a bug report, just tell what you see, with full details (versions of dt and windows, files you tested, possibly a copy of the sidecar file.) You can hardly get too detailed, but don’t include guesses; the devs are in a much better position to speculate about possible causes, as they work with the code.

1 Like