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

Thu Sep 21 09:58:52 PDT 2023

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230921/9e2dc5bb/attachment-0001.html>