Orientation correction not working in Safari 13.1 (including iOS)

[gbresciano]

Hi, first, I want to thank you for this library. It's been very useful for me.

It seems that there's a problem with the last version of safari. When loading a portrait image (orientation = 6) it shows up as a landscape image
You can reproduce it with this image in the demo and you'll notice that the result is rotated as in this screenshot:

This doesn't happen in chrome.

Can you help?

Thanks!

[aogaili]

+1 I just ran into the same issue as well.

[gbresciano]

It seems that the latest version of safari autorotates based on EXIF data and then the image loader rotates again

[aogaili]

Yes, I can confirm that this is the case, I've removed the orientation attribute and indeed the correct orientation is rendered!

[gbresciano]

I suspect this might be linked to the implementation of a new css property called image-orientation (https://webkit.org/css-status/#property-image-orientation)

As a temporary workaround, I'm only enabling the orientation option if the image-orientation css property is not available

{ orientation: document.createElement('img').style.imageOrientation === undefined }

[aogaili]

Thanks @gbresciano for this research and workaround!

[gbresciano]

I just noticed firefox has css image-orientation but doesn't rotate the photo automatically, so the workaround is not good

[hartdn]

I was going to work-around this by checking for the version of Safari, but I have noticed that if you choose to resize on iOS or iPados then it strips the exif data. So now I don't now what to do.

[beavis]

What about checking if default-orientation computed value is "from-image" and disabling orientation if that is the case?

{ orientation: getComputedStyle(document.body).imageOrientation !== 'from-image' }

Would it be possible for the library to just force to use image-orientation: 'none' when generating the image? Does canvas drawImage respect that?

Edit: I'm afraid on safari canvas doesn't care about that and uses the default image-from behaviour: check this url on safari: https://mcc.id.au/2020/image-orientation/
Related chromium issue: w3c/csswg-drafts#4666

[blueimp]

Thanks for the report @gbresciano and everyone's comments.
As visible from @beavis chromium issue link, the same problem affects the next major version of Chrome (v81).

I have not found a good workaround using the style.imageOrientation property on either the img or document.body elements.
I was originally hoping that I can set img.style.imageOrientation = 'none' before drawing into the canvas element from the img source, but this had no effect.

I do have a workaround testing EXIF image orientation support the same as in the unit tests:

JavaScript-Load-Image/test/test.js

Lines 839 to 854 in 452adbf

	it('Should rotate right based on the exif orientation value', function (done) {
	expect(
	loadImage(
	blobJPEG,
	function (img, data) {
	expect(data).to.be.ok
	expect(data.exif).to.be.ok
	expect(data.exif.get('Orientation')).to.equal(6)
	expect(img.width).to.equal(1)
	expect(img.height).to.equal(2)
	done()
	},
	{ orientation: true }
	)
	).to.be.ok
	})

But that means including a 713 Bytes JPEG image (might be possible to make it smaller) in the library itself.

Will test a bit further before pushing a fix.

[beavis]

I was originally hoping that I can set img.style.imageOrientation = 'none' before drawing into the canvas element from the img source, but this had no effect.

That was my initial thought and in chrome canary looks like it's actually working, either setting it on the image or in the canvas element makes it render in the original orientation, but seems safari does not support that, you can check it on last row of images here: https://mcc.id.au/2020/image-orientation/

But that means including a 713 Bytes JPEG image (might be possible to make it smaller) in the library itself.

I was testing checking against computed value of imageOrientation property, not sure how safe or future proof this is.
Would this 329 bytes jpg work for the check? https://raw.githubusercontent.com/beavis/orientation/master/orientation6.jpg

[blueimp]

Yes, that looks usable.

• What kind of license would you put it under (preferably "public domain")?
• How did you create it?
• With which JPEG decoders did you tests its validity?

I was thinking about basing a minimum file on https://github.com/mathiasbynens/small/blob/master/jpeg.jpg, but I've only ever researched JPEG image headers, not JPEG image content.

[beavis]

I can't decode that one, seems it's an arithmetic JPG but it that works for your test it will be smaller for sure.
I just created a sample 2x1 black image with an image editor and ran jpegoptim against it then added the exif field. In case you need it I just added an MIT license readme to that repo, but I don't mind about that at all, take the file as yours.

[beavis]

By the way, looks like safari ignoring image-context: none on canvas drawImage is a bug that has already been patched: https://bugs.webkit.org/show_bug.cgi?id=209849

[blueimp]

Good news about the safari patch, that would allow a workaround without a test image.

Didn't know that jpegoptim works that well for minimal files, I'll use the same approach, thanks.
Which tool did you use to add the EXIF info?
I have a 350 bytes file that is black/white 1x2 pixels and has the Orientation flag, transplanted via jhead, but was wondering if there's a better tool.

[beavis]

Which tool did you use to add the EXIF info?

I just used a GUI for exiftool, not sure if that works any better than your approach.