[Bug 12444] Canvas rendering should be done in linear color space (gamma 1) and the result displayed in sRGB color space (approximately gamma 2.2)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12444

--- Comment #4 from Hugues De Keyzer <w3c@hugues.info> 2011-04-14 20:12:57 UTC ---
(In reply to comment #3)
> The change you are asking for has color management implications, which is why a
> discussion of the implicit color space of a canvas element is relevant.

Yes, of course. I just wanted to point out that it is not limited to color
management.

> It seems odd to ask for a floating point linear gamma representation of canvas
> pixels - only to output the result via sRGB? Why the arbitrary clamp?

A linear floating point color data representation represents the “best”
possibility in terms of quality. This is what is used thoroughly now in
computer graphics. For example, one of the most used file formats to store
rendered images is OpenEXR, which stores pixel data in 16-bit floating point.
Most high-end video games do all their rendering in floating-point off-screen
textures that are composited and post-processed before being displayed in 8-bit
sRGB.

Storing image data in floating-point has actually two advantages. The first
advantage is precision. Because floating-point numbers have a precision that is
relative to their value, they are very well suited for storing logarithmic
values, and light intensity is perceived as logarithmic by the human visual
system. The precision advantage is why I am recommending floating-point here
(if possible).

The second advantage is the possible range of values. Floating-point numbers
are not limited to a range from 0 to 1 (or 0 to 255). They can be thousands of
times higher than 1, and even negative. Now, what is the point of such values,
when displayed values will anyway be between 0 and 1? Indeed, the final result
will have values between 0 and 1, but because image pixels are used in
computations (blending, etc.), such values are important as intermediate
values. With only values clamped between 0 and 1, (1 + 1) / 2 would be equal to
0.5 instead of 1, because no intermediate result higher than 1 can be stored.
This can give ugly results. Fading out a picture containing out-of-range
highlights (such as a picture of a landscape where the sun is visible) will
make these highlights appear gray, while they should stay bright white. Take a
look at the 4th OpenEXR sample picture (a desk in front of tainted glass) on
the bottom of this page: http://www.openexr.com/samples.html. It represents the
same image where values are scaled down. This would be impossible to do with
values clamped between 0 and 1. These high dynamic range features are actually
out of the scope of the subject of my first message, but if we really want the
best possible results, they should be considered.

> This would a large architectural change for user agents; canvas elements would
> use a lot more memory and render slower.

Yes, indeed. That is why I propose the alternative method where conversions are
done on-the-fly. This would require less memory but would be actually probably
more CPU-intensive. Lookup tables can possibly be used to accelerate these
operations. Ideally, this should be implemented in hardware.

> > In either case, all rendering operations should be done
> > in linear space, preferably in floating-point.
> The author can do this with sRGB-to-linear conversions, if the color space of
> the canvas is known or assumed to be sRGB - IOW authors do create linear gamma
> drawing operations by calculating the 'correct' color values themselves.

Indeed, some computations can be done “manually”. What I propose is that the
results would be good “by default”. Most programmers are unaware of these gamma
problems. Currently, simply drawing a circle or text gives wrong antialiasing
(try with fuchsia on a green background, you get dark edges). Same thing for
linear gradients (going from red to green shows a dark part in the middle).
Same thing for everything actually, even if it not always obvious to detect. It
would clearly be better if users had not to worry about it and get good
results, optionally bypassing the system if they want more control.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 14 April 2011 20:13:01 UTC