[x3d-public] X3DOM Documentation: Gamma Correction

Tue Sep 1 12:35:20 PDT 2020

Let me try to explain the "gamma correction" issue better (and I
emphasizing that my page tries to explain the issue properly :
https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
). Maybe this will help with some answers:

1. "Gamma correction" in the context of 3D rendering is important to make
lighting calculations correct.

2. Your monitor typically "distorts" the colors.

     2.1. When you take a photo with a camera, or when you prepare an image
in GIMP/Photoshop/Paint etc., you counteract this distortion, by making the
RBG values "inversely distorted". So the RGB values in images like PNG/JPG
*do not* correspond to physical values. They don't even "map linearly" to
physical values, because the "distortion" is non-linear.

    2.2. To use the image as a texture (that multiplies e.g. the "diffuse"
light factor), you need to get back physical value from images. Only then
you can sum and multiply these values in a way that is physically correct.

    2.3. And at the end, once lighting calculations are done, you should
again "inversely distort" the final color, because it has to be displayed
on a computer screen.

   The points 2.2. and 2.3. are something that has to be implemented in a
renderer in order to claim it "supports gamma correction". It's actually
fairly easy, again I refer you to
https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
.

3. The "distortion" I talk about above is actually just component-wise
power operation with a constant exponent. That is, "output = pow(input,
CONSTANT)" or (inverse) "output = pow(input, 1 / CONSTANT)".

4. In a perfect world, the point 2.2. above is implemented knowing the
exact CONSTANT of the monitor where the image was prepared (authored) or
the camera used to capture a photo. In practice, using the "CONSTANT = 2.2"
is good enough, as it is so common.

    Similarly, in a perfect world, the point 2.3. above is implemented
knowing the exact CONSTANT of the monitor where you render. In practice,
using the "CONSTANT = 2.2" is good enough, as it is so common.

    So, "perfect gamma correction" implementation, in theory requires
knowing your monitor specifics. But in practice, and in many actual
implementations, just assuming "CONSTANT = 2.2" is good enough (and more
visually correct than not doing any gamma correction).

4. Historically many rendering engines didn't care about this. Because it
was easier to ignore this issue (easier to implement, and faster to perform
by GPUs, as you just avoid doing something). I suspect (proof welcome) that
most X3D renderers except X3DOM and CGE do not apply gamma correction.

    Most new rendering systems support gamma correction, as an option.

    What should be the default? No gamma correction, or gamma correction
sometimes, or gamma correction always?

5. Using gamma correction with assets that have been prepared assuming "no
gamma correction" means that colors are bad. Likewise, not using gamma
correction with assets that have been prepared assuming "there is gamma
correction" is bad.

6. X3DOM applies gamma correction by default, always.
https://doc.x3dom.org/tutorials/lighting/gamma/ says
gammaCorrectionDefault=linear by default.

7. Castle Game Engine by default applies gamma correction on
PhysicalMaterial, and *does not* apply gamma correction on Material or
UnlitMaterial.

8. What is better, AD 6 or AD 7? I have no idea:)

    7.1. The bad consequence of AD 6 is that X3DOM changes how X3D models
look like (compared to other browsers that don't do gamma correction). Of
course it can be adjusted (using the Environment X3D node). The advantage
of this decision is consistency and correctness (with respect to how you
should calculate lighting) -- you just do it always.

    7.2. The bad consequence of AD 7 is inconsistency -- I apply gamma in
case of some material nodes, I don't apply gamma in case of others. See
https://castle-engine.io/manual_gamma_correction.php . Of course it can be
adjusted (using the view3dscene menu item, or Pascal variable
GammaCorrection = gcNever | gcPhysicalMaterial | gcAlways). The advantage
of this decision is backward compatibility: by default, models with Phong
Material render without gamma, which matches (I think) most other X3D
browsers (except X3DOM), and it matches CGE behaviour before gamma
correction was implemented.

8. Note that glTF says to apply it always. Thus, for perfect glTF
compatibility, a renderer should apply gamma at least to PhysicalMaterial
and UnlitMaterial. (For glTF compatibility, it doesn't matter what you do
on Phong Material.)

9. What to say in X3D spec? In my opinion, nothing, in X3D 4.0. We need to
talk and figure out what is best. Opinion from other browser implementors
is necessary to make a proper decision here, IMHO. I'm leaning toward

  Environment {
    SFString gammaCorrectionDefault "DEFAULT" # ["DEFAULT", "NONE",
"LINEAR"]
  }

  Where "DEFAULT" == browser-specific behaviour.

   So it is not a perfect solution (because we avoid specifying the
default), but it allows authors to force/disable gamma correction if
desired.

Regards,
Michalis

wt., 1 wrz 2020 o 18:43 Don Brutzman <brutzman at nps.edu> napisał(a):

> We discussed further on today's teleconference.
>
> The limited approach below attempts to say that gamma correction is
> important and should be applied if possible.
>
> The various approaches we've looked at in glTF and the following
> references all take extremely similar approaches, with the only difference
> being default values chosen (for example 2.2 versus 2.0).
>
> The following statements were not accepted (correct, incorrect or even
> ill-defined):
>
> - The application of gamma correction may be affected by the display
> hardware being utilized.  This is why an X3D scene author cannot uniquely
> define whether gamma is part of a given X3D model, it is (at least
> partially or sometimes) dependent on the external display hardware.
>
> - Another example was a camera might (or might not) apply gamma correction.
>
> - Can we define if gamma correction is preferred?  Or applied?  Or a giant
> mystery?
>
> I am unsatisfied that something so fundamental to presentation is also
> something that X3D has no opinion about, because it is too complicated.  We
> are better than that.  Silent acceptance of mysterious results seems
> insufficient.
>
> I suspect that path to some form of improvement lies through simplicity,
> not complexity.
>
> Recommendation:
> - define what we do know,
> - note that some things are difficult and the province of hardware and
> operating systems,
> - suggest that browsers consider gamma correction whenever appropriate.
>
> Thank you for discussing a difficult topic.  Hopefully we can add just a
> little value to X3D Architecture prose without making things worse.
>
> On 9/1/2020 9:18 AM, Don Brutzman wrote:
> > OK thanks.  If I follow your thinking completely, it sounds like we do
> not want to add to spec yet, rather keep it as a potential system feature.
> >
> > However, am not understanding rationale.  If gamma correction benefits
> and context and requirements and solution approaches are all well
> understood, why aren't we saying anything now in the X3D specification?
> >
> > In other words, what else would it take to add gamma considerations to
> X3D?  If X3D rendering is expected to be archival in nature, then it seems
> essential.  For starters, perhaps something as simple as
> >
> > ==================================================
> > * X3D Architecture, clause 11 Rendering component
> >    11.2.5 Gamma Correction
> >
> > Gamma correction is a nonlinear operation used to encode and decode
> luminance.
> >
> > Gamma encoding of images is used to optimize the usage of bits when
> encoding an image by taking advantage of the non-linear manner in which
> humans perceive light and color.
> >
> > It is recommended that X3D browsers support gamma correction for scene
> rendering whenever appropriate for the display device being used.
> >
> > ==================================================
> >
> > Also wondering if anyone has written a paper about X3D and gamma
> correction - not finding any.
> >
> > Another reference of interest, liberally paraphrased above:
> >
> > * Wikipedia: Gamma correction
> >    https://en.wikipedia.org/wiki/Gamma_correction
> >
> >
> > On 9/1/2020 2:55 AM, Michalis Kamburelis wrote:
> >>
> >> It's a great explanation of how and why gamma works in X3DOM :)
> >>
> >> It was an inspiration for my own reading about gamma (results on
> https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
> ) and finally implementation of gamma correction in Castle Game Engine (
> https://castle-engine.io/manual_gamma_correction.php ).
> >>
> >> Note that in CGE I made a bit different decisions than X3DOM:
> >>
> >> - In CGE, the default is different. We apply gamma by default only on
> PhysicalMaterial, and we don't apply it on Material and UnlitMaterial. Of
> course it can be changed (to apply gamma always -- compatible with X3DOM,
> or never). The explanation how and why is on
> https://castle-engine.io/manual_gamma_correction.php . I made such
> default behaviour to keep backward compatibility, otherwise introducing
> gamma in CGE would change the look of almost all existing models.
> >>
> >>      So, long story short: if you set in CGE "GammaCorrection :=
> gcPhysicalMaterial" (using code, or using view3dscene menu item) than CGE
> and X3DOM make 100% compatible gamma handling.
> >>
> >> - We don't yet support X3DOM "Environment" node (with
> "gammaCorrectionDefault" field) because there wasn't much need for it. CGE
> developers have a simple global variable to adjust it from Pascal. One day
> I'll add "Environment.gammaCorrectionDefault" support, but it's lower
> priority now.
> >>
> >> Regards,
> >> Michalis
> >>
> >> pon., 31 sie 2020 o 22:22 Don Brutzman <brutzman at nps.edu <mailto:
> brutzman at nps.edu>> napisał(a):
> >>
> >>     Michalis, wondering what you thought about this?
> >>
> >>     https://doc.x3dom.org/tutorials/lighting/gamma
> >>
> >>     "If you know what gamma correction is, you may just want to know
> that: Lighting in X3DOM can be gamma-correct or not, depending on the
> Environment node’s gammaCorrectionDefault field. RGB Colors and textures
> are assumed to be gamma coded. Intensities of all sorts are assumed to be
> linear. You can use gamma correction with the "gammaCorrectionDefault"
> attribute:" [...]
> >
> > all the best, Don
>
> all the best, Don
> --
> Don Brutzman  Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200901/fd87b60a/attachment-0001.html>