GNOME Bugzilla – Bug 310499
GIMP (libexif?) corrupts manufacturer EXIF data from Nikon D70
Last modified: 2008-01-15 12:57:59 UTC
From Debian bug report http://bugs.debian.org/318288: --------- This could be a bug in the EXIF library, but I don't know how to check that... Anyway, gimp messes up the EXIF headers for images taken with Nikon D70. Before doing anything for the (JPEG) image, the metacam program shows all the EXIF fields nicely. After doing some adjustments with gimp (shouldn't matter what kind of adjustments) and saving the file with the EXIF information, metacam says n times things like this to stderr: WARNING: Unknown field type 8519 WARNING: Unknown field type 16932 (The n is probably a four digit number...) Between and after those warnings metacam outputs part of the EXIF headers to stdout. Everything below the "Manufacturer Fields" is missing, which of course contains many important fields. This seems to be a problem with only this model (Nikon D70). I've tested the same things with Canon DIGITAL IXUS 430, and that's working fine. Could also be a problem with all Nikon DSLR's, but I only have D70 to test this with. ============================================= > Can you attach a sample original image (smaller than, say, 200KB) to this > bug report that shows this behavior? Shooting almost totally black at the lowest resolution with the highest compression with this camera just gets a image that fits in that limit. I never really shoot in this mode, but it revealed either another bug, or a new feature of this bug. Metacam shows the EXIF fields correctly again for the original image. After opening the image in gimp and doing nothing but saving it with a new name (with JPEG saving options Optimize, Force baseline JPEG, Save EXIF data and Save thumbnail marked) it messes up also the fields above the manufacturer fields. Here's what metacam prints to stdout after doing the above with the attached image: ----8<---- File: Debian_bug_318288-g.jpg Standard Fields ----------------------------------- Image Creation Date: 2005:07:15 00:09:51 Make: NIKON CORPORATION Model: NIKON D70 Software Version: Ver.2.00 X Resolution: 300 Pixels/Inch Y Resolution: 300 Pixels/Inch YCbCr Positioning: Datum Point EXIF Fields --------------------------------------- Sub-Second Creation Time: Ver Image Capture Date: Ver Sub-Second Capture Time: Ver Image Digitized Date: Ver Sub-Second Digitized Time: Ver Exposure Bias: nan EV Focal Length: nanmm Exposure Time: 0 Sec. Aperture: fnan Exif Image Width: 0 pixels Exif Image Height: 0 pixels Exposure Program: Not Defined Exposure Mode: Auto Exposure White Balance: Auto White Balance Metering Mode: Unknown EXIF Version: FlashPix Version: Light Source/White Balance: Automatic Flash: Flash Not Fired; Sensing Method: Unknown (0) Compressed Bits Per Pixel: Infinity Max Aperture Value: fnan ColorSpace: Unknown (0) Component Configuration: Unknown(<80>)Unknown(Þ)Unknown(ç)Unknown(·) Digital Zoom Ratio: None 35mm Focal Length: Unknown Scene Capture Type: Standard Gain Control: None Contrast: Normal Saturation: Normal Sharpness: Normal Subject Distance Range: Unknown Manufacturer Fields ------------------------------- ----8<---- (BTW, the n for the "WARNING: Unknown field type x" for this image saved with gimp was a five digit number. 20287 to be exact. With the higher resolution image it was 20288. A notable difference is that the lower resolution image had 7692 "WARNING: Unknown field type 0" errors vs. the 9 in the higher resolution image... Don't know if this is important at all, but hopefully it could give some pointers finding the cause of this bug...) With a higher resolution and not so heavy compression these fields seem to be ok in metacam even after saving them thru gimp. But even with the lower resolution image the manufacturer fields are missing... > Also, does modifying the original image with ImageMagick's convert utility > also mess up the EXIF data? No. Doing for example 'convert -negate Debian_bug_318288.jpg Debian_bug_318288-i.jpg' keeps all the EXIF data. But does ImageMagick even use the same EXIF library? > If you use a different program to read EXIF data after modifying the image, > does it show the same problem? Metacam has the best support for different vendor-specific extensions to the EXIF standard that I'm aware, but testing with 'exif' it does show fields that metacam failed to show in the above situation with the lower resolution image. But it doesn't seem to know how to show the manufacturer fields at all... (Not even from the original attached image.) This is the diff when 'exif' is used first on the original attached image, and then to the one saved with gimp: ----8<---- 1c1 < EXIF tags in 'Debian_bug_318288.jpg' ('Motorola' byte order): --- > EXIF tags in 'Debian_bug_318288-g.jpg' ('Motorola' byte order): 33c33 < Maker Note |22856 bytes unknown data --- > Maker Note |10 bytes unknown data 60c60 < EXIF data contains a thumbnail (7499 bytes). --- > EXIF data contains a thumbnail (2024 bytes). ----8<---- I believe that the "Maker Note" contains the manufacturer fields, so those fields are still lost after saving the image with gimp. (Note that the Ixus 430 also has manufacturer fields, but those fields are untouched after saving the image with gimp. But then again, it has another manufacturer...)
Created attachment 49232 [details] original test image with manufacturer EXIF data
I don't have any problems with the exif in this file using cvs HEAD and libexif 0.6.9. I think we really need to know the version of libexif that is involved here.
Same version of libexif, 0.6.9.
A note from the maker of the Debian bug report: Debian Sarge has version 2.2.6 of Gimp, not 2.2.8 as stated in the top right box...
This is reproducible with debian's libexif, but not libexif 0.6.12. So this seems like a libexif problem, and not gimp's. Careful of blindly upgrading to libexif 0.6.12 though, since there's other bugs in that version. Maybe pulling from CVS HEAD would be better....
The diff above suggests that the problem comes specifically in the handling of Maker Notes, and comment #2 suggests that it involves something that Debian modified in libexif (the libexif I tested was built from tarball).
Debian Sid is now at libexif 0.6.12, btw. Already got an update, maybe someone discovered the problems we had in bug 300186 :)