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

Don Brutzman brutzman at nps.edu
Fri Nov 27 10:50:25 PST 2020 

We've had much discussion about gamma over many years.

* Wikipedia: 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

---

2. Have X3D4 specification remain silent.

---

Opposition or improvements to option 1 are welcome.  Thanks for considering the possibilities.



On 9/2/2020 9:14 AM, Michalis Kamburelis wrote:
> Subject: Re: X3DOM Documentation
>
> """For example, shapes with a PhysicalMaterial
> could use a linear color space, while other shapes could use a srgb
> space.""" --- and this is exactly what Castle Game Engine is doing by default now:)
> 
> It makes nice backward compatibility, so we didn't break how the existing assets look like suddenly. But indeed it is more complicated than just "apply gamma always" like X3DOM.
> 
> I agree that choice whether to use gamma or not should be possible inside X3D file, so it warrants additional node. The scene author knows how the assets were prepared.
> 
> So I'm all after Environment node like X3DOM. I think the only difficult decision here is "what should be default" :)
> 
> Regards,
> Michalis
> 
> W dniu śr., 2.09.2020 o 18:05 Andreas Plesch <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> napisał(a):
> 
>     One, I think important, reason to allow a scene author to choose gamma
> 
>     correction for a scene with a node such as Environment or field value
> 
>     is that only the author knows how colors and textures in the scene are
> 
>     supposed to be used. Only the author knows if colors provided in the
> 
>     scene are defined for a linear color space or a srgb color space.
> 
> 
> 
>     Another, unrelated, question is if it should be possible to allow
> 
>     mixed use of color spaces. For example, shapes with a PhysicalMaterial
> 
>     could use a linear color space, while other shapes could use a srgb
> 
>     space. That means, instead of a global gamma correction field, there
> 
>     could be a field with a more local scope. This is a larger change and
> 
>     perhaps too complex.
> 
> 
> 
>     -Andreas
> 
> 
> 
>     On Wed, Sep 2, 2020 at 11:25 AM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
> 
>      >
> 
>      > Thanks Michalis and everyone for renewed scrutiny on gamma and SRGB.
> 
>      >
> 
>      > Meanwhile a small point: we don't need to worry about the potential burden of adding another node (i.e. Environment).
> 
>      >
> 
>      > There is already a modest number of global capabilities that are defined in Scene Access Interface (SAI).  So gamma correction options can be hung in there somewhere.  If ever needed by an author (likely rare) they might nevertheless access the property via Script node.
> 
>      >
> 
>      > ==============================
> 
>      > Extensible 3D (X3D) Part 2: Scene access interface (SAI)
> 
>      > 6.3 Browser services
> 
>      >
> 
>      > https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#BrowserServices <https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#BrowserServices>
> 
>      >
> 
>      > 6.3 Browser services
> 
>      > 6.3.1 Introduction
> 
>      > 6.3.2 getName
> 
>      > 6.3.3 getVersion
> 
>      > 6.3.4 getCurrentSpeed
> 
>      > 6.3.5 getCurrentFrameRate
> 
>      > 6.3.6 getSupportedProfiles
> 
>      > 6.3.7 getProfile
> 
>      > 6.3.8 getSupportedComponents
> 
>      > 6.3.9 getComponent
> 
>      > 6.3.10 getExecutionContext
> 
>      > 6.3.11 createScene
> 
>      > 6.3.12 replaceWorld
> 
>      > 6.3.13 importDocument
> 
>      > 6.3.14 loadURL
> 
>      > 6.3.15 setDescription
> 
>      > 6.3.16 createX3DFromString
> 
>      > 6.3.17 createX3DFromStream
> 
>      > 6.3.18 createX3DFromURL
> 
>      > 6.3.19 updateControl
> 
>      > 6.3.20 registerBrowserInterest
> 
>      > 6.3.21 getRenderingProperties
> 
>      > 6.3.22 getBrowserProperties
> 
>      > 6.3.23 changeViewpoint
> 
>      > 6.3.24 print/println
> 
>      > 6.3.25 dispose
> 
>      > 6.3.26 setBrowserOption
> 
>      >
> 
>      > ==============================
> 
>      > Extensible 3D (X3D) Part 2: Scene access interface (SAI)
> 
>      > 6 Services reference, 6.3.26 setBrowserOption
> 
>      >
> 
>      > https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#setBrowserOption <https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#setBrowserOption>
> 
>      >
> 
>      > parameters:     SAIBrowserRef, SAIString, SAIObject
> 
>      > returns:        SAIBoolean
> 
>      > errors: SAI_INVALID_OPERATION_TIMING
> 
>      > events: None
> 
>      > buffered:       No
> 
>      > external:       Yes
> 
>      >
> 
>      > The setBrowserOption service allows setting options defined in 9.2.4 Browser options in ISO/IEC 19775-1. The name field shall be one of the defined names in Table 9.2 in ISO/IEC 19775-1. This service shall return an SAIBoolean value indicating whether the change request was successful. A browser is not required to support dynamic changes to any options. If a browser option is not supported, a value of FALSE shall be returned.
> 
>      >
> 
>      > ==============================
> 
>      > Extensible 3D (X3D) Part 2: Scene access interface (SAI)
> 
>      > 6.4 Execution context services
> 
>      >
> 
>      > https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#ExecutionContextServices <https://www.web3d.org/documents/specifications/19775-2/V3.3/Part02/servRef.html#ExecutionContextServices>
> 
>      >
> 
>      > 6.4 Execution context services
> 
>      > 6.4.1 getSpecificationVersion
> 
>      > 6.4.2 getEncoding
> 
>      > 6.4.3 getProfile
> 
>      > 6.4.4 getComponents
> 
>      > 6.4.5 getUnits
> 
>      > 6.4.6 getWorldURL
> 
>      > 6.4.7 getNode
> 
>      > 6.4.8 createNode
> 
>      > 6.4.9 createProto
> 
>      > 6.4.10 namedNodeHandling
> 
>      > 6.4.11 getProtoDeclaration
> 
>      > 6.4.12 protoDeclarationHandling
> 
>      > 6.4.13 getExternProtoDeclaration
> 
>      > 6.4.14 externprotoDeclarationHandling
> 
>      > 6.4.15 getRootNodes
> 
>      > 6.4.16 getRoutes
> 
>      > 6.4.17 dynamicRouteHandling
> 
>      > 6.4.18 dispose
> 
>      >
> 
>      > ==============================
> 
>      >
> 
>      > On 9/1/2020 12:42 PM, Michalis Kamburelis wrote:
> 
>      > > 9. [...] 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.
> 
>      > [...]
> 
>      >
> 
>      > all the best, Don
> 
>      > --
> 
>      > Don Brutzman  Naval Postgraduate School, Code USW/Br brutzman at nps.edu <mailto: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 <http://faculty.nps.edu/brutzman>
> 
> 
> 
> 
> 
> 
> 
>     -- 
> 
>     Andreas Plesch
> 
>     Waltham, MA 02453
> 

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

More information about the x3d-public mailing list