- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 26 Aug 2011 14:45:22 -0700
On Fri, Aug 26, 2011 at 11:10 AM, Mark Callow <callow_mark at hicorp.co.jp> wrote: > On 11/08/26 10:03, Tab Atkins Jr. wrote: >> On Fri, Aug 26, 2011 at 9:57 AM, Glenn Maynard <glenn at zewt.org> wrote: >>> Rather than baking magic EXIF constants into the API, would it make more >>> sense to translate to degrees? >> Possibly. ?However, 4 of the EXIF orientations (2, 4, 5, and 7) are >> "unnatural" orientations that require mirroring the data as well as >> rotating it. >> >> We'd also need to decide whether the reported rotation is how much it >> differs from upright or the rotation needed to return it to upright >> (the difference between 90deg and -90deg). >> > The EXIF constants do not represent a degree of rotation. They describe > how the rows and columns of the image data map to the top and bottom of > the image so more flexible in some ways, as evidenced by the possible > "unnatural" orientations, and less flexible in others. I'll avoid arguing nomenclature; we're describing the same thing. > 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. But I have no > objection to such a property being added. Browsers ignore the EXIF Orientation tag, and by now I suspect that's needed for web-compat. You can test your browser by visiting <http://www.xanthir.com/etc/exif/> if you'd like. ~TJ
Received on Friday, 26 August 2011 14:45:22 UTC