On Tue, May 13, 2014 at 6:59 PM, K. Gadd <k...@luminance.org> wrote: > On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <caban...@gmail.com> wrote: > > Can you give an explicit example where browsers are having different > > behavior when using drawImage? > > I thought I was pretty clear about this... colorspace conversion and > alpha conversion happen here depending on the user's display > configuration, the color profile of the source image, and what browser > you're using. I've observed differences between Firefox and Chrome > here, along with different behavior on OS X (presumably due to their > different implementation of color profiles). > > In this case 'different' means 'loading & drawing an image to a canvas > gives different results via getImageData'. > > On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <caban...@gmail.com> wrote: > > Would this be solved with Greg's proposal for flags on ImageBitmap: > > > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-June/251541.html > > I believe so. I think I was on record when he first posted that I > consider the alpha and colorspace flags he described as adequate. > FlipY is considerably less important to me, but I can see how people > might want it (honestly, reversing the order of scanlines is a very > cheap operation; you can do it in the sampling stage of your shader, > and actually *have* to in OpenGL because of their coordinate system > when you're doing render-to-texture.) > > On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <caban...@gmail.com> wrote: > >> Very specifically here, by 'known color space' i just mean that the > >> color space of the image is exposed to the end user. I don't think we > >> can possibly pick a standard color space to always use; the options > >> are 'this machine's current color space' and 'the color space of the > >> input bitmap'. In many cases the color space of the input bitmap is > >> effectively 'no color space', and game developers feed the raw rgba to > >> the GPU. It's important to support that use case without degrading the > >> image data. > > > > > > Is that not the case today? > > It is very explicitly not the case, which is why we are discussing it. > It is not currently possible to do lossless manipulation of PNG images > in a web browser using canvas. The issues I described where you get > different results from getImageData are a part of that. > > On Mon, May 12, 2014 at 4:44 PM, Rik Cabanier <caban...@gmail.com> wrote: > > Safari never created a temporary image and I recently updated Firefox so > it > > matches Safari. > > Both Safari, IE and Firefox will now sample outside of the drawImage > region. > > Chrome does not but they will fix that at some point. > > This is incorrect. A quick google search for 'webkit drawimage source > rectangle temporary' reveals such, in a post to this list. > > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/080583.html > My statement to this effect was based on my (imperfect) memory of that > post. 'CGImage' (to me) says Safari since it's an Apple API, and the > post mentions Safari.
I made a codepen that showed the issue: http://codepen.io/adobe/pen/jIzbv Firefox was not matching the behavior on mac because it created a intermediate image. I fixed that in https://bugzilla.mozilla.org/show_bug.cgi?id=987292 I agree that the code you linked to exists in WebKit but they add padding so it samples outside the source again.