-
Notifications
You must be signed in to change notification settings - Fork 1.3k
exif: implement reading user-defined EXIF tags from files #19656
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
exif: implement reading user-defined EXIF tags from files #19656
Conversation
|
I am currently busy with the gtk4 migration, so great you have a look here. |
4b95f8e to
a0af003
Compare
|
Figured it out! The xmp read was called with exif_read == FALSE, leading to a dt_metadata_clear call. I fixed that in a manner which hopefully makes sense. EDIT: I'm not exactly sure in which case the exif_read == FALSE code path should be triggered except on image import, so I don't know how to test that I didn't break anything... I tried to look through the usages of the various functions, but I seem to circle back to imports always. |
Let's say I modify the exif information using a script (which I do sometimes) and I get it all screwed up. I can force the metadata to be reread, which cleans up my mess and sets the metadata in the database to agree with the metadata in the image. |
|
@wpferguson As far as I can tell, that doesn't trigger an xmp read with exif_read == FALSE, but calls (assuming you mean the "refresh EXIF" button) |
|
Wont build gcc 12.3.0 |
|
Hmmm… I can't see from the code what's wrong and it builds for me … Unfortunately, I'm mostly AFK until Monday, so I probably won't be able to look into it before that. |
The metadata customization dialogue does offer Exif.* tags, but they were not actually read from EXIF. This commit fixes that behaviour.
Through the call chain dt_image_import -> _image_import_internal -> dt_exif_xmp_read -> _exif_decode_xmp_data, the function _exif_decode_xmp_data would be called with exif_read == FALSE, causing it to delete all metadata which has previously been read in _exif_decode_exif_data (see the parent commit). The intent was likely to be able to update descriptions etc. which had been written through other programs in the Xmp files in darktable. In order to continue to support this use case, we do still remove Xmp-related tags if we don't find them in the sidecar, but only those (via a string match).
a0af003 to
bfdae9d
Compare
|
@wpferguson found it, fixed! |
This is a follow-up from #19622, where @zisoft pointed out that there's a mechanism to read custom EXIF tags into darktable's database for filtering and such. That didn't work, so I cobbled together this patch.
This does not fully work yet. For some reason, on first import of an image, the metadata is not set. I have to reread the EXIF data manually via the UI in order for it to appear. Any ideas why that might be welcome.