image rotation is on wrong direction

[Mikael]

Hi community! Thank you for the great system!

But I have faced with a problem. Given an image. When I upload the image to image field - image gets rotation in wrong direction..

 

 

On the above image you can see the third image rotated on the contrary...

https://github.com/processwire/processwire/blob/d8945198f4a6a60dab23bd0462e8a6285369dcb9/wire/core/ImageSizerEngineGD.php#L477

DSC01828.zipAlso if I change the above line to:

$angle = 360 + $degree;

then it rotates it correct.. So it seems like script rotates image in wrong direction.. What to do with that? Thanks!

I have attached zip with original image.DSC01828.zip

[bernhard]

This is a more than annoying bug that will hopefully be fixed sooner than later: https://github.com/processwire/processwire-issues/issues/1154

Please add a comment to the issue that you are also having problems with this. Hopefully it will get Ryans attention.

[Mikael]

@bernhard thank you for the answer! I have commented it on github) But how do you avoid this problem for your own ?

How do you think, it is good idea to avoid it as I said, at least temporary with changing '-' to '+'

$angle = 360 + $degree;

[bernhard]

I have no solution yet. @Robin S seems to have found a way, but I had no time to test what he wrote in the issue. I was always hoping that Ryan will come up with a fix sooner than I have to build a quickfix on my own. I thought of adding custom buttons/checkboxes to rotate the image after saving... For now I've just added a comment that says "if the orientation is wrong please use this online editor and upload the image again" ? 

[Mikael]

@bernhard But where can I take a look at Robin S solution ? I even did not expect that meeting brother in misfortune could make me so happy. Your web site looks great. We are also a German team. Our link will be encrypted in this message, like a little puzzle) So need to fix it and 'get it work'.. I don't know if the extension of website where I have error with image does matter, but if it does it is 'com'. 

[bernhard]

@Robin S is a genius! ? 

Based on his posts in the github issue I did the following and finally got the bug fixed (it seems):

 

For Server Side Resizing:

Search for "$corrections = array(" in all your files. You should find 3 files:

Replace those arrays with this one:

		$corrections = array(
			'1' => array(0, 0),
			'2' => array(0, 1),
			'3' => array(180, 0),
			'4' => array(0, 2),
			'5' => array(90, 1),
			'6' => array(90, 0),
			'7' => array(270, 1),
			'8' => array(270, 0)
		);

This did already fix my issue.

Client Side:

Replace PWImageResizer.js with this file created by @Robin S and delete the old minified version PWImageResizer.min.js to make sure that the new version is loaded: https://github.com/processwire/processwire-issues/files/4660217/PWImageResizer.zip

 

Would be great to hear if that also fixed your issue @Mikael ?

Thx again @Robin S for the great work!!

[Mikael]

@bernhard wow wow really wow) I followed your instruction and seems problem gone away ) Hope it will not back again) Great danke! 

[bernhard]

1 minute ago, Mikael said:

Hope it will not back again)

It will be back on the next update of ProcessWire unless Ryan fixes the issue in the core until then. So you either need to wait with that update or you apply the changes again after your upgrade.

[Mikael]

@bernhard yes this is completely understandable ) but I meant that bug will not have other side effects and not appear with other images 

[horst]

What I do not understand is why the original code has worked for 15+ years and now (within a sudden) it should not do anymore. As far as I could not find any changes in the EXIF specs. ??

Are you sure that the corrections arrays are wrong, really? Or may it be that the browsers have changed to a behave that rotates images ONLY BY VIEW, and that this new browser behave has to be corrected elsewhere in the inspection and processing workflow?

Just wondering.

[bernhard]

Yeah, good point. I have no idea... I have another problem in my app. I'm generating a PDF from a page with some images and one of them keeps getting rotated by 90°. Only one, all the other images work as expected. ? 

[horst]

Until today, since 20+ years, every time when I inspected such behaves, it comes out at 100% that the source image simply got the wrong notation in the EXIF rotation flag. 

Mostly directly when created from a camera, but also came from image tools that rotated images without updating the EXIF rotation flag.

In my opinion, the new browser behave isn't of any help but makes it more "mysterious" for regular users when working within image processing chains. The ONLY point where this new behave is helpful is when original images will be displayed on the front in a webpage (and have uncorrected rotation).

[bernhard]

Hm. I thought maybe I could strip the EXIF data from the image but did not have enough time to look into it. Do you know if PW has a method for that? Otherwise it seems to be 7 lines of code using php+imagick (which I'm using).

[horst]

EXIF data is stripped out with every processing function that uses GD-lib. So, if you just use creating a 100% width "variation" and store it as the "new" original image, all your EXIF data is lost. (GD-lib simply does not keep any image markers by design. Historically it was build to create small images for the web, and everything that may bloat filesize is dropped)

PW every time reads the EXIF data from the original image that regularly will be kept untouched.

[thetuningspoon]

On 12/3/2020 at 12:00 PM, horst said:

What I do not understand is why the original code has worked for 15+ years and now (within a sudden) it should not do anymore. As far as I could not find any changes in the EXIF specs. ??

This has been an intermittent issue for me with PW as long as I can remember.

[ian]

Just came across this issue today with one of my clients.  Unfortunately @Robin S's fix(es) didn't make any difference for me (applied to PW 3.0165).

Turning off client-size resize option in the image field made no difference

The image in question's Orientation is reported as "Rotate 270 CW" via an online EXIF reader, but oddly enough, I got different behaviour in my local dev environment to that in production (could be differences in the PHP/GD engine versions I guess).  In dev, the image was rotated 90 CW, but in production 180 CW. ?

[teppo]

Hey @horst — sorry for pinging, but I'm pretty sure you're most likely to know what's going on here ?

So, I've been having similar issues with one site, where there are a lot of profile pics etc. Quite often uploaded images are not correctly rotated by ProcessWire. It's not super common issue, but common enough to cause major problems for admins.

Now, one pic which I'm currently testing (I can share a link if it's important) reports EXIF orientation as 8:

• Based on our built-in corrections array, orientation 8 should be rotate 90 degrees (clockwise, I presume).
• Based on some other sources, such as https://www.impulseadventure.com/photo/exif-orientation.html, orientation 8 actually requires 90 degrees CCW (or 270 degrees CW).

Am I reading that source wrong, or is there a mistake?

The array provided by @bernhard fixes the issue for me, and seems to be in line with at least that single source. I am not well versed in this topic, so be kind; I may be entirely missing the point here ?

[bernhard]

I can just say that I'm still having this issue as well... 

[Jan Romero]

40 minutes ago, teppo said:

Based on some other sources, such as https://www.impulseadventure.com/photo/exif-orientation.html, orientation 8 actually requires 90 degrees CCW (or 270 degrees CW).

If you want to have a bit of fun, I recommend the EXIF specs:

2.3 (2010)
2.3 (2012 revision, including fixes in the orientation part)
2.31 (2019)

All of them say of orientation 8 “The 0th row is the visual left-hand side of the image, and the 0th column is the visual bottom,” so 90° CCW seems correct. Further down you can find such gems as

“Orientation = 8 is equivalent to an arrangement that is turned Orientation = 3 90 degrees clockwise”. Skip to Orientation 3:

“Orientation = 3 is equivalent to an arrangement that is turned Orientation = 6 90 degrees clockwise” …

“Orientation = 6 is equivalent to an arrangement that is turned Orientation = 1 90 degrees clockwise”. Right. Thankfully, Orientation 1 is self-sufficient:

“Orientation = 1 is created when 0th row of the coded image data stored in the Exif image file and the visual top of the display screen, and 0th column and visual left, will each be matched for display”. Hooray.

I feel like I’m in an escape room.

[Jan Romero]

Just to add to the reports, I have coincidentally encountered this issue just minutes ago and thankfully remembered this thread. Bernhard’s/Robin S’s fix worked for my image. It was EXIF orientation 6 (confirmed this to be in line with the specs. 90° CW to make it upright), shot on some old-ish Samsung phone and uploaded without client side resizing. The original showed up fine, but the generated variations were upside-down. Thanks!

[horst]

On 12/3/2021 at 11:10 AM, teppo said:

Hey @horst — sorry for pinging, but I'm pretty sure you're most likely to know what's going on here ?

Hi @teppo, I'm not able to react quickly to this. I will try to investigate and / or set up an in-depth-test for that issue and want to take in some of the images where @bernhard and / or @Robin S solutions worked fine. Just trying to get a new working solution for all situations. But I only can schedule this after the 22. december, unfortunately not earlier. ?

@teppoCan you PM me a zip with the wrong original image, and maybe one corrected from PW, or only the original image and what you have changed in the code so that it comes out correctly?

[bernhard]

I've had to deal with this issue today and I tried my fix from last year and unfortunately got wrong results as well ? 

I'll send you the image via PM @horst

[teppo]

11 hours ago, bernhard said:

I've had to deal with this issue today and I tried my fix from last year and unfortunately got wrong results as well ? 

Hey Bernhard. Just to confirm: do you mean that the corrected image rotations array didn't fix the issue for you? If so, did you have client side image resizing enabled, and did you try if disabling that makes any change?

14 hours ago, horst said:

@teppoCan you PM me a zip with the wrong original image, and maybe one corrected from PW, or only the original image and what you have changed in the code so that it comes out correctly?

 

PM'd.

[palacios000]

On 12/3/2020 at 6:38 PM, horst said:

EXIF data is stripped out with every processing function that uses GD-lib. So, if you just use creating a 100% width "variation" and store it as the "new" original image, all your EXIF data is lost. (GD-lib simply does not keep any image markers by design. Historically it was build to create small images for the web, and everything that may bloat filesize is dropped)

PW every time reads the EXIF data from the original image that regularly will be kept untouched.

Would it be not possible to remove all EXIF data on image upload, so PW has a neutral version of the image? Then the person who uploads the photo can check the orientation.

My problem now is: when the image gets rendered from PW, the orientation is correct; but when I fetch via http a variation of the same image, as you said EXIF data is lost, so the resized image has wrong orientation.

[teppo]

5 hours ago, palacios000 said:

My problem now is: when the image gets rendered from PW, the orientation is correct; but when I fetch via http a variation of the same image, as you said EXIF data is lost, so the resized image has wrong orientation.

Out of curiosity, which version of PW are you using?

PW auto-corrects the rotation, and some issues related to this were fixed in version 3.0.197. Just wondering if updating to the latest stable version (3.0.200), for an example, would resolve this problem.

5 hours ago, palacios000 said:

Would it be not possible to remove all EXIF data on image upload, so PW has a neutral version of the image? Then the person who uploads the photo can check the orientation.

My understanding is that PW doesn't remove EXIF data from uploaded image, just resized images — though I could be wrong here! One exception at least is that if you have configured a max image size for your image field, then it will be automatically resized after being uploaded, which means that PW no longer has any version of it with EXIF data in place.

Anyway, I'm not sure which one you're talking about here: original uploaded image, or a PW generated size variation of it? If it's the latter, then currently there's no way to retain EXIF data, but the image should still be automatically rotated according to what was in said EXIF data.

(There is an open issue about keeping EXIF data, at least in some cases, but no clear solution yet: https://github.com/processwire/processwire-issues/issues/1055.)