[whatwg] Colour correction (was: Canvas ImageData comments)

[Arne Johannessen]

Philip Taylor wrote on January 18th, 2008:
> 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 :-)

It's worthwhile to think about what colour spaces are for:

Colour correction tries to solve a simple problem: Alice wants to  
send an image to Bob, but their screens are not guaranteed to show  
the same colour when presented with the exact same RGB triple, so Bob  
might not be seeing the same image Alice does.

The solution to this problem is obvious: Both Alice and Bob have  
their screen's properties measured. Alice sends her screen's  
properties along to Bob, who can then transform the image to fit his  
screen's properties.

This whole measuring business is rather expensive. It's necessary  
even today in many cases when you want to print stuff with accurate  
colours, but on the web, it's far easier: Alice transforms her image  
to a "standard" colour space before sending it to Bob, tweaking the  
actual RGB triples such that the image still "looks right" to her.  
The effect still is the same for Bob though: He gets an image and is  
informed of the properties of the screen that would make this image  
"look right".

At this point, Bob can make this image "look right" on his screen / 
if/ he knows his screen's properties (a. k. a. colour space). If he  
was a professional print designer, he might know them. But most web  
users aren't.

Some consumer-oriented operating systems make it possible to  
"calibrate" one's screen, i. e. to estimate it's properties through  
an heuristic interactive process. Few users that I've known ever go  
through this trouble. Most don't even know what this "colour  
calibration stuff" is all about.

Now, for web pages, this whole mess enters the next level: Unlike  
images, they consist of colours coming from multiple sources,  
including legacy HTML, CSS, scripts and HTML-embedded images. In  
order for colour correction to be of any use, /all/ of these colour  
sources need to be properly tagged!



I'm not sure where all of this leads us. I mean, we can't expect that  
the authors tag all their colours, but neither can we expect all  
users to calibrate their screens.

This entire colour correction problem seems to be too big for this  
spec to handle. Having said that, we need to specify a sensible  
behaviour for user agents that doesn't prevent this problem to be  
handled in other places (perhaps the operating system, perhaps some  
future spec, ...).

Opinions are welcome.

Perhaps I have time next week to check out what current browsers  
actually do today. From past experience I expect that it's not  
consistent in every situation; I recall some serious trouble working  
with Safari in particular.



> [...]
>
> 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.

Yeah, that sounds good: There should be no colour conversion in  
normal method calls. Not sure how to make that work well with regards  
to the operating system though.

> [...] And I have no idea if this is trivial for implementors, or if  
> it's impossible. So I don't have any useful suggestions.

Same here, at least at this time.

-- 
Arne Johannessen