#400 Exif orientation unknown for some JPEG files

[Matthias Kiefer]

For the attached jpeg file, graphicsmagick reports an unknown orientation.
However, other software like exiftool can correctly extract the orientation.

The image has been taken with LG G3 with Android V5.0 and the default installed LG Camera App. The problem happens with every image taken with this phone.

> gm identify  -format %[EXIF:Orientation] 20160921_155817.jpg.jpeg
unknown
> exiftool -a -n -G1 -Orientation 20160921_155817.jpg.jpeg
[IFD0]          Orientation                     : 6
[IFD1]          Orientation                     : 6

> gm -version
GraphicsMagick 1.3.25 2016-09-05 Q16 http://www.GraphicsMagick.org/
Copyright (C) 2002-2016 GraphicsMagick Group.
Additional copyrights and licenses apply to this software.
See http://www.GraphicsMagick.org/www/Copyright.html for details.

Feature Support:
  Native Thread Safe       yes
  Large Files (> 32 bit)   yes
  Large Memory (> 32 bit)  yes
  BZIP                     yes
  DPS                      no
  FlashPix                 no
  FreeType                 yes
  Ghostscript (Library)    no
  JBIG                     no
  JPEG-2000                no
  JPEG                     yes
  Little CMS               no
  Loadable Modules         yes
  OpenMP                   no
  PNG                      yes
  TIFF                     yes
  TRIO                     no
  UMEM                     no
  WebP                     no
  WMF                      no
  X11                      no
  XML                      yes
  ZLIB                     yes

Host type: x86_64-apple-darwin15.6.0

Configured using the command:
  ./configure  '--prefix=/usr/local/Cellar/graphicsmagick/1.3.25' '--disable-dependency-tracking' '--enable-shared' '--disable-static' '--with-modules' '--without-lzma' '--disable-openmp' '--with-quantum-depth=16' '--without-gslib' '--with-gs-font-dir=/usr/local/share/ghostscript/fonts' '--without-x' '--without-lcms2' 'CC=clang' 'CXX=clang++'

Final Build Parameters:
  CC       = clang
  CFLAGS   = -g -O2 -Wall -D_THREAD_SAFE
  CPPFLAGS = -I/usr/local/Cellar/freetype/2.6.5/include/freetype2 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/libxml2
  CXX      = clang++
  CXXFLAGS = -D_THREAD_SAFE
  LDFLAGS  = -L/usr/local/Cellar/freetype/2.6.5/lib -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/lib
  LIBS     = -lfreetype -lbz2 -lz -lltdl -lm -lpthread

[Matthias Kiefer]

Sorry, Sourceforge always gives me errors when trying to upload the image. I have created an html hexdump with exiftool. Please let me know, how I can send you the image

[Matthias Kiefer]

Trying to upload image as zip file

[Troy Patteson]

Hi,

I was just looking at the source code for attribute.c to see if I could add the ability to set the EXIF orientation when I noticed this post. The issue here is caused because of a bug in GenerateEXIFAttribute() when processing the GPS IFD within the EXIF profile. The flag gpsfound is set to MagickTrue but not cleared after looping through each of the tags within the GPS IFD. When gpsfound is set, only EXIF tag IDs between GPS_TAG_START and GPS_TAG_STOP are allowed and all other tags are ignored. Normally the EXIF IFD which houses the EXIF orientation tag occurs before the GPS IFD but in your example image the reverse is true. As a result, when the EXIF IFD is being processed, all of the EXIF tags which are not between GPS_TAG_START (0x01) and GPS_TAG_STOP (0x1D) are ignored including orientation (0x112).

The solution is to simply clear the gpsfound variable after finishing looping through the tags in the current IFD. See the trivial patch against the release version v1.3.25 attached. On another note, attribute.c uses both tabs and spaces for indents. It would be really nice if one or the other was used.

Cheers,
Troy

[Bob Friesenhahn]

Troy's patch has been applied and it appears to solve the problem. Thank you very much for this fix.

Regarding tabs in source files, this source file originated with mixed tabs and spaces. The project standard is to use only spaces. I will consider if the tabs should be stripped from all files, but this would create a very large diff which might make things difficult for people investigating other fixes.