1
votes

I am having issues with -auto-orient not working - specifically with iPhone images, but likely with others. I'm working currently with a client who uploaded an image, we process it and store it in our cloud storage.

Using the PHP exif_read_data comand, I see (removing excess stuff):

[FileSize] => 43228
[FileType] => 2
[MimeType] => image/jpeg
[Make] => Apple
[Model] => iPhone 7 Plus
[Orientation] => 6
[ExifVersion] => 0221

Then I use Imagick to check the image orientation:

$testimage = new IMagick();
$testimage->readImage($original_file);
$image_orientation = $testimage->getImageOrientation();
print "Orientation: $image_orientation\n";

This results in: Orientation: 6

I then do my resizing, and use auto-orient on the image (with PHP exec() ):

/usr/bin/convert -auto-orient /tmp/phpi1E33B -resize 640x480 /tmp/AR7020014-1567534336-lp_01_original_1567534336.jpg

And check the orientation of the result:

$testimage->readImage($new_output_filename);
$image_orientation = $testimage->getImageOrientation();
print "After convert, orientation\n";

Results in: After convert, orientation: 1

But the problem is that the image is still sideways when I look at the file. So auto-orient is flipping whatever value IMagick::getImageOrientation looks at, but doesn't seem to be actually changing the image?

Note: I run convert locally on the command line, and get the same results.

The ImageMagick version on my server is: convert --version Version: ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC Features: DPC Modules OpenMP Delegates: bzlib djvu fftw fontconfig freetype jbig jng jpeg lcms lqr ltdl lzma openexr pangocairo png tiff wmf x xml zlib

Locally, the version is: convert --version Version: ImageMagick 6.9.9-40 Q16 x86_64 2019-08-30 http://www.imagemagick.org Copyright: © 1999-2018 ImageMagick Studio LLC License: http://www.imagemagick.org/script/license.php Features: Cipher DPC Modules Delegates (built-in): bzlib djvu fftw fontconfig freetype gslib jbig jng jp2 jpeg lcms ltdl lzma openexr png ps raw tiff webp x xml zlib

NOTE: If I calculate a specific orientation value (i.e., '-rotate -90'), AND use -auto-orient, it seems to work correctly.

1
This is bringing back memories. Think we found EXIF orientation data was useless and starting stripping all that out. This might be worth a read: daveperrett.com/articles/2012/07/28/… - ficuscr
Post an example image. Note that some viewers do not utilize the auto-orient flag and so will display the image wrong. - fmw42
Hmm.. "some viewers" seems to include Facebook. That's why the problem came out at all - a share from our customer's site to FB had her house upside down, though it looked fine on our site. I have used the "auto-orient + explicit orientation" option, and it seems to work for my test cases. - Andy Wallace
Not sure how to post an example image, but here's a link to one: storage.cloud.google.com/idx-photos-gs.ihouseprd.com/MI-LANSING/… - Andy Wallace
I got your image and find the same results. I have reported this on the ImageMagick web site. However, I am suspicious that your image was photographed correctly oriented, but was tagged with the wrong orientation flag. Therefore, it is auto-oriented by the flag by 180 deg and thus shows up wrongly rotated, because the flag is in error. I will report back here once I get confirmation. - fmw42

1 Answers

0
votes

Ok, so there are multiple "answers" here. Thanks to fmw42, I'm pretty sure that the image was correctly oriented, but the EXIF:orientation value was not correct. In addition, I have found that:

  • -auto-orient by itself didn't do anything visible, but set the EXIF value
  • -rotate rotated the image, but didn't set the EXIF value
  • using both together both rotated the image and set the EXIF value

My tests show this working ok, so now to see what happens in the real world when users get ahold of this.