[x3d-public] X3DOM Documentation: Gamma Correction

Tue Sep 1 12:42:33 PDT 2020

I'm sorry for the last really long email, long even for my standards :) And
yes, I did screw the numbering at the end :)

I put that long text on a wiki page:
https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D
.

Regards,
Michalis

wt., 1 wrz 2020 o 21:35 Michalis Kamburelis <michalis.kambi at gmail.com>
napisał(a):

> 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/c6d6b715/attachment-0001.html>