[x3d-public] X3DOM Documentation: Gamma Correction

[J. Scheurich]

Am 02.09.2020 um 13:51 schrieb Andreas Plesch:
> I checked to see if the SRGB colorspace is included in webgl. It is,
> as an extension in webgl1 and by default in webgl2.
>
> Here is the documentation of the extension:
>
>
> https://www.khronos.org/registry/OpenGL/extensions/EXT/EXT_sRGB.txt
>
>
> It has an explanation and a slightly more sophisticated formula to
> convert between linear and srgb colorspaces.
>
> I think the reason for breaking backward compatibility in x3dom by
> turning on gamma correction was that other 3d content pipelines do the
> same, eg. generate colors and textures supposed to be used that way,
> and to help push x3d forward. At the time, I thought this is a bit
> premature but now in 2020 it may be ok.
>
> Andreas
>
> ---on the phone---
>
> On Wed, Sep 2, 2020, 7:27 AM Michalis Kamburelis
> <michalis.kambi at gmail.com <mailto:michalis.kambi at gmail.com>> wrote:
>
>     I guess the question from Patrick was more about the "S" letter in
>     GL_SRGB vs GL_RGB :) Not about the "A" letter.
>
>     And grepping the latest White Dune source code -- as far as I can
>     see, you do not use GL_SRGBA. You use a variant without "S", that
>     is GL_RGB (when no alpha) or GL_RGBA (when alpha).
>
>     Sure a texture with alpha channel has to use a version with "A"
>     suffix, so GL_SRGBA or GL_RGBA.
>
>     Using GL_SRGB (or GL_SRGBA) means that OpenGL takes care of
>     converting the values from texture into linear space. IOW, the
>     point 2.2. from description on
>     https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D
>     , """To use the image as a texture (that multiplies e.g. the
>     "diffuse" light factor), you need to get back physical value from
>     images""" -- this point can be done by hardware if you use the
>     format with "S" in the name. It is described e.g. in
>     https://www.khronos.org/opengl/wiki/Image_Format#sRGB_colorspace .
>
a senrnvr on zhis webpae:
Colors accessed from textures via GLSL samplers undergo filtering, based
on sampler properties
<https://www.khronos.org/opengl/wiki/Sampler_Object>. However, filtering
is a linear process, while the sRGB colorspace is a non-linear
colorspace. So filtering in the sRGB colorspace does not result in
reasonable values

>
>     Castle Game Engine (right now) doesn't use the format with "S", we
>     use regular GL_RGB / GL_RGBA, and we do "pow(xxx, 2.2)" is GLSL
>     code. So it's not a problem if we apply gamma in one case, and not
>     apply it in other -- we just use a different shader variant. The
>     texture data is the same.
>
>     I know that the same goes for glTF sample implementation (see here
>     for their implementation:
>     https://github.com/KhronosGroup/glTF-Sample-Viewer/blob/master/src/shaders/tonemapping.glsl
>     ).
>
>     And the same goes for X3DOM. They apply the proper operation in
>     the shader (depending on "Environment.gammaCorrectionDefault").
>
>     So, nobody (from above 4 implementations) is using the format with
>     "S" in the name.
>
>     And Patrick, you make an excellent point here: using the format
>     with "S" in the name is a *good* idea. And it is easily possible
>     only if the specification has an extremely simple rule: "apply
>     gamma correction always" (otherwise you would need to use
>     different texture formats, depending on whether your material node
>     indicates gamma or not).
>
>     Thank you for this insight!
>
>     I also agree with John -- it does seem counter-intuitive that you
>     would need "Environment" node to have consistent gamma treatment
>     in all browsers.
>
>     That said, I'm still left with one problem -- if we just say in
>     the spec """X3D browsers should just apply gamma correction,
>     always, unconditionally""" then we have lots of benefits
>     (simplicity, consistency with glTF) but one big drawback -- we
>     break compatibility in case of browsers that didn't implement
>     gamma correction before. All the X3D models, tested on X3D
>     browsers without gamma, will suddenly look different, as we would
>     change how "Material" effectively looks (how it is mixed with a
>     diffuse texture).
>
>     Opinions welcome :) I'm still at the cross-roads, what is the best
>     way ahead :)
>
>     Regards,
>     Michalis
>
>     śr., 2 wrz 2020 o 11:57 J. Sheurich <mufti11 at web.de
>     <mailto:mufti11 at web.de>> napisał(a):
>
>
>         On 2020-09-02 11:41, Patrick Dähne wrote:
>         > Hi Michalis,
>         >
>         >> 7. Castle Game Engine by default applies gamma correction
>         on PhysicalMaterial, and *does not* apply gamma correction on
>         Material or UnlitMaterial.
>         > Ok. Let’s say you have something like that:
>         >
>         > Shape {
>         >    appearance Appearance {
>         >      material Material {
>         >        texture DEF tex ImageTexture {
>         >          url "foo.png"
>         >        }
>         >      }
>         >    }
>         >    geometry Box {}
>         > }
>         >
>         > Shape {
>         >    appearance Appearance {
>         >      material PhysicalMaterial {
>         >        baseTexture USE tex
>         >      }
>         >    }
>         >    geometry Box {}
>         > }
>         >
>         > What’s the internal OpenGL texture format of the
>         ImageTexture?  GL_RGB or  GL_SRGB?
>         >
>         a png-file can have alpha information, therefore it would be
>         logical to
>         have GL_SRGBA for .png and .gif
>
>         white_dune uses GL_SRGBA ....
>
>         so long
>
>         MUFTI
>
>
>
>         _______________________________________________
>         x3d-public mailing list
>         x3d-public at web3d.org <mailto:x3d-public at web3d.org>
>         http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>