On Fri, Aug 26, 2011 at 11:10 AM, Mark Callow <[email protected]> wrote: > On 11/08/26 10:03, Tab Atkins Jr. wrote: >> On Fri, Aug 26, 2011 at 9:57 AM, Glenn Maynard <[email protected]> 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
