Wrong orientation of images (Portrait/Landscape) after upload


#1

Hi,
I made some tests on uploadimng images (via Panel) and some of my uploaded portrait-images are rotated into landscape format.

For example, an image was taken with an iPhone 5 (in portrait). I transferred it to my computer and in Preview and Photoshop, it has these dimensions:

2448 x 3264 px

After uploading it to the Kirby Panel, it has the following Type / Size / Dimensions:

image / 2.63 mb / 3264 x 2448

So, it looses it’s original orientation and is rotated into landscaped format. Thus, calling it in my template, it has the wrong orientation aswell.

Is there any fix for this?

EDIT: I just tried uploading another landscape format and it is displayed in landscape, but upside-down.

SOLVED: Malvese provided the solution for this down there.


Auto orient - FTP - ImageMagick
#2

Some graphic editors mess up with the orientation in the EXIF information. That’s the most common source of problems with orientation. Some don’t read the EXIF, some do read it but don’t update it when the image is rotated.
I tried to import a photo from my 4S, but it’s too big (> 2 MB). Did you resize them first in a graphic editor?

FWIW, I resized + rotated an image from my iPhone in Photoshop and the orientation was correct in Kirby.


Auto rotate and remove EXIF
#3

Hi, the wrong orientation actually happens, when the image did not run through any editor. The orientation is messed up, uploading the image straight from my phone or (after sending it to my computer), straight from there.

If I open the image first in Photoshop and just save it or “save it for web…”, Kirby takes over the correct orientation. For the user of my website, it has to be possible, to upload images straight from phone/computer, without any editor.

Some additional information: For the images, I uploaded straight, I couldn’t read any exif()->data(), if I saved them first with Photoshop, I could read the exif-data. Also, the images with the wrong orientation, don’t create any thumbnails in the files-overview.


#4

I just uploaded a portrait image from my iPhone (6 Plus) via Air Drop, and while thumbs don’t get displayed, the orientation is correct and it gets displayed alright on the page as well (Kirby 2.1 beta). And the Exif information is right there as well.

[Edit] Thumb generation is limited to a max file size of 2048 x 2048, unless you use ImageMagick.

From the changelog (2.1 beta)

The file viewer comes with improved previews for transparent PNGs and SVGs as well as better handling for thumbnails of large images. GD lib can now created thumbnails for files up to a maximum of 2048 x 2048 pixels. If you switch the thumbnail driver to Imagemagick there’s no more limit for thumbnails.


#5

Okay, that explains the thumbnail thing. I was wondering, if the filesize might be a reason for the wrong orientation aswell, but uploading another portrait-image (taken from another phone), the same problem occurs. This image is only (864 x 1152 px).

Is it somehow possible to rotate an image after upload?


#6

Are you using Mac OS, Windows, or any other OS?


#7

I’m using Mac OS X Yosemite and iOS from an iPhone 5. So far all portrait-images from an iPhone 5 (mine or others) are being rotated. If I open the image in my iPhone, rotate it, save it, and rotate it again (to its original state) and upload it, it’s being displayed properly. (This might at least be an emergency solution)


#8

If you upload the image to your computer without opening the image anywhere and just hit command + i in finder, is the exif information there and correct?


#9

Or upload images to http://regex.info/exif.cgi and see if there is something in the “Orientation” field.
Photoshop doesn’t display metadata in a complete or practical way.


#10

Without any saving or opening, I can see all the data and the image is displayed correctly with CMD + i.

EDIT: Checking my files with the mentioned website and reading the exif-data out with php, I get the value “6” for orientation, which is also the correct value for portrait-images (to rotate them 90° CW).


#11

Some more news. If I upload a portrait-image, it is displayed by the Panel and in the template with a wrong orientation (90° CCW). If I click on the image in the Panel (So it opens the direct image-url in the browser), the image is displayed correctly. How could this be?

Here two screenshots:
Image In Panel
Image-url opened in browser (Safari)

I’m calling the image in my template like this:

$lastimage = $page->images()->sortBy('modified', 'desc')->first();
<img src="<?php echo $lastimageurl; ?>" title="<?php echo $pavilionpage->title(); ?>" />

#12

OK I did a few more tests. Same here, the orientation info doesn’t seem to be read. Only the dimensions are taken into account.

An image straight from an iPhone has:

  • Dimensions: 1,600 × 1,200
  • Orientation: Rotate 90 CW
    Displayed the wrong way (vertical image, thumbnail displayed horizontally)

But one resized in Photoshop and saved has:

  • Dimensions: 750 × 1,000
  • Orientation: Horizontal (normal)
    Displayed correctly (vertical image, thumbnail displayed vertically)

I’d have to dig a bit more, but I now think there are two issues:

  1. The thumbnail is created without taking orientation into account. It just takes the dimensions and resizes. EXIF:
  • Dimensions: 300 × 200
  • Orientation: (none specified)
  1. On the image details screen, a bigger image is displayed. It’s actually the original full-size one but as a background image. And most browsers can rotate images automatically (= read EXIF info), but not when used in an html document or as background images.
    This is probably why your image is right when you click to view the original.

#13

I had that issue only once and I assume it’s a problem with GD lib. I couldn’t find any fix for it so far. Did you try to switch the thumbs driver to imagemagick?

c::set('thumbs.driver', 'im');

#14

I though a bit more about it, and think it’s not a Kirby or GD issue after all.

The orientation info only makes sense in images taken straight from a camera. Camera manufacturers do this because rotating a photo in-camera before saving the file is ressource intensive, takes time, and would drain the battery.
When an image is modified in a graphic editor, there is no longer any doubt as to which orientation is correct: you edit and save it the way it should be looked at, with the top of the image at the top. That’s why most editors just strip the orientation info and re-save the image in its “normal”, intended orientation. A portrait 1600x1200 image with a “Rotate 90 CW” info then becomes a 1200x1600 one without any orientation info.

Now what should the thumb() function do? It has no way to know how the image will be displayed, so it shouldn’t try to “fix” the image and take orientation into account because:

  1. the function() can’t tell if we’ll only use thumbnails, or both thumbnails and the original image. Both should have the exact same orientation infos ;
  2. sometimes you may take a photo sideways and want to keep it that way. Automatically “fixing” it would give a wrong result ;
  3. orientation sensors sometimes give wrong informations when the camera is aimed towards the ground or sky.

So @R4ttlesnake, as you display you images in html pages and the untouched originals alone in a new window/tab, I believe the only way to get consistent results on your site is to rotate them before you upload them. It could be really quick, and lots of apps can do lossless jpeg rotations.

Edit: if Kirby offers post upload hooks someday, you may try to losslessly rotate the original image with something like jpegtran first, then create thumbnails.


All images are rotated after uploading
#15

Thanks for all the efforts, it got quite clearer now.

So, at first, it’s indeed not the driver, ImageMagick delivers the same results. About the uploads, I wanted to use the feature to upload images from the camera, straight via the mobile Panel-version of Kirby. As this turns out very complicated, it might indeed be best, to just rotate or save them before.

I’m using the Image Converter Plugin, by seehat, to create multiple resized versions of my upload with the Post File Upload Hook. I thought there might be a way to check the actual orientation of the image against a possible orientation-data in the exif and if they don’t match, rotate the image after upload. As this all goes to deep for my knowledge, I’ll have to stick to the save-first-before-upload method.

Best!


#16

I just noticed the Image Converter plugin has an auto orientation option, but it’s off by default: 'autoOrient' => false. Well it’s actually an option in the Toolkit’s thumb() function.
I think what autoOrient does is flip/rotate the image according to its orientation field in EXIF. The new image should be saved in the right orientation, with EXIF info stripped, and possibly display the way you want.

For the full-size image, you could try to create a auto-rotated version of it, of the same dimensions, and have it replace the original. Probably not lossless, but sometimes convenience beats 100% quality :wink:


#17

Hi, I was already trying to set the autoOrient option ‘true’. Weirdly, this function rotates the image into its correct orientation, but squeezes/resizes it back into the landscape format.

So, now it gets complicated. The portrait image is oriented wrong like 800 x 600 (in 90° wrong orientation). The autoOrient seems to rotate it correctly by 90° into 600 x 800, BUT squeezes the height to 600 and stretches the width to 800. It ends up 800 x 600 (correctly oriented portrait, squeezed into landscape.

Is there probably any fix for this?

Here my image Converter settings:

'url' => $fileurl,
'root' => $filedir,
'width' => 1280,
'height' => 1440,
'upscale' => false,
'quality' => $resized_quality,
'filename' => '{name}_bah.{extension}',
'autoOrient' => true,

Image Converter Plugin

Thanks!


#18

Ok, first the doc says “This converts your image to a maximum size of 1024x1024 px” and your settings use bigger values, can you try with smaller ones?

Just a wild guess, untested: the plugin does autoOrient before resize. What if you modify the script (lines 86 to 90) to apply resize before autoOrient?


#19

OKOKOK, I owe you beers, that’s that’s it. The problem was indeed, that the autoOrient was executed first and the plugin then resizes with the former (landscape) dimensions.

Now, I changed it to the following + it works with bigger sizes than 1024 x 1024 px.

...
$command[] = '-resize';

$dimensions = clone $this->source->dimensions();
$dimensions->fitWidthAndHeight($this->options['width'], $this->options['height'], $this->options['upscale']);
$command[] = $dimensions->width() . 'x' . $dimensions->height() . '!';

if($this->options['autoOrient']) {
  $command[] = '-auto-orient';
}
...

Well, thanks again!


#20

Good news! This actually was also useful to me, as I’m working on a site with lots of image uploads :smile:
I opened a issue in kirby-imageconverter’s repo with a link to this thread.