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

Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D



On Tue, Sep 7, 2010 at 4:21 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>
> On 06/09/2010 18:54, Thatcher Ulrich wrote:
>> I agree with virtually everything you said, except for two important
>> points, see comments below:
>>
>> On Mon, Sep 6, 2010 at 4:42 AM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
>>> ...
>>>
>>> Since we don't have blend shaders the only way to do this correctly is to
>>> create another renderbuffer and do another pass over the data.
>> Actually, an app author can do this directly in their fragment shader.
>>  Just do "gl_FragColor = pow(linear_rgb, 1.0 / 2.2);" at the end of
>> the shader.  When/if WebGL exposes EXT_framebuffer_sRGB, the hardware
>> can do this more cheaply (and perhaps more exactly) using a lookup
>> table.
>
> Subsequent blending and anti-aliasing will then be mathematically and
> visually incorrect. Blending and especially anti-aliasing must be done
> in a physically linear space.

You say they "must" be done in a physically linear space, and yet in
practice no system works this way unless EXT_*_sRGB are enabled, or
unless the shaders are written to work around this.

> Doing what you suggest is only correct if
> blending is disabled or is blend equation and func are set such that the
> destination is replaced by the source color.

Yes -- sorry to be the bearer of bad news.  EXT_*_sRGB are designed to
correct this.

> which brings me back to something I wrote:
>> I'm still very focused on native GL applications. Since GL does not
>> have blend (compositing mode) shaders  an extra pass is needed to "fix
>> gamma using a shader in the compositing stage." This will cause a
>> performance drop compared to rendering directly to a window surface.
>> But as you point out, WebGL is already performing this extra pass to
>> composite the canvas with the other page contents and it makes a great
>> deal of sense to perform color space conversion during that pass.
>
> I have to take this back. Unless the compositing being done by the
> browser involves only "replace" then another pass is required after
> blending/compositing to convert to the display color space otherwise the
> result is incorrect.

Browsers should use EXT_*_sRGB when possible.  Browsers could
alternatively carefully write their compositing shaders to do this in
an extra pass using sRGB as inputs and output.  Browsers should not
pass their data through linear 888 in an effort to solve this problem;
the cure would be worse than the disease.  And finally, browsers that
do compositing in software probably should not even worry about this
problem, because the software-based fixes are expensive.  (In fact,
most browsers currently ignore this issue and thus do things
"incorrectly".)

-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: