- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 17 Apr 2014 00:46:55 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Justin Novosad <junov@google.com>, whatwg <whatwg@lists.whatwg.org>, Boris Zbarsky <bzbarsky@mit.edu>
On Wed, Apr 16, 2014 at 8:09 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad <junov@google.com> wrote: >> I was wondering the same thing. From the image-orientation spec: "It applies >> only to content images (e.g. replaced elements and generated content), not >> decorative images (such as background-image)." >> So this property apparently has a considerably larger scope than just >> correcting the orientation of images from files, which I guess explains why >> it is in CSS. > > I don't really follow the reasoning. But I guess if this has been > shipping in Firefox for a while we might be out of luck changing this. The problem here stemms from that orientation data lives as "metadata" in the EXIF data of image formats. This means that many tools has simply ignored that metadata. The result seems to have been that people open their images in tools that ignore the EXIF metadata. Then rotates the pixel data using that tool. Then saves the image again while keeping the EXIF metadata unchanged. This now means the pixels have been rotated (say) 90 degrees, but the EXIF metadata still says "rotate image 90 degrees". So any tool that now honors the EXIF renders the picture *wrong*. So effectively the EXIF metadata has to be ignored in order to keep webcompat. That was the case even before image-orientation was implemented. FWIW I believe that WebP is remaking this same mistake. Would be cool if someone tried to prevent this from happening. / Jonas
Received on Thursday, 17 April 2014 07:47:56 UTC