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:
- 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". - I turned on Darktable’s option to look for updated xmp files on startup, but that didn’t seem to solve the problem.
- 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. - 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.
- 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.
- 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
I don’t think this is a darktable bug. Last month i was fixing a rating tag bug, so i read thru most of the code that handles the xmp.
Can you go back thru your steps again? Start at the top, image is in SD card.
Hi g-man,
Not sure how to explain it, but now it seems to work, even when I choose to write sidecar file ‘on import’. From then on, however, all changes to ratings must be made from within Darktable. Once sidecar file was created Darktable did not detect changes in ratings that were made in Bridge, even after re-importing. In preferences, ‘Look for updated xmp files on startup’ is checked. So, my choice is now to write the sidecar file ‘after edit’.
On a second thought, perhaps all this had something to do with behaviour not of the software but of the HD itself, such as sleeping.
Here are my workflow steps:
- From within Bridge, I download images from SD card and convert the native raw camera formats (Canon, Sony) to .dng files which are then stored on hard disk in a folder structure created in Bridge’s Photo Downloader page (Year/Year-Month).
- In Bridge, I add metadata to and rate (1 star) photos I wish to work on in Darktable.
- I open Darktable, and from import → add to library I choose the folder on the HD with the photos I wish to process. Unfortunately, I haven’t found a way to import only those photos I rated back in Bridge (have an idea how to do that? It would be a nice feature). Instead, I create a collection based on rating.
- From there I move to Darkroom for processing the files in the collection.
Thanks for taking the time to look into this.
That is perfectly normal: dt uses a different naming scheme for its sidecar files, and reads the Bridge sidecar when there’s no dt sidecar yet. dt also will not write to the Bridge sidecar. That is done to help migration, the aim isn’t/wasn’t to have both used together (keep in mind that at the time this was implemented, dt was not available for windows). So that part works just as described in the manual section linked above
While that works, it’s not the best way to treat raw files: .DNGs don’t always conserve all the information from the original raw files, and dt is quite able to handle canon and sony raw files (except for the newest formats, perhaps). So in most cases, converting to DNG doesn’t have any advantages (archiving them is going to be just as much a headache as with any other digital format, the hardware is probably obsolete before the software)
And DNG is not an open standard format, but still owned by Adobe. So in that respect, while better documented, it isn’t better than the camera raw formats (they still have to deal with the undocumented “maker note” sections in the raw files).
Of course, DNG files from cameras that produce them natively are not a problem, they work just like any other native format (CR2, ARW, ORF, …)
Good advice. The only reason I converted the files to DNG was that one of them might find its way into Photoshop. But it’s quite rare.