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

Thu Sep 21 17:09:40 PDT 2023

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:andreasplesch at gmail.com>>
Cc: X3D <x3d-public at web3d.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:andreasplesch at gmail.com>> wrote:

On Thu, Aug 24, 2023 at 9:14 AM Michalis Kamburelis
<michalis.kambi at gmail.com<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230922/dee88141/attachment-0001.html>