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

Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved



Recap of sRGB functionality

The EXT_sRGB extension provides native support for the sRGB color format. sRGB is a non-linear color format, and most picture source data that WebGL will encounter will be encoded in it (such as jpeg, or PNGs with the sRGB color profile), additionally most display devices that WebGL will run on, will assume colors to be output in sRGB. More information about that format can be had here http://en.wikipedia.org/wiki/SRGB and here http://www.color.org/srgb.pdf

A simple implementation of sRGB in a shader looks like this:

vec3 gamma(vec3 color){
    return mix(
        color * 12.92,
        1.055*pow(color, vec3(1.0/2.4)) - 0.055,
        step(0.0031308, color)
    );
}

vec3 degamma(vec3 color){
    return mix(
        color/12.92,
        pow((color + 0.055)/1.055, vec3(2.4)),
        step(0.04045, color)
    );
}

However there are some problems in supporting sRGB this way manually.
EXT_sRGB was introduced to solve these problems, and it solves them in the following fashion:
ES 3.0 supports sRGB in the core, the specification follows the same semantic as EXT_sRGB, in that:
Direct3D

The ability to perform degamma before read and gamma before write is present in Direct3D 9, specifically:
See more information here: http://msdn.microsoft.com/en-us/library/windows/desktop/bb173460(v=vs.85).aspx

Angle gating

I don't think an extension should be Direct3D angle gated from community approved if the following conditions are met:
These conditions seem to be met for sRGB, barring any objection to this assertion to follow.

This working principle is the same as was adopted for gating features on mobile functionality, where if those conditions where not met, an extension could not proceed. Quite a few extensions which didn't have mobile support at the time, made it to community approved on the grounds that it was agreed that the extension was necessary, that implementations of it exist that pass the unit tests and that a good portion of mobiles can support that extension. So I don't see a reason to provide preferential treatment to Direct3D angle in that regard.



On Wed, Jun 11, 2014 at 1:46 AM, Zhenyao Mo <zmo@chromium.org> wrote:
To be clear, I am not against this specific extension for WebGL 1.

If anyone is willing to implement it in ANGLE for ES2, then definitely yes.


On Tue, Jun 10, 2014 at 4:44 PM, Zhenyao Mo <zmo@chromium.org> wrote:
It is not to tie WebGL to ANGLE, but whatever we implement, it should be supported on all major platforms.  If an extension doesn't have the potential to be supported on Windows, then maybe we should not support it at all.


On Tue, Jun 10, 2014 at 4:19 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:

Why? WebGL as a spec should not be gated on ANGLE, even if sometimes we get de facto blocked on the translator. If UAs are able to support an agreed-upon extension in the absence of ANGLE-D3D-backend support, should it be possible to promote from Draft? Apple, in particular, has no interest in the D3D backend, and neither do two of Mozilla's products.

In general, WebGL2 has a bunch of differences regarding how the internalFormat==format invariant no longer exists in ES3. sRGB won't be the only area with this issue.

-Jeff

----- Original Message -----
From: "Kenneth Russell" <kbr@google.com>
To: "Jeff Gilbert" <jgilbert@mozilla.com>
Cc: "Florian Bösch" <pyalot@gmail.com>, "public webgl" <public_webgl@khronos.org>
Sent: Tuesday, June 10, 2014 3:18:59 PM
Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved

>From my standpoint it's a requirement that ANGLE expose the extension
in its ES 2.0 backend before the EXT_sRGB WebGL extension be moved to
community approved status. Shannon Woods from the ANGLE team has
pointed out an essential difference between EXT_sRGB and ES 3.0's
built-in sRGB functionality, which is that EXT_sRGB exposes sRGB
texture formats, while ES 3.0 exposes sRGB texture internal formats.
This might only be a minor issue to address but it needs to be
investigated. I've filed
https://code.google.com/p/angleproject/issues/detail?id=672 about it.

-Ken


On Tue, Jun 10, 2014 at 2:51 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
> Interesting, I was just wondering about this. FWIW, implementation of extensions that are core in WebGL 2 shouldn't be much of a burden, since the mechanisms are similar in WebGL2 and the extensions. Internally, we use basically the same paths for the extension as our WebGL2 implementation.
>
> -Jeff
>
> ----- Original Message -----
> From: "Florian Bösch" <pyalot@gmail.com>
> To: "Kenneth Russell" <kbr@google.com>
> Cc: "public webgl" <public_webgl@khronos.org>
> Sent: Monday, June 9, 2014 9:18:59 PM
> Subject: Re: [Public WebGL] Re: EXT_sRGB and EXT_frag_depth to community approved
>
> I think EXT_sRGB should be moved to community approved with all due haste
> so as to avoid Mozilla having to retract their implementation, and so that
> iOS can include the functionality.
>
> These devices support EXT_sRGB natively.
>
> - iPad 2
> - iPad 3
> - iPad 4
> - iPhone 4s
> - iPhone 5
> - iPhone 5C
> - iPhone 5s
> - iPad Air
> - iPad mini (and retina)
> - iPod touch 5th gen
> - Xiaomi MiniPad
> - Samsung SM-G870
>
> But these devices are not OpenGL ES 3.0 compatible:
>
> - iPad 2
> - iPad 3
> - iPad 4
> - iPhone 4s
> - iPhone 5
> - iPHone 5C
> - iPod touch 5G
>
> Of These, the following are iOS8 compatible:
>
> - iPad 2
> - iPad 3
> - iPad 4
> - iPhone 4s
> - iPhone 5
> - iPhone 5C
> - iPod touch 5G
>
> If EXT_sRGB is dropped in favor of WebGL2, it means that Apple could not
> include support for it in iOS8. That would mean that until Apple appears
> with a WebGL2 implementation, sRGB will not be available on the the iPhone
> 5s, iPad Air and iPad mini. But worse, it would never be available on the
> iPad 2, iPad 3, iPhone 5s, iPhone 5, iPhone 5C and iPod touch 5G, which
> represent a sizable bulk (the majority?) of iOS devices in use, and cannot
> support WebGL2.
>
>
> On Tue, Jun 10, 2014 at 1:14 AM, Kenneth Russell <kbr@google.com> wrote:
>
>> It sounds like all implementers that have responded are in favor of
>> moving EXT_frag_depth to community approved. Thanks for pushing on
>> this. Merged your pull request.
>>
>>
>>
>> On Mon, Jun 9, 2014 at 3:34 AM, Florian Bösch <pyalot@gmail.com> wrote:
>> > Any progress on moving EXT_frag_depth to community approved?
>>

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