[x3d-public] X3DOM Documentation: Gamma Correction
J. Scheurich
mufti11 at web.de
Wed Sep 2 15:35:37 PDT 2020
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
>
More information about the x3d-public
mailing list