After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 310499 - GIMP (libexif?) corrupts manufacturer EXIF data from Nikon D70
GIMP (libexif?) corrupts manufacturer EXIF data from Nikon D70
Status: RESOLVED NOTGNOME
Product: GIMP
Classification: Other
Component: Plugins
2.2.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2005-07-15 14:13 UTC by Ari Pollak
Modified: 2008-01-15 12:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
original test image with manufacturer EXIF data (174.39 KB, image/jpeg)
2005-07-15 14:13 UTC, Ari Pollak
Details

Description Ari Pollak 2005-07-15 14:13:29 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...)
Comment 1 Ari Pollak 2005-07-15 14:13:58 UTC
Created attachment 49232 [details]
original test image with manufacturer EXIF data
Comment 2 weskaggs 2005-07-15 17:09:35 UTC
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.
Comment 3 Ari Pollak 2005-07-15 18:18:28 UTC
Same version of libexif, 0.6.9.
Comment 4 Markku Ekblom 2005-07-15 20:37:33 UTC
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...
Comment 5 Manish Singh 2005-07-15 21:34:16 UTC
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....
Comment 6 weskaggs 2005-07-18 15:34:49 UTC
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).
Comment 7 Michael Schumacher 2005-07-18 16:16:06 UTC
Debian Sid is now at libexif 0.6.12, btw. Already got an update, maybe someone
discovered the problems we had in bug 300186 :)