[x3d-public] [...] Gamma Correction for X3D4 final draft

[Don Brutzman]

Yes agreed that our slowly converging understanding of gamma correction possibilities is good news... but for now, it is only an enabler for potential experimentation in X3DJSONLD and for further development in our various other implementations.

Clearly we will not achieve any kind of meaningful new specification capabilities at this point without further exploration, implementation and evaluation.

In response to your other points, no we don't put anything in the spec about "unhandled" (unspecified) nodes... That is because X3D is indeed extensible, but we only define what is correct and let browser software handle problems in their own way.  On rare occasions we acknowledge the possibility of model error but the most we ever might say is "results are undefined" to avoid defining any specific error-handling responses.

So for gamma correction, we are definitely not changing any requirements or solutions in X3D4 draft specification (soon to be voted upon by Web3D Consortium members).

There are 2 spec choices below: acknowledging norms by simply stating that gamma correction is typically expected, or else continuing to say nothing.

I expect that we will confirm consensus and pick either choice 1 or choice 2 during our planned X3D4 finalization meeting next Friday.

Again thanks for considering the possibilities.


On 11/27/2020 5:37 PM, John Carlson wrote:
> 
> The good news is we can achieve desired results IN X3DJSONLD.   We just need to put in the spec that unhandled nodes are ignored/logged.
> 
> My current problem is going back through all my examples and adding a node.   A bit onerous and I don’t think I want to do it.
> 
> Possible solution.   Put in a hack into X3dToJson.xslt which will be carried through X3DJSONLD.   Also hack JSON schema generator, or just fail validation and let user deal with it.
> 
> None of these hacks have a savory feeling.
> 
> Ugh!
> 
> John
> 
> On Fri, Nov 27, 2020 at 12:51 PM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
> 
>     We've had much discussion about gamma over many years.
> 
>     * Wikipedia: Gamma correction
>     https://en.wikipedia.org/wiki/Gamma_correction <https://en.wikipedia.org/wiki/Gamma_correction>
> 
>     It seems like we have good shared understanding about what gamma correction means for 3D scenes.  Nevertheless with each round of review, we have not yet converged on a single consensus approach for exposing control of gamma correction to scene authors.  Insufficient time remains to resolve this issue fully in X3D4.
> 
>     As A simplistic summary, two general approaches have been proposed:
>     - Environment node (with design refinements and implementation additions likely in the future)
>     - Configuration file (hard to deploy, beyond authors' reach but perhaps suitable for diverse devices.
> 
>     Whether or not an image texture is gamma corrected seems to be a separate matter; if authors apply or remove gamma correction, typically that is upstream in authoring process (and perhaps only performed as a "hack" to adjust a scene).
> 
>     We might expect that considerations regarding gamma correction becomes increasingly significant in the future as a variety of VR/AR/XR devices become available.  Correspondingly it is not yet feasible to consider all of the potential emerging use cases for X3D gamma correction in these new domains.  And so, waiting until sometime next year might actually be a good strategy for now.
> 
>     The X3D specification is silent about gamma correction.
> 
>     Meanwhile it would seem that authors and browser builders deserve at least an indicator regarding expectations. Our apparent alternatives over the next week:
> 
>     ---
> 
>     1. Suggested: state something like
> 
>          "In general, for consistent presentation, the rendering of X3D scenes is usually expected to include gamma correction."
> 
>     This sentence might be added to
>     * X3D Architecture, 12 Shape component, 12.2.2 Appearance characteristics
>     https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/shape.html#AppearanceCharacteristics <https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD3/Part01/components/shape.html#AppearanceCharacteristics>
> 
>     ---
> 
>     2. Have X3D4 specification remain silent.
> 
>     ---
> 
>     Opposition or improvements to option 1 are welcome.  Thanks for considering the possibilities.
> [...]

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