Identify EXIF orientation wrong when EXIF thumbnail exists

[jggretton]

Hi, I think I've found a bug with "identify"

I've noticed that for images without EXIF orientation information on the main image, but with EXIF orientation on the embeded thumbnail, "identify" picks up the thumbnail's orientation and returns it as if it was the orientation for the main image.

I've tested this on ImageMagick 6.7.9-7 2012-09-24 Q16 http on linux and ImageMagick 6.7.5-0 2012-01-26 Q16 http on windows.

I haven't got a non-copyrighted image to show as an example of this, and can't reproduce a problem image myself, but I have included some output from Identify and from PHP's read_exif_data() as comparison below.

If anyone can replicate this and/or has any suggestions to get identify to give the correct results I'd be very grateful.

Thanks,

James

Output from Identify

Code: Select all

    [Image] => 57586.jpg
    [Format] => JPEG (Joint Photographic Experts Group JFIF format)
    [Class] => DirectClass
    [Geometry] => 2736x3648+0+0
    ....
    [Compression] => JPEG
    [Quality] => 99
    [Orientation] => RightTop
    ....

Output from read_exif_data

Code: Select all

    [FileName] => 57586.jpg
    [FileDateTime] => 1348494016
    [FileSize] => 3875894
    [FileType] => 2
    [MimeType] => image/jpeg
    [SectionsFound] => ANY_TAG, IFD0, THUMBNAIL, EXIF, MAKERNOTE
    ....
    [THUMBNAIL] => Array
        (
            [Compression] => 6
            [Orientation] => 6
            [XResolution] => 72/1
            [YResolution] => 72/1
            [ResolutionUnit] => 2
            [JPEGInterchangeFormat] => 3950
            [JPEGInterchangeFormatLength] => 5669
            [YCbCrPositioning] => 2
        )
     ......
     (no other orientation information)

[Jason S]

Possible test case here. I found an image whose thumbnail contains an orientation tag, and modified the tag (but not the thumbnail image) to be top-right. I agree that it looks like a bug, and it's probably not limited to the orientation.

[jggretton]

Hi Jason, thanks for the example image. Good to know it's not just me! Hopefully this is something that the ImageMagick team can fix in a future release.

Team IM: I do feel for you guys, it must be a nightmare trying to keep up with the crazy EXIF data that the camera manufacturers love to include, but I really appreciate your hard work and have a lot of respect for ImageMagick. Thanks a million

[Jason S]

I reviewed the Exif spec with respect to JPEG files, and it confirms that there can be no more than two IFDs in the primary IFD list, and the second one is only used for a thumbnail. So maybe there's never any reason to look at the "next IFD" pointers at all. If so, this could easily be fixed, by deleting the code that does that.

In magick/property.c, about line 1484, delete:

Code: Select all

                if ((offset != 0) && ((size_t) offset < length) &&
                    (level < (MaxDirectoryStack-2)))
                  {
                    directory_stack[level].directory=exif+offset;
                    directory_stack[level].entry=0;
                    directory_stack[level].offset=tag_offset1;
                    level++;
                  }

But I'm not 100% sure that the rules are the same for all image formats, or that IFDs that aren't in the primary list can never have "next IFD" pointers, or that ImageMagick never cares about thumbnails.

I notice that this code is only executed for IFDs that contain an EXIFIFD, INTEROPERABILITYIFD, or GPSIFD tag. That seems odd to me, though maybe there's a reason for it. I found a JPEG/Exif file that contains none of those tags -- it doesn't contain a thumbnail, either, but 'identify' wouldn't have looked for it if it did.