[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] The Newly Expanded Color Space Issue



On Wed, Sep 8, 2010 at 5:48 PM, Chris Marrin <cmarrin@apple.com> wrote:
>
> It's time to bring this issue to a conclusion. We can't make WebGL programs correct, and we can't tell authors that we will only accept mathematically correct WebGL programs. What we CAN do is to give authors sufficient tools (given the current constraints) to give them the flexibility to do what they want with WebGL. As Adrienne and I have pointed out the only things we can do are:
>
> 1) Manipulate the color space of images being loaded with texImage2D. Choices are:
>
>        a) Convert all images to sRGB always
>        b) Convert all images to Linear always
>        c) Give a choice of which conversion to perform
>
> (with all choices, we also need a way to turn off all conversion and get raw pixels into the engine)

All I strongly care about is 1d (raw mode).  1a is a nice-to-have.  1c
is unnecessary but it doesn't offend me, especially if someone else
does the work.

> 2) Manipulate the color space of the drawing buffer as it is composited with the page. Choices are:
>
>        a) Always convert the drawing buffer as if it is sRGB into the device color space used by the compositor
>        b) Always convert the drawing buffer as if it is Linear into the device color space used by the compositor
>        c) Give a choice of which conversion to perform

I vote for 2a.  I don't particularly like 2c but again, if someone
else does the work it doesn't offend me.

I have an additional meta-point I'd like to make in favor of my preferences.

WebGL has operated to date on a simple and powerful guiding principle
-- bring OpenGL ES 2.0 to Javascript.  This has involved compromises
and additions in a few places, but in terms of decision making, ES 2.0
(and the relevant web standards on the other side) have been solid
focusers and guides towards what stands to be an excellent,
performant, coherent and well-specified result.

On this particular question, while it's true that ES 2.0 itself does
not specify a color space, it's also true that practically all
implementations in the real world write into sRGB device framebuffers.
 This situation is the result of conventional practice based on many
years of real world experience, coupled with sound engineering
tradeoffs.  OpenGL ES 2.0 is not perfect -- people have correctly
pointed out its (effectively) nonlinear blending and sampling behavior
under certain conditions.  So I understand the impulse to polish off
this minor blemish.

But there are other slight blemishes in OpenGL, not to mention design
decisions that might have been better taken differently.  Fortunately,
the WebGL group has kept revisionism at bay, and largely resisted the
urge to redesign what is already proven to work well.

I look at a linear output framebuffer for WebGL as the kind of
standards-group rethink that the group has successfully and admirably
avoided to date.  Technically, it's not based on any OpenGL ES 2.0
implementation experience, or any web standard.  In my opinion as a
graphics engineer, it has academic benefit but very little practical
merit.  I've sought out contrary evidence and contrary opinions, and
found very little to support it.  It's almost entirely a navel-gazing
paper exercise.

It is a poster child for a proposal that should be excluded from WebGL
1.0 and reconsidered for an extension if someone cares enough to take
it up.

-T

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: