Clarifying sRGB sourceColorSpace values

[dgovil]

In the Documentation for USD Shade, it mentions

sRGB : Mark texture as sRGB when reading.

We're trying to tighten up our understanding of colour and had a few questions. The answers to which could probably be beneficial to add to the docs themselves.

1. Does sRGB describe the transfer curve, or also the gamut of the image?
2. Are the values in sourceColorSpace case sensitive? OCIO colorSpace names are case-sensitive, so it would be nice if USD specified the same.

Thanks for any extra light you can shed on this.

[tallytalwar]

Filed as internal issue #USD-8043

[syoyo]

1. Does sRGB describe the transfer curve, or also the gamut of the image?

After reading up stbImage.cpp, sourceColorSpace is used in OpenForReading, and sRGB is used only for gamma(the transfer curve).

https://github.com/PixarAnimationStudios/USD/blob/release/pxr/imaging/hio/stbImage.cpp

For oiioImage.cpp plugin, sourceColorSpace is not used when reading an image data.

https://github.com/PixarAnimationStudios/USD/blob/release/pxr/imaging/plugin/hioOiio/oiioImage.cpp

So no way to describe color gamut in sourceColorSpace, at least in UsdUVTexture schema.
(If we want to specify gamut of the texel value, we'll need to add metadatum to sourceColorSpace attribute).

[syoyo]

2. Are the values in sourceColorSpace case sensitive? OCIO colorSpace names are case-sensitive, so it would be nice if USD specified the same.

Apparently pxrUSD(hdSt) uses case-sensitive token for sourceColorSpace like other token values. +1 for staying case-sensitive color space names in USD!

[spiffmon]

Thanks for the research, @syoyo ! I'm not sure exactly how Storm does it (I suspect through the use of GetFormat() which factors in srgb-ness, but the hdPrman rtx_glfImage plugin uses IsColorSpaceSRGB() to decide whether to linearize or not, so it's OK that the oiioImage plugin does not directly apply sourceColorSpace itself.

Two things to note are that our hope is to largely deprecate the need for sourceColorSpace by providing Hydra-level support for USD's colorSpace metadata and other cms configuration data. I think the reason we chose to explicitly add sourceColorSpace was to explicitly indicate that it wasn't as general or expressive as an OIIO colorSpace... it's really just talking about gamma, though I do note that the specification does not clearly state that.

The other thing is how much we do want to state about colorSpace, which is largely meant to be compatible with colorspaces as specified by MaterialX. I just reread the color management section of the Mtlx spec, and it explicitly does not define too closely what colorspaces or color transforms mean, deferring instead to whatever CMS is specified. BUt given that for all intents and practical purposes, that is OCIO, I wonder if more can or should be said? @dgovil , @jstone-lucasfilm, possibly a topic for an upcoming ASWF usd-materialx working group session?

[jstone-lucasfilm]

This is a great question, and thanks for looping me into the conversation, @spiffmon.

MaterialX inherits its default set of color spaces from the ACES 1.2 standard, and the srgb_texture color space in MaterialX uses the rec709 color primaries with the sRGB transfer function. We're clarifying the language around color spaces in MaterialX 1.39, and here's a section of the proposed specification:

By default, MaterialX supports the following color spaces as defined in ACES 1.2 (http://www.oscars.org/science-technology/sci-tech-projects/aces), and applications rendering MaterialX documents are expected to transform input colors and images from these spaces to the color space of their renderer. One straightforward option for providing this support is to leverage MaterialX code generators, which support these transforms automatically, but applications may use any appropriate means to handle the transforms on their own.

• srgb_texture
• lin_rec709
• g22_rec709
• g18_rec709
• acescg
• lin_ap1 (alias for "acescg")
• g22_ap1
• g18_ap1
• lin_srgb

[dgovil]

Thanks guys. I'll relay that to our folks here and follow up with more if needed.