Legacy ImageMagick Discussions Archive

Hello there,

I believe I've found a bug specifically with an EXIF 7 oriented jpg image. Everything should be here to easily reproduce. Hope someone is able to try and reproduce it soon.

ImageMagick version: ImageMagick 6.7.7-6 2013-03-06 Q16
OS: OSX 10.6.8 (Snow Leopard)

Steps to reproduce:
1. Start with this EXIF 7 oriented jpg image http://cl.ly/image/0I3b2v2k3l46
2. Run this command: Expected: 240x240px image with the text "RIGHT MIRRORED" roughly centered in the image.
Actual: 160x200px image with the text towards the top of the image and the rightmost text is cropped http://cl.ly/image/0q0w2p2k1l1P

I get the same results as you in IM 6.8.7.0 Q16 Mac OSX from your command with proper IM 6 syntax (read input image first)

convert exif7.jpg -auto-orient -crop 240x240+0+40 oriented_cropped_exif7.jpg

BUT, if you add +repage it works fine

convert exif7.jpg -auto-orient +repage -crop 240x240+0+40 oriented_cropped_exif7.jpg

I also get the same results.

"+repage" is required because of the canvas settings that "-auto-orient" makes.
Without "+repage, this messes up the "-crop".

Thanks fmw42 and snibgo for testing and letting me know that the +repage option makes this work.

What's odd is that my original command applied to the other EXIF orientation image examples (1-6, 8) works as I'd expect with no problem. Here's a link to the image files I'm using for testing: https://github.com/component/exif-rotat ... ter/images

Would either of you have an idea why the other 7 images worked fine and this one didn't? Why did it's virtual canvas get in the state it did but not the others?

convert 1.JPG -auto-orient info:
1.JPG JPEG 240x320 240x320+0+0 8-bit PseudoClass 256c 1.21KB 0.000u 0:00.009
convert 2.jpg -auto-orient info:
2.jpg JPEG 240x320 240x320+0+0 8-bit PseudoClass 256c 0.000u 0:00.000
convert 3.JPG -auto-orient info:
3.JPG JPEG 240x320 240x320+0+0 8-bit PseudoClass 256c 0.000u 0:00.000
convert 4.jpg -auto-orient info:
4.jpg JPEG 240x320 240x320+0+0 8-bit PseudoClass 256c 0.000u 0:00.000
convert 5.jpg -auto-orient info:
5.jpg JPEG 240x320 320x240+0+0 8-bit PseudoClass 256c 0.000u 0:00.000
convert 6.JPG -auto-orient info:
6.JPG JPEG 240x320 240x320+0+0 8-bit PseudoClass 256c 0.000u 0:00.000
convert 7.jpg -auto-orient info:
7.jpg JPEG 240x320 320x240+80-80 8-bit PseudoClass 256c 0.000u 0:00.009
convert 8.JPG -auto-orient info:
8.JPG JPEG 240x320 240x320+0+0 8-bit PseudoClass 256c 0.000u 0:00.000

I see nothing obvious in the verbose info: for 7.jpg or using EXIFTOOL. It would appear to me that there is some kind of bug in -auto-orient for Orientation: RightBottom that is adding the canvas offset of +80-80. Since JPG does not support virtual canvas offsets, it would thus imply that it is a bug in auto-orient.

Can you generate more images of different sizes with the same orientation and see if they fail also and have some non-zero virtual offset?

The string formats also show the same offset

convert 7.jpg -auto-orient -format "%P %O\n" info:
320x240 +80-80


PS I looked at the autoOrientImage code and it is very simple just calling transverse image for orientation 7 (rightbottom). Nothing is obvious. But there are some differences between transverseImage and transposeImage. But I do not read code that well to know if there is a problem in transverseImage.

I note that "-transverse" creates a predictable offset, eg:

I get the same bad results in IM 6.8.7.0 Mac OSX for -transverse but not -transpose. So it does look like a bug in -transverse.

convert -size 301x20 xc: -transverse info:
xc: XC 20x301 301x20+281-281 16-bit sRGB 0.000u 0:00.000

convert -size 301x20 xc: -transpose info:
xc: XC 20x301 301x20+0+0 16-bit sRGB 0.000u 0:00.000

Ah I see. Looking at the commit activity for TraverseImage it has had several incremental changes, all made by cristy and a bug fix from anthony.