[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 2:42 PM, Chris Marrin <email@example.com> wrote:
> On Sep 6, 2010, at 7:21 PM, Mark Callow 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 <firstname.lastname@example.org> 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
>> 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. 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.
>> 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.
> I believe our task in conditioning the image for use by the HTML compositor is simply to convert it (if necessary) into sRGB space. That is at least what the WebKit compositor expects, and it does any further conversion into device space from there. If those downstream conversions are not correct, that's not our problem, it's a browser problem. Some browsers may indeed do that incorrectly, but we shouldn't be trying to fix that.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: