Image portrait, shows 90deg rotated clockwise in the editing modal

[somatonic]

I upload a portrait image and then click to edit and in the modal the image is rotated to the right 90 degrees.

The uploaded image show correct in the finder and also the thumbnail.

When I create a portrait jpg in photoshop and upload it works fine.

There's something with the meta data.

Also brings me to the conclusion that we need a rotation tool too? :)

[apeisa]

Any possibility to get the original image for trying to reproduce this one?

[somatonic]

It's just a portrait photo original from a nikon or cannon camera.

[somatonic]

Two photos as example http://soma.urlich.ch/photos/DSC_1612.JPG http://soma.urlich.ch/photos/DSC_1605.JPG

[ryancramerdesign]

Soma, something definitely different with those photos as when I open them in my browser, they draw from left to right (rather than top down), and that's something I've never seen before. I have both Nikon (DSLR) and Canon (P&S) cameras, but haven't observed this effect with photos from either.

If I upload them to PW, ImageSizer isn't even able to manipulate or generate variations from them. I think we most likely need Horst to take a look at these photos. They seem to be of a different format than we've seen before. Perhaps PHP's GD can't read them? I noticed in looking closely at the EXIF data that they have thousands of data points (more than I've seen), plus 3 versions of the image in the JPEG file: full res, 570 width, and 160 width. I'm guessing this is all supported by the JPEG standard, but maybe not that common? To summarize, we need Horst. :)

On Thu, Feb 26, 2015 at 7:35 AM, Philipp Urlich notifications@github.com wrote:

Two photos as example http://soma.urlich.ch/photos/DSC_1612.JPG http://soma.urlich.ch/photos/DSC_1605.JPG

— Reply to this email directly or view it on GitHub https://github.com/ryancramerdesign/ProcessWire/issues/964#issuecomment-76170800 .

[somatonic]

Well they work fine everywhere so far for me, resizing etc, in browser, in finder etc. Only one that doesn't work is in the edit modal. :)

I can't tell exactly what's up with these photos (even if I made them) as the camera is the one of a friend of mine. Just a good digital camera.

[teppokoivula]

@somatonic From what I can tell, these images definitely seem rotated. Take a look at what this tool has to say about them: http://regex.info/exif.cgi. I'm seeing "Orientation Rotate 270 CW" in the EXIF data.

[somatonic]

@teppo of course is the image rotated (by rotating the camera), so this info is in the picture (as we all know). I'm not sure what you want to say with that. It works with all image software aswell as OS and PW image sizing, so it is handled all correctly except by PW new edit modal.

[teppokoivula]

I'm not entirely familiar with all the things that ImageSizer now handles, but from what I can tell, rotating images is definitely in it's scope. This can be specifically disabled, but seems to be enabled by default, and I'm guessing that this feature "is to blame" here. Either that, or perhaps ImageSizer doesn't recognise the rotate settings in your image, while it should.. just thinking out loud :)

[teppokoivula]

@somatonic Sorry for obscure comments. What I'm trying to say here is that the way you described this issue, it seems to match what I'm seeing elsewhere. If you try that tool I linked to, it displays exactly the same "problem".

I'm not familiar with how these things are usually handled, so I'm partly guessing, but what I've said above seems like a possible issue here.

[somatonic]

Since it works everywhere except in the edit modal, it seems that it is rotated by image sizer correctly but the info stays there, and then in the modal it get's resized again to it's rotated again? Not sure.

[teppokoivula]

Right -- sorry. Looks like I skipped some parts of your description there, and the testing tool on the other hand is probably meant to display images like that :)

[nicoknoll]

Strange thing: I have this chrome extension "Hover zoom". So if I hover your image link it will be rotated 270 ccw (from how it should be). If I open the link in a new tab the orientation is right but it loads from left to right (if you would turn it 270 ccw from how it should be it would be loading from top to bottom I guess)...

I guess it's the same problem as here: http://stackoverflow.com/questions/19561090/why-this-image-is-loaded-from-right-to-left

[somatonic]

I can't observe this as it's always displaying "correct" orientation (portrait) in all my software I have. MacOSX, Chrome, Firefox etc. Finder Preview, Photoshop all handle it correctly. So I'm lost as to what's happening here and why it should be different for others. 270 CW means the image is rotated 3 times 90, that is already strange as it's usually only rotated 90 CW or -CW.

[nicoknoll]

I think I found something. Take a look here: http://jsfiddle.net/63rtfog1/

Chrome only displays it correctly if opened directly (the image url ending with ".jpg"). If you embed the image in html the exif information will be ignored. Same thing for PHP I guess.

(So processwire probably would have to take a look at the exif data, rotate the image, save the image and overwrite the exif data. Like here: http://www.neilyoungcv.com/blog/code-share/image-resizing-with-php-exif-orientation-fix/)

[teppokoivula]

So, just continuing what @NicoKnoll said above: the version of the image loaded in the edit dialog is the original one, not resized, and thus not rotated? Seems to make sense, actually. Should all images be rotated when uploaded, regardless of whether they need resizing? :)

I was observing similar behaviour here, though it occurred when I tried to open an image in (magnific popup) modal.

[somatonic]

Just. It works when I upload it in PW. The uploaded image, lightbox zoom view and the thumbnail are all correct. So it seems to be handled correctly. Though Ryan mention he can't even upload as the resizer throws an error? Weird.

[teppokoivula]

@somatonic strangely enough the lightbox (if you're referring to the one you get when clicking on the image in the field?) acts just the same as the edit view for me, which is consistent with what Nico mentioned earlier.

In short, every time that the image (original, not resized) is embedded in HTML (directly or via AJAX) it gets displayed "tilted". Using Chrome here, if the behaviour differs between browsers, and the field doesn't have max size defined (which actually prevents this whole issue from happening, as long as uploaded images are "too big").

[nicoknoll]

But I think it's save to say a solution would be to re-save every EXIF rotated image via PHP in the right orientation. I think this should somehow be included in the core to prevent problems like this.

[somatonic]

Ok, I just tested again and the lightbox zoom shows also rotated, so yes it's when it's just output in html.

[horst-n]

Hi, haven't seen this earlier. It can result in problems when automaticly rotate and save images to replace the original ones on upload: 1) All EXIF data is lost! 2) We cannot detect the original quality of an uploaded image, and thus there is a huge potential to damage images by just assume or select the wrong quality setting after autorotate. Also a global setting may not suit all images on a site. I can upload images with different qualities just into one imagefield.

ImageSizer keeps the original images untouched to be able to access Exifdata and to not corrupt image quality. Therefore it rotates images on the fly just before applying the other modifications. After autorotating it swaps width and height if necessary.

I would highly suggest to visually mark all thumbnails of images with wrong orientation in the admin. And then give the user an icon to autorotate and replace the original image if he want to, but not without a selection for quality.

Also the new image modal should read the orientation flag and simply use some CSS rotate / transform for displaying it right oriented on the fly. This way all users can get satisfied, those who want to stay with there original images and those who want to replace their originals. But don't forget to tell them that they will loose all metadata.

I will check if ImageSizer allready is able to only detect and return the orientation flag, and if not I can make a suggestion, Ryan. Also I will try out Somas image and report back, but think you guys already have nailed it.

[horst-n]

So, Somas images are simple JPEGs, from a Nikon D7000 and were shot back in 2013, or the clock of the camera was set wrong. :) But regardless of that, the orientation flag tells that it need to be rotated CW 270 (what would would be CW -90, CCW 90). Currently the modal image editor does not check / respect the orientation flag when displaying the image. But after selecting a crop and delegate it to ImageSizer, ImageSizer assumes that the crop is meant for the corrected orientation. (Thus it creates wrong crops, maybe with added big black barns).

Can this be the solution ?

div.rotate {
    -moz-transform:rotate(270deg);     /* Firefox 3.6 Firefox 4 */
    -webkit-transform:rotate(270deg); /* Safari */
    -o-transform:rotate(270deg);         /* Opera */
    -ms-transform:rotate(270deg);       /* IE9 */
    transform:rotate(270deg);              /* W3C */
} 

BTW: CroppableImages is affected by this wrong orientation too.

[horst-n]

Another thought on the general problematic of wrong image orientation:

There is a nice tool, jpegtran, available on ubuntu and other distros. It is also available as Windows binary. It was initially released around 2000 and is still maintained: http://manpages.ubuntu.com/manpages/lucid/man1/jpegtran.1.html http://jpegclub.org/jpegtran/

This little commandline tool provides lossless jpeg rotation and keeps all metamarkers! I think on systems where this could be used (no exec() restrictions) we should silently auto-correct rotation on upload. On systems where this can't be used, we should use an opt-in solution as I have said in my previous posts, (mark thumbs in admin with a red triangle or that like).

[teppokoivula]

@horst-n I'm definitely wrong person to comment on things related to managing images, but.. I'd much rather see a CSS solution than an exec() call.

Additionally the lack of rock solid licensing terms (preferably in the form of a recognised free software license) is a red flag for me, even if the authors do allow use of said library as long as it's properly credited. That's probably just me being overly cautious, though :)

[horst-n]

@teppokoivula: I personally also highly would prefer to let the original images untouched. :) And I never would use GD to automaticaly manipulate and store original images. So a CSS-rotated Display is my favourite.

Regarding the license I have to say that I haven't looked at that since I have seen that it is in the default Ubuntu distro. I have thought that this is a sign that it is free software per se. Sorry.

[teppokoivula]

@horst-n Perhaps I was a bit too hasty there; jpegtrans devs don't make it exactly obvious how their licensing model works (partly because there's no separate document for that and they don't use a known license), and that seemed kind of fishy.. but it looks like Ubuntu considers it free software, and Wikipedia says it's free software with "a custom BSD-style license and attribution requirement". So.. sorry for that :)

Either way, the CSS method definitely still gets my vote.

[horst-n]

:)

[andoro]

Hello guys! Is there any solution for this issue in PW 2.6?

I run into this problem with my client who is using PW 2.4

Thx a lot!

[azimidev]

I have this issue. Any update