[x3d-public] X3DOM Documentation: Gamma Correction

Tue Sep 1 11:27:08 PDT 2020

I was very upset when X3DOM apparently diverged (or did X_ITE diverge), and
despite applying recommended (?) fixes, the visual appearances were
strikingly different between X3DOM and X_ITE.   I think I had learned
helplessness or something, and I dropped the issue.   It’s great that
another champion has taken up the challenge.

Adding Holger so he is aware.

John

On Tue, Sep 1, 2020 at 11:44 AM Don Brutzman <brutzman at nps.edu> wrote:

> 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
>
>
>
> _______________________________________________
>
> 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/20200901/b2f51f34/attachment-0001.html>