Hopefully a straightforward question, but what colour space should a gprim’s displayColor default to? I assume sRGB given that is the norm for all other colour channels in USD if otherwise unspecified.
I’d like to know where you got sRGB, @dhruvgovil ? We’re in a bit of an intermediate documentation state right now, but until the introduction of UsdColorSpaceAPI, we had documented that in the absence of any specification, the fallback colorspace was linRec709, and that is still the presumed colorspace in the absence of any property colorSpace metadata or applied UsdColorSpaceAPI’s.
We’ll try to fill the documentation gap asap.
Ah, admittedly I haven’t gotten up to speed yet with the ColorSpaceAPI, but I don’t see that explicitly called out in the docs?
Grepping for rec709, the only mention I see is The default constructor creates black, in the "lin_rec709" space but I don’t believe it had language saying that extended elsewhere.
I assumed that it followed the behaviour of the pre-colorSpaceAPI logic, where textures defaulted to sRGB for sourceColorSpace if the auto mode couldn’t infer something else.
But thanks for the clarification. It’s good to know its officially linRec709
Ahhh… yes textures were a bit different; that fallback was a nod to the fact that our initial texture support for usdz was primarily jpg and png, and in the absence of any other information, you probably want to assume 8 bit textures require the srgb transfer function (although as Nick points out, we don’t actually infer a colorSpace from that…).
But for scene-referred colors, we want a linear space, and rec709 still seems the conservative choice. You are correct that ColorSpaceAPI’s doc does not explicitly mention the scene-wide fallback of linRec709, though it’s what we’ve been intending for awhile now (what, you couldn’t read our minds???).
Like I said, we’ll clarify that at least in the API docs somewhere for 25.05, with more comprehensive user-level documentation coming at some point soon this year.
Great, thanks for the extra clarity!