[x3d-public] X3DOM Documentation: Gamma Correction

[Michalis Kamburelis]

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 .

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> 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
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200902/532d8581/attachment-0001.html>