GNOME Bugzilla – Bug 656515
F-spot corrupting jpg exif data
Last modified: 2018-07-01 08:54:09 UTC
Fedora 14, X86_64 F-spot 0.8.2 Jpeg images taken from camera and appear OK. F-spot configured to store metadata with the image files. After updating images with tags, jhead puts out an error: "Illegally sized Exif makernote subdir (6912 entries)". Did another test: - Tested image from camera, jhead reporting no issues. - Started F-spot - Copied over the corrupted image file with pristine file from camera - updated the tags for that file in f-spot, causing f-spot to update image exif information -> result jhead stating: "Illegally sized Exif makernote subdir (6912 entries)"
Example of broken file. Only thing done to the file is that it has been imported to f-spot. http://6q7caj.1fichier.com/en/IMG_9996_broken.JPG The same file prior to import: http://tf3xg6.1fichier.com/en/IMG_9996.JPG
Did side by side comparison of same image prior and after f-spot import. comparing output from exiftool. here are the differing tags: Exif Byte Order : Big-endian (Motorola, MM) User Def 1 Picture Style : Standard User Def 2 Picture Style : Standard User Def 3 Picture Style : Standard Time Stamp : 2011:06:18 19:22:59 Shutter Count : 1 Internal Serial Number : E688939 Measured RGGB Data : 42725 66251 66929 43601 ========================================================= Exif Byte Order : Little-endian (Intel, II) User Def 1 Picture Style : Unknown (0x8100) User Def 2 Picture Style : Unknown (33024) User Def 3 Picture Style : Unknown (33024) Time Stamp : 1980:08:16 13:40:29 Internal Serial Number : <BD>.��� Measured RGGB Data : 2800025600 46858241 91291649 2857435136 Software : f-spot version 0.8.2 ========================================================== Seems that f-spot messes up the timestamps etc. To me looks like a bug with big endian vs little endian. At least when comparing measured RGGB data (converted values to HEX): Original: 1st)0000 A6E5 2nd)0001 02CB 3rd)0001 0571 4th)0000 AA51 F-Spot: 1st)A6E5 0000 2nd)02CB 0001 3rd)0571 0001 4th)AA51 0000
Oops, in my previous comment, there is one mistake. After being processed by F-Spot, exiftool reports the byte order as big endian. (Opposite of what I wrote)
f-spot is not under active development anymore, has not seen code changes for five years, and saw its last tarball release in the year 2010. Its codebase has been archived: https://gitlab.gnome.org/Archive/f-spot/commits/master Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.