[whatwg] Add "naturalOrientation" property to <img>

[Ian Hickson]

On Fri, 26 Aug 2011, Tab Atkins Jr. wrote:
>
> Some cameras (sometimes automatically, sometimes through an option) 
> record the orientation of the camera when a picture was taken.

Also things like geolocation, camera settings, etc.


> Webapps that manipulate images need to have the ability to tell when an 
> image should be rotated before being displayed, like desktop 
> image-manipulation software has.

And access other EXIF data, presumably, again for the same reasons that 
desktop software does (e.g. the way iPhoto puts photos on a map).


On Fri, 26 Aug 2011, Mark Callow wrote:
> 
> When EXIF orientation is present in the JFIF/EXIF file, I would hope the 
> browser would apply it whenever decoding the file and creating the image 
> object. If it does so , there should remain relatively few cases where 
> the webapp needs to read the image's natural orientation.

On Fri, 26 Aug 2011, Tab Atkins Jr. wrote:
>
> Browsers ignore the EXIF Orientation tag, and by now I suspect that's 
> needed for web-compat.

On Fri, 26 Aug 2011, James Salsman wrote:
>
> Maybe someone should ask the browser vendors how many img formats they 
> support and what the code footprint memory overhead would be for adding 
> rotation support for those which are likely to need it at whatever 
> confidence level you feel is appropriate.

On Fri, 26 Aug 2011, Peter Kasting wrote:
> 
> Auto-rotating images in the browser is controversial for reasons that 
> mostly boil down to web compat, not code footprint. WebKit-on-iOS does 
> it and AFAIK few others do.

(And this causes web compat issues. I'm surprised they still do it.)


On Fri, 26 Aug 2011, Tab Atkins Jr. wrote:
> 
> We don't have any APIs for manipulating files on your hard-drive

Actually now we do, to some extent.


> I wouldn't be opposed to exposing more EXIF data, but the Google Gears 
> API only exposed mimetype (which is irrelevant for image editing in 
> canvas), natural width and height (already exposed as naturalWidth and 
> naturalHeight), and orientation. Exposing the rest of the data would 
> just need use-cases to justify it.

My recommendation would be to just expose all the EXIF data in a generic 
manner, e.g.:

   var d = img.exif.SubjectArea;
   if (d) switch (d.length) {
     case 2: showSubjectPoint(d[0], d[1]); break;
     case 3: showSubjectCircle(d[0], d[1], d[2]); break;
     case 4: showSubjectRectangle(d[0]-d[2]/2, d[1]-d[3]/2, d[2], d[3]); break;
   }

The possible members of the "exif" object would be those given in the EXIF 
specification. Only those actually present in the image data would be 
present in the object. The values would depend on the field; for those 
whose type is "ASCII" (2) it would be a string, for all the others it 
would be an array. In the case of "RATIONAL" (5) and "SRATIONAL" (10) it 
would be an array of arrays, the inner arrays all having two members that 
are numbers. All other types would just be numbers, with "UNDEFINED" (7)
treated as "BYTE" (1).

Is this something browser vendors would be interested in implementing?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'