Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Wed, Apr 16, 2014 at 8:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Apr 16, 2014 at 3:45 PM, Justin Novosad ju...@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
Re: [whatwg] canvas drawImage and EXIF orientation metadata
On Thu, Apr 17, 2014 at 2:46 AM, Jonas Sicking jo...@sicking.cc wrote: 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. The question was why is this a CSS style instead of a property on img, not why isn't this just the default. -- Glenn Maynard
[whatwg] BroadcastChannel should support structured clones
It would be very useful to be able to send structured data, including Blobs, through the BroadcastChannel API. This is something we've seen any time we've done storage or message passing, that one of the first thing authors ask for is to not have to do JSON serialization/parsing manually. The ability to pass ArrayBuffers and Blobs is somewhat less commonly asked for, likely because binary data is less often used, but seems important nonetheless. We can't allow transferring of objects, since you can't transfer something to all listeners of a broadcasting API. But plain structured clones should be no problem to support conceptually (though more work to implement of course). We've started looking at doing structured clone support for Firefox and likely won't ship until we have that implemented. / Jonas
Re: [whatwg] BroadcastChannel should support structured clones
Another thing that seems like an oversight in the spec is that the spec currently says that BroadcastChannel should be exposed in Window context. We should also expose it in Worker contexts. / Jonas On Thu, Apr 17, 2014 at 2:32 PM, Jonas Sicking jo...@sicking.cc wrote: It would be very useful to be able to send structured data, including Blobs, through the BroadcastChannel API. This is something we've seen any time we've done storage or message passing, that one of the first thing authors ask for is to not have to do JSON serialization/parsing manually. The ability to pass ArrayBuffers and Blobs is somewhat less commonly asked for, likely because binary data is less often used, but seems important nonetheless. We can't allow transferring of objects, since you can't transfer something to all listeners of a broadcasting API. But plain structured clones should be no problem to support conceptually (though more work to implement of course). We've started looking at doing structured clone support for Firefox and likely won't ship until we have that implemented. / Jonas
