Re: [whatwg] Colour correction (was: Canvas ImageData comments)
On Jan 21, 2008, at 01:36, Maciej Stachowiak wrote: On Jan 20, 2008, at 11:03 AM, Henri Sivonen wrote: On Jan 20, 2008, at 19:58, Darin Adler wrote: I think the sRGB design is a good one. I disagree. Why would you want a brand new Cinema display emulate the gamut of an office CRT from the previous millennium potentially by clipping instead of stretching the colors to gamut of the device at hand? Wouldn't changing the default gamma have essentially the same effect (with the added difference that even profile-tagged images could not take advantage of wider gamut)? Gamma correction maps the [0.0, 1.0] range to [0.0, 1.0], so it doesn't make the available range of color narrower or wider--it just affects the spacing of the available values within the range. If compatibility considerations were absent, the Mac default gamma would have merit, since it gives the light color range more precision whereas the TV/Windows legacy gamma wastes precision in the dark range. However, if the common case (the Web) lives in sRGB, which isn't the Mac native gamma, doing the color space conversion not only takes away the supposed benefit of the Mac default gamma *and* adds the loss of precision caused by the inevitable rounding in the conversion. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
[whatwg] Canvas bits
The ImageData object's width is greater than zero. (and subsequent lines) is wrong, since it's talking about an object that's explicitly not an ImageData. What happens with NaN in imagedata.data? (NaN is a Number, so it's allowed in the data array. It's not below 0, or above 255, and it can't be rounded to the nearest integer.) Note: The transformation is applied to the path when it is drawn - oh no it isn't. -- Philip Taylor [EMAIL PROTECTED]
[whatwg] putImageData
I was just doing some putImageData tests last night, and found that firefox does not allow putImageData to specify a target that extends beyond the bounds of the canvas. Given that getImageData can request bounds that extend beyond the canvas region (3.14.11.1.10) I would expect to be able to use putImageData in a similar manner, eg. canvas.putImageData(canvas.getImageData(-50,-50,200,200), -50, -50) should succeed. I'd just like the spec to state clearly that this should (or, i suppose, should not :( ) work as Expected, and allow putImageData to work as getImageData does. --Oliver
[whatwg] pushstate + hashchanged
Pushstate looks great, but with it a new need arises. When the user changes the
path in the locationbar, reload is triggered. It should not, as to match the
behavior of the hash change. Instead, just an event should be dispatched.
Something like hashchanged or popstate event, I'm not sure. Which portion of the
path should cause reload and which should not ('cause is supposedly managed by
javasript) would be configurable by a new property, e.g. something like
document.basePath.
So what do you think?
Ivan Vim
