[x3d-public] X3DOM Documentation: Gamma Correction

[Don Brutzman]

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