[x3d-public] [...] Gamma Correction for X3D4 final draft
John Carlson
yottzumm at gmail.com
Fri Nov 27 17:37:25 PST 2020
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> wrote:
> 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
>
> _______________________________________________
> 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/20201127/fadea2ce/attachment-0001.html>
More information about the x3d-public
mailing list