[x3d-public] Need for colorspaceConversion field in ImageTexture, glTF compatibility

Thu Sep 21 19:18:18 PDT 2023

Hi Don,

Good points on our overarching design objectives. I agree that availability
of libraries should not drive design decisions to a large extent.

With regards to related standards, fidelity of color reproduction is such a
minefield that it would be wise to only address what is absolutely
necessary, for example for glTF compatibility. I think it may be
unavoidable to accept a certain degree of fuzziness. It might be possible
to come up with smart framing along the lines that x3d is color space
agnostic in the sense that the x3d output color space is the same as the
input color space. The only color space which is fully supported is sRGB
(not sure what this implies), Color computations assume linear color space
but browsers automatically convert. Embedded color profiles are supported.

I think this was another reason glTF decided to ignore embedded color
profiles. It removes a source of potential ambiguity (should sRGB be
applied twice? Probably not). It keeps things simpler.

-Andreas

On Thu, Sep 21, 2023 at 8:09 PM Brutzman, Donald (Don) (CIV) <
brutzman at nps.edu> wrote:

> Thanks for great analysis, Andreas.
>
> At this point, I would only add that our design objective is to enable
> authors to achieve the highest possible quality renderings, consistently
> across every platform, regardless of whether the software libraries used by
> an underlying implementation are capable of matching the correct result in
> the current version. Note that this approach is also testable, checkable
> and repeatable when an off-line  renderer produces a reference image.
>
> If we pay careful attention to all related standards and specifications,
> it seems like this is the best modeling solution that results in correct
> quality for models using our archival standard
>
> Have fun with X3D! 😎
>
> v/r Don
> ------------------------------
> *From:* Andreas Plesch <andreasplesch at gmail.com>
> *Sent:* Thursday, September 21, 2023 12:58:52 PM
> *To:* Brutzman, Donald (Don) (CIV) <brutzman at nps.edu>
> *Cc:* Holger Seelig <holger.seelig at yahoo.de>; Michalis Kamburelis <
> michalis.kambi at gmail.com>; puk Richard <puk at igraphics.com>; X3D <
> x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Need for colorspaceConversion field in
> ImageTexture, glTF compatibility
>
>
> NPS WARNING: *external sender* verify before acting.
>
> I dug deeper into the motivation of why glTF ignores embedded color
> profiles and found this in an earlier glTF spec. draft:
>
>
> https://github.com/KhronosGroup/glTF/blame/7420e21a23feee17831f07a682275967c755ec7f/specification/2.0/Specification.adoc#L1386
>
> So the motivation appears to be that while it is possible to ignore such
> profiles in webGL without too much effort, some image libraries on some
> platforms cannot deal with such embedded color profiles.
>
> Thus, ignoring embedded profiles is the lowest common denominator.
>
> Note that the latest glTF spec. does not contain this explanation,
> probably because it is not essential.
>
> The same argument could be made for X3D as evidenced by view3dscene which
> I believe uses image libraries which do not apply embedded color profiles.
>
> On the other hand, traditionally other X3D browsers do apply embedded
> color profiles as this is what an author most likely intended.
>
> In other words there would be no large need for explicitly defining how
> images are decoded but glTF translation to X3D now requires it anyways.
>
> Here is a list of items to address for X3D 4.1 candidature:
>
> - agree on field name "colorSpaceConversion"
> - agree on signature: probably only init, eg. there is no use case for
> [in,out]
> - agree on text: draft "The SFBool colorSpaceConversion field determines
> if color profile information embedded in the source asset/image file is
> applied to raw image colors (TRUE), or is ignored (FALSE)."
> - MovieTexture: not aware if standard movie formats also can embed color
> profile information, or if WebGL can ignore those. Let's focus only on
> ImageTexture.
>
> Found this:
> https://video.stackexchange.com/questions/6902/do-video-formats-support-colour-profiles;
> mp4 can request a decoder to use one out of a list of standard color
> profiles. But X3D may just have to rely on browsers doing their best.
>
> Note that embedded profiles only make sense for image textures intended to
> carry actual color information. For textures intended to carry other
> information (normals, etc.), it is the responsibility of the authors to
> prepare such images suitably (eg. without embedded profiles). Thus, there
> is no need for further clarification in the spec.
>
> The same is true for gamma correction. It does not make sense to apply
> gamma correction to textures carrying data other than color/grey scale
> information. Thus there is no expectation by authors that gamma correction
> is applied to such data textures, and thus no need for clarification.
>
> There may be other color space related clarifications for the spec. . For
> example, the lighting equations typically assume that the input colors are
> given in a linear color space. So there may be a requirement to convert
> from source color space (typically sRGB) to linear color space and then
> after lighting to an output color space (typically also sRGB) (which a
> rendering device may further convert to a device calibrated color space).
> But this may be out of scope for X3D and could be left to browser behaviour.
>
> Any feedback or thought always welcome,
>
> Andreas
>
> On Thu, Sep 21, 2023 at 7:42 AM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
> Hi Don,
>
> Here is the relevant glTF reference:
>
> https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#images
>
> "Any colorspace information (such as ICC profiles, intents, gamma values,
> etc.) from PNG or JPEG images *MUST* be ignored. Effective transfer
> function (encoding) is defined by a glTF object that refers to the image
> (in most cases it’s a texture that is used by a material)."
>
> There may be an github issue discussing this decision as well.
>
> Best regards,
>
> Andreas
>
> On Thu, Sep 21, 2023, 6:54 AM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> Thanks for an interesting candidate capability.  Some references:
>
>
>
>    - Wikipedia: Color space
>    - https://en.wikipedia.org/wiki/Color_space
>
>
>
>    - Wikipedia: List of color spaces and their uses
>    - https://en.wikipedia.org/wiki/List_of_color_spaces_and_their_uses
>
>
>
> From glTF 2.0
>
>
>
>    - 3.9.3. Additional Textures
>    - emissive : The emissive texture and factor control the color and
>    intensity of the light being emitted by the material. The texture MUST
>    contain 8-bit values encoded with the sRGB opto-electronic transfer
>    function so RGB values MUST be decoded to real linear values before they
>    are used for any computations. To achieve correct filtering, the transfer
>    function SHOULD be decoded before performing linear interpolation.
>    -
>    https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#additional-textures
>    - References
>    - IEC 61966-2-1 *Default RGB colour space - sRGB*
>    https://webstore.iec.ch/publication/6169
>
> Note
>
> The encoding characteristics of sRGB are freely available from ICC:
> https://www.color.org/chardata/rgb/srgb.xalter
>
>    - (which is at International Color Consortium)
>
>
>
> Additional references welcome
>
>
>
> Each mention of color profile that I found in glTF indicated that SRGB
> profile usage was required.  Didn’t see any other options.  Wondering if
> there is further work in glTF extensions on this topic.
>
>
>
> Prior attempts to permit gamma definition in X3D did not converge on an
> acceptable solution.
>
>
>
> I did not find relevant mention of “color space” or “SRGB” in X3D 4.0
> specification.
>
>
>
> If we can align with other standards, particularly glTF evolution, then
> this field certainly seems like a candidate to become a Web3D Consortium
> Recommended Practice in anticipation of future X3D 4.1 Architecture.  No
> doubt we would want to look carefully across the specification to ensure
> that color was handled consistently and interoperably.
>
>
>
> Continued scrutiny and development welcome.  Have fun with X3D color
> control!  8)
>
>
>
> 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
> https://faculty.nps.edu/brutzman
>
>
>
> *From:* x3d-public <x3d-public-bounces at web3d.org> *On Behalf Of *Holger
> Seelig
> *Sent:* Thursday, September 21, 2023 3:06 AM
> *To:* Andreas Plesch <andreasplesch at gmail.com>
> *Cc:* X3D <x3d-public at web3d.org>
> *Subject:* Re: [x3d-public] Need for colorspaceConversion field in
> ImageTexture, glTF compatibility
>
>
>
> I have now also added the field `colorSpaceConversion` in X_ITE to the
> ImageTexture node, also in the same notation. Everything was already
> prepared for it.
>
>
>
> I can't show an example yet, because everything is still in the dev branch.
>
>
>
> The signature of the new field looks like this:
>
>
>
> SFBool [] colorSpaceConversion TRUE
>
>
>
> Best regards,
>
> Holger
>
>
>
> --
>
> Holger Seelig
>
> Leipzig, Germany
>
>
>
> holger.seelig at yahoo.de
>
> https://create3000.github.io/x_ite/
>
>
>
> Am 21.09.2023 um 08:26 schrieb Andreas Plesch <andreasplesch at gmail.com>:
>
>
>
> Coming back to color profiles potentially embedded in some important
> image formats, I added a colorSpaceConversion field to ImageTexture in
> x3dom:
>
>
> https://andreasplesch.github.io/x3dom/dist/doc/author/Texturing/ImageTexture.html
>
> It is by default true for normal X3D use and can be false for loading
> glTF textures correctly:
>
>
> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/817bc44089a7b7545149cf12acdd7c86/raw/75242ebfea03048d0f4939e1656c5063c9544d11/TextureEncodingTest.x3d
>
> It is trivial to change the field name if there are other suggestions.
>
> -Andreas
>
> On Tue, Aug 29, 2023 at 1:53 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>
> Following up after some work:
>
> On Thu, Aug 24, 2023 at 11:15 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>
> On Thu, Aug 24, 2023 at 9:14 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
>
>
> 1. As for colorspaceConversion:
>
> I don't think we want to avoid adding X3D field for this :)
>
>
> Well, it is worth thinking through options if it means smarter
> solutions can be discovered.
>
>
> I'm all after adding X3D field to account for this -- that is, say
> explicitly whether ICC profile should be honored or not, so that all
> cases are satisfied. I'm cool with colorspaceConversion name.
>
>
>
> ...snip
>
> After some thought I do think that a new field is needed for
> ImageTexture (and MovieTexture, and Background ?).
> "colorspaceConversion" or "colorSpaceConversion" or perhaps something
> shorter like "colorProfile"  ?
>
> x3dom will probably use the webgl texture unpacking parameter.
>
>
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>

-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230921/56eead41/attachment-0001.html>