GNOME Bugzilla – Bug 792239
Add ApertureValue fallback to gexiv2_metadata_get_fnumber
Last modified: 2018-01-05 12:48:33 UTC
While working on a gexiv2-based Tracker extractor (bug 787589), I learnt about the Exif.Photo.ApertureValue tag. It seems to me that libexif's EXIF_TAG_FNUMBER implicitly falls back to Exif.Photo.ApertureValue if Exif.Photo.FNumber is missing. I had a file from which I had removed the latter, but not the former, and Tracker's JPEG extractor was still showing an f-number. The Tracker extractor doesn't have any fallback, so I can only assume that libexif is doing something. However, I have not read libexif's code, nor have I come across "real" files in the wild where not having a fallback can be a problem. Regardless, this seems like a reasonable thing to do, and as an added bonus the (g)exiv2 based RAW extractor would behave like the libexif based JPEG/PNG/etc. extractors. More on Exif.Photo.ApertureValue: https://photo.stackexchange.com/questions/19143/how-can-the-aperture-value-written-in-exif-be-larger-than-the-nominal-limit-of-t https://en.wikipedia.org/wiki/APEX_system
Created attachment 366373 [details] Test case used to play with ApertureValue
Created attachment 366374 [details] [review] metadata: Fallback to ApertureValue if FNumber is absent or invalid
"exiv2 pr -p s /path/to/file" also falls back to ApertureValue if FNumber is missing.
Attachment 366374 [details] pushed as 80174b3 - metadata: Fallback to ApertureValue if FNumber is absent or invalid
Pushed with minor fix (missing include) and an added testcase
(In reply to Jens Georg from comment #5) > Pushed with minor fix (missing include) and an added testcase Sorry, I attached it too soon, and you got to it before I could re-attach a fixed version. Thanks for fixing it up.