Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Fri, 13 Mar 2015 07:39:07 +0100, Philip Jägenstedt phil...@opera.com wrote: For video the rotation is applied to videoWidth and videoHeight, at least in Chromium/Blink. A video with rotation metadata is thus indistinguishable from one where the frame themselves are rotated. If there's any hope that doing the same for img could be Web compatible, and Safari's behavior makes that seem likely, that seems like a pretty good outcome. Let's try it. https://code.google.com/p/chromium/issues/detail?id=413272#c6 -- Simon Pieters Opera Software
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Tue, Mar 10, 2015 at 1:29 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a markup feature as it affects the semantics of the image (or perhaps investigate whether rotating automatically is feasible): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Yup, and thanks for linking the bug. If it happens at the markup level, it should *definitely* affect the naturalWidth/Height properties. I don't think that's in question at all. But nobody's moved on the markup issue, so I haven't removed the CSS property yet. ^_^ ~TJ
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties. I don't think that's in question at
all. But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^
Not to rehash comments that I and others have already made in bug 25508, but I
think specifying whether we honor EXIF orientation on a per-image basis is not
really very interesting.
By far the most desirable outcome, if it’s sufficiently web-compatible, is to
just respect EXIF orientation by default.
If we can’t do that, then I think content authors will mostly just opt in via a
single “img { image-orientation: from-image }” in their CSS. That’s the
simplest opt in solution that’s feasible. It’s also trivial to encapsulate in a
standard CSS library.
I’m opposed to the removal of the CSS property for a markup-based solution, as
that will force content authors to specify “autorotate” on every single img
element on the page. That’s a waste of effort and bandwidth (though admittedly
compression will make the impact there minimal), and it makes it more likely
that content authors will simply forget to do so on some elements.
Encapsulating this solution is also significantly more heavyweight.
Having a DOM-based way to request that EXIF orientation be respected is
desirable, though, so that it can be used with non-HTML uses of images like
canvas.
- Seth
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Fri, Mar 13, 2015 at 12:21 PM, Seth Fowler s...@mozilla.com wrote:
On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties. I don't think that's in question at
all. But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^
Not to rehash comments that I and others have already made in bug 25508, but
I think specifying whether we honor EXIF orientation on a per-image basis is
not really very interesting.
By far the most desirable outcome, if it’s sufficiently web-compatible, is to
just respect EXIF orientation by default.
Yup, agreed, that's the best solution. Let's make it happen. ^_^
If we can’t do that, then I think content authors will mostly just opt in via
a single “img { image-orientation: from-image }” in their CSS. That’s the
simplest opt in solution that’s feasible. It’s also trivial to encapsulate in
a standard CSS library.
I’m opposed to the removal of the CSS property for a markup-based solution,
as that will force content authors to specify “autorotate” on every single
img element on the page. That’s a waste of effort and bandwidth (though
admittedly compression will make the impact there minimal), and it makes it
more likely that content authors will simply forget to do so on some
elements. Encapsulating this solution is also significantly more heavyweight.
Having a DOM-based way to request that EXIF orientation be respected is
desirable, though, so that it can be used with non-HTML uses of images like
canvas.
Agree with all of this. It's still unclear, though, whether the
effects of the CSS property should be reflected in the
naturalWidth/Height properties, which is the subject of this thread.
If we can get away with just always autorotating, the question is
moot, which is ideal.
~TJ
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
Dragging dropping an image to save locally, a common image UI
interaction. Regardless of `image-orientation` the file saved isn't going
to change, right?
As a developer my intuition would assume that naturalWidth/Height are
constrained to the physical media and not the EXIF meta data. If you want
the naturalWidth/Height to match, export your media by rotating so the
exif.orientation = 1 (no rotation).
Just my 2¢
On Fri, Mar 13, 2015 at 2:28 PM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Fri, Mar 13, 2015 at 12:21 PM, Seth Fowler s...@mozilla.com wrote:
On Mar 13, 2015, at 11:56 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
If it happens at the markup level, it should *definitely* affect the
naturalWidth/Height properties. I don't think that's in question at
all. But nobody's moved on the markup issue, so I haven't removed the
CSS property yet. ^_^
Not to rehash comments that I and others have already made in bug 25508,
but I think specifying whether we honor EXIF orientation on a per-image
basis is not really very interesting.
By far the most desirable outcome, if it’s sufficiently web-compatible,
is to just respect EXIF orientation by default.
Yup, agreed, that's the best solution. Let's make it happen. ^_^
If we can’t do that, then I think content authors will mostly just opt
in via a single “img { image-orientation: from-image }” in their CSS.
That’s the simplest opt in solution that’s feasible. It’s also trivial to
encapsulate in a standard CSS library.
I’m opposed to the removal of the CSS property for a markup-based
solution, as that will force content authors to specify “autorotate” on
every single img element on the page. That’s a waste of effort and
bandwidth (though admittedly compression will make the impact there
minimal), and it makes it more likely that content authors will simply
forget to do so on some elements. Encapsulating this solution is also
significantly more heavyweight.
Having a DOM-based way to request that EXIF orientation be respected is
desirable, though, so that it can be used with non-HTML uses of images like
canvas.
Agree with all of this. It's still unclear, though, whether the
effects of the CSS property should be reflected in the
naturalWidth/Height properties, which is the subject of this thread.
If we can get away with just always autorotating, the question is
moot, which is ideal.
~TJ
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
For video the rotation is applied to videoWidth and videoHeight, at least in Chromium/Blink. A video with rotation metadata is thus indistinguishable from one where the frame themselves are rotated. If there's any hope that doing the same for img could be Web compatible, and Safari's behavior makes that seem likely, that seems like a pretty good outcome. Philip On Fri, Mar 13, 2015 at 6:14 AM, Seth Fowler s...@mozilla.com wrote: The more I think about this, the more I agree with David. It really does make more sense to act like the rotation is part of the image format, because after all it *is*, at least when from-image is used. This approach also gives us a smoother path to eventually respecting EXIF orientation by default. If we did that, we’d want naturalWidth and naturalHeight to take EXIF orientation into account, so planning for that with the behavior of image-orientation makes sense. And FWIW, Safari (which respects EXIF orientation in image documents and by default on mobile) does appear to take EXIF orientation into account for naturalWidth and naturalHeight, so this approach is web compatible. Consider this a second vote for “naturalWidth and naturalHeight should respect image-orientation”. - Seth On Mar 10, 2015, at 10:09 AM, L. David Baron dba...@dbaron.org wrote: On Monday 2015-03-09 16:52 -0700, Tab Atkins Jr. wrote: That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. This is likely to be surprising, but also probably the correct answer for separation-of-concerns reasons. I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm. I really think that the mechanism for opting in to honoring EXIF should make the browser act as though the rotation were in the image format. It's a compatibility hack (because implementations were initially shipping without EXIF support, and there may be a dependency on that), but once the developer has opted in, everything should really act like the rotation is part of the image format. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Monday 2015-03-09 16:52 -0700, Tab Atkins Jr. wrote: That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. This is likely to be surprising, but also probably the correct answer for separation-of-concerns reasons. I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm. I really think that the mechanism for opting in to honoring EXIF should make the browser act as though the rotation were in the image format. It's a compatibility hack (because implementations were initially shipping without EXIF support, and there may be a dependency on that), but once the developer has opted in, everything should really act like the rotation is part of the image format. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
The more I think about this, the more I agree with David. It really does make more sense to act like the rotation is part of the image format, because after all it *is*, at least when from-image is used. This approach also gives us a smoother path to eventually respecting EXIF orientation by default. If we did that, we’d want naturalWidth and naturalHeight to take EXIF orientation into account, so planning for that with the behavior of image-orientation makes sense. And FWIW, Safari (which respects EXIF orientation in image documents and by default on mobile) does appear to take EXIF orientation into account for naturalWidth and naturalHeight, so this approach is web compatible. Consider this a second vote for “naturalWidth and naturalHeight should respect image-orientation”. - Seth On Mar 10, 2015, at 10:09 AM, L. David Baron dba...@dbaron.org wrote: On Monday 2015-03-09 16:52 -0700, Tab Atkins Jr. wrote: That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. This is likely to be surprising, but also probably the correct answer for separation-of-concerns reasons. I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm. I really think that the mechanism for opting in to honoring EXIF should make the browser act as though the rotation were in the image format. It's a compatibility hack (because implementations were initially shipping without EXIF support, and there may be a dependency on that), but once the developer has opted in, everything should really act like the rotation is part of the image format. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On 2015-03-10 09:29, Anne van Kesteren wrote: On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a markup feature as it affects the semantics of the image (or perhaps investigate whether rotating automatically is feasible): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 Just my opinion, but I believe rotation of a image should be stored in the image itself. With JPG this is possible. Not sure about PNG or WebP or SVG though. Now if a image space in a webpage (as reserved by css or width height in a image tag) is say 4:3 but the image has info about rotation so it ends up 3:4 instead then the ideal is for the browser to with that 3:4 rotated image within the reserved 4:3 space. The closest analogy I can think of are black bars on movies, although in this case it would be the background behind the image showing through maybe. If attributes or CSS override the orientation of an image I'd consider that an image effect instead. -- Roger Hågensen, Freelancer
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Tue, Mar 10, 2015 at 12:01 AM, Seth Fowler s...@mozilla.com wrote: I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. I thought there was some agreement that image-orientation ought to be a markup feature as it affects the semantics of the image (or perhaps investigate whether rotating automatically is feasible): https://www.w3.org/Bugs/Public/show_bug.cgi?id=25508 -- https://annevankesteren.nl/
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On 3/9/15, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 9, 2015 at 4:01 PM, Seth Fowler s...@mozilla.com wrote: On 3/9/15, Seth Fowler s...@mozilla.com wrote: Hi all! I wanted to get the opinion of this list on how image-orientation and the img element's naturalWidth and naturalHeight properties should interact. The css-images level 3 spec says: So there is now a property called naturalWidth and that is the intrinsic width. And you want to know about the rotation and how that affects it. Great question. ... but I have a different question:- Why not call it what it is? More names for the same thing adds more confusion. There is already enough complexity with intrinsic width, the width property, computedStyle's width, and clientWidth. Calling intrinsic width, a term that has existed for years, naturalWidth - adds complexity. APIs that use ubiquitous language are generally less confusing than those that do otherwise. Or maybe I've misunderstood Evans' DDD. That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. I think that that is not what Seth was asking about. IIUC, he asked about EXIF rotation info. When you take a pic in your iPhone, if there is rotation data on it, and if that data is not removed, the image will look rotated in browsers that recognize this header, like Safari. -- Garrett @xkit ChordCycles.com garretts.github.io personx.tumblr.com
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Mar 9, 2015, at 5:06 PM, Garrett Smith dhtmlkitc...@gmail.com wrote: On 3/9/15, Tab Atkins Jr. jackalm...@gmail.com wrote: That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. I think that that is not what Seth was asking about. IIUC, he asked about EXIF rotation info. When you take a pic in your iPhone, if there is rotation data on it, and if that data is not removed, the image will look rotated in browsers that recognize this header, like Safari. No, Tab is right. The question is about the CSS image-orientation property, which allows (among other things) an image to be rotated according to the orientation specified in its EXIF info. - Seth
Re: [whatwg] Effect of image-orientation on naturalWidth/Height
On Mon, Mar 9, 2015 at 4:01 PM, Seth Fowler s...@mozilla.com wrote: Hi all! I wanted to get the opinion of this list on how image-orientation and the img element’s naturalWidth and naturalHeight properties should interact. The css-images level 3 spec says: The intrinsic height and width are derived from the rotated rather than the original image dimensions.” The HTML spec says: The IDL attributes naturalWidth and naturalHeight must return the intrinsic width and height of the image, in CSS pixels, if the image is available, or else 0.” On the surface, it seems clear that image-orientation must affect naturalWidth/Height. However, I’m not sure whether this was intended, and I don’t have a strong intuition for whether this is more or less surprising to content authors than having these two features be totally independent. There is certainly a potential performance cost if the two features do interact, since that means that naturalWidth/Height will depend on style information. On the other hand, naturalWidth and naturalHeight would definitely take EXIF orientation into account if we respected it by default, so perhaps they also should when content authors opt in to EXIF orientation support using image-orientation. Let me know what you think. That's a good question. I suspect that .naturalWidth/Height should return the image's dimensions before applying CSS rotations. This is likely to be surprising, but also probably the correct answer for separation-of-concerns reasons. I wonder whether I need to tweak Images, or Hixie needs tweak img. Hmm. ~TJ
