[whatwg] Canvas ImageData comments

[Philip Taylor]

On 18/01/2008, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 16 Jun 2007, Philip Taylor wrote:
> >
> > Colour spaces are not dealt with at all, but are particularly relevant
> > for getImageData (else you have no idea what the values mean).
>
> Fixed, in theory. But since I have no idea what I'm talking about here,
> you'll have to check closely to make sure I didn't babble incoherently.

I don't know much about colour spaces either, so someone else should
check that it's sane :-)

> > maybe it's safest to just say that all colours throughout the canvas API
> > must be handled consistently in the same colour space (without saying
> > exactly which it is).
>
> Wouldn't that mean that different browsers could have different effects
> when rendering external images -- with gamma -- to the canvas?

I guess so; and things like gradients wouldn't work consistently if
the colour space wasn't consistent.

Maybe the desired properties are:
- drawImage(<img>) onto a displayed <canvas> should look the same as
the original <img>, regardless of whether the image has gamma etc.
- toDataURL should return the same raw pixel data as getImageData, at
least for image/png (though other formats might make that impossible),
for consistency.
- drawImage(toDataURL()) should have no effect.

I'd also like:
- fillStyle = 'rgb(r, g, b)'; fillRect(...); getImageData returns
exactly [r, g, b, 255].
mainly because that makes it possible to write test cases that use
getImageData to check the results.

I don't know if any of these are wrong, or if others are missing. And
I have no idea if this is trivial for implementors, or if it's
impossible. So I don't have any useful suggestions.

> > "The putImageData(image, dx, dy) method must take the given ImageData
> > structure, and draw it at the specified location dx,dy in the canvas
> > coordinate space, mapping each pixel represented by the ImageData
> > structure into one device pixel." - how should it 'draw it'? Given the
> > requirement on putImageData(getImageData(...)), it has to be replacing
> > the pixels in that area rather than doing anything like normal drawing,
> > but that isn't explicit.
>
> Is it better now?

It looks clear enough to me.

> > In the example code:
> > [...]
> > "function FillCload(data, x, y) { ... }" - should be "function
> > FillCloud(data, x, y) { ... }".

That error was replaced with "function AddCload(data, x, y) { ... }" - s/a/u/

> > "The width and height (w and h) might be different than the sw and sh
> > arguments to the function" - 'different than' sounds a bit odd to me
> > here; maybe I'd prefer 'different from'.

Oops, I was wrong to mention that - 'different than' seems to be
common in some Englishes, and I don't want to complain when it's just
dialect variations.

-- 
Philip Taylor
excors at gmail.com