Closed Bug 1616169 Opened 6 years ago Closed 6 years ago

honor intrinsic orientation information in drawImage()

Categories

(Core :: Graphics: Canvas2D, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla77
Tracking Status
firefox77 --- fixed

People

(Reporter: heycam, Assigned: heycam)

References

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(1 file, 4 obsolete files)

Browsers are converging on honoring EXIF orientation data for HTML images (per bug 1607667).

For images painted with canvas drawImage(), there are some differences:

  • In WebKit, where there is no image-orientation property (it's effectively always from-image), the image drawn to the canvas will honor the EXIF orientation.

  • In Chrome, it will also honor the EXIF orientation, unless the value of image-orientation on the canvas element is none.

Taking this to ensure it is resolved before bug 1607667 makes it to beta.

Assignee: nobody → cam
Status: NEW → ASSIGNED

Thanks Cameron! I think if the idea in the CSS WG is to remove image-orientation we should do as WebKit?

I think the idea is to remove the property once we know that there is no need for image-orientation: none to opt out of any unintentional breakage from flipping the initial value.

I was wrong about WebKit: while in current Safari releases there is no image-orientation, they have recently landed an implementation that supports from-image and none, with from-image` being the initial value, but it hasn't made it into a STP yet.

The priority flag is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(lsalzman)
Flags: needinfo?(lsalzman)
Priority: -- → P3

Note that this does not match what the recently added WPTs require, which
is that the value of image-orientation on the canvas element is used to
determine whether to correctly orient the image. This isn't currently
supported by the HTML spec however; if that gets edited in, we can
update our behavior.

Can you get Apple/Google to start a discussion on that if they still want it? Seems weird, but not out-of-line with the way <canvas> works I suppose.

Is there an equivalent bug for WebGL APIs? They also appear to take images as input.

I'll file a separate issue for canvas.

I don't have a separate bug for WebGL, but in the end I'm going to solve this in a more general way, in bug 1616411, that doesn't require any specific updates to canvas or other image consumers. So in this bug I'm only going to land the test renamings.

Attachment #9135247 - Attachment description: Bug 1616169 - Part 4: Mark canvas drawImage orientation tests as tentative. → Bug 1616169 - Mark canvas drawImage orientation tests as tentative.
Attachment #9135244 - Attachment is obsolete: true
Attachment #9135245 - Attachment is obsolete: true
Attachment #9135246 - Attachment is obsolete: true
Attachment #9135248 - Attachment is obsolete: true
Pushed by cmccormack@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/23d1f2dbee27 Mark canvas drawImage orientation tests as tentative. r=tnikkel
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/22799 for changes under testing/web-platform/tests
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla77
Upstream PR merged by moz-wptsync-bot
Keywords: site-compat

There's still an outdated note on https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage

drawImage() will ignore all EXIF metadata in images, including the Orientation. This behavior is especially troublesome on iOS devices. You should detect the Orientation yourself and use rotate() to make it right.

Keywords: dev-doc-needed
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: