-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Images used by textures with different color spaces? #2308
Comments
+1 |
Doing this is probably unusual, but I think it is valid. @lexaknyazev What do you think? For reference, if you load the two models in the referenced glTF-Transform issue in Babylon.js sandbox, they look the same before and after. |
Hello, |
I just checked Babylon viewer and indeed they look the same, |
I think you mean the sandbox doesn't use EXT_sRGB formats. If so, yes, by default, we have this turned off because of a Chromium issue. If you use https://3dcommerce.babylonjs.com, it will use EXT_sRGB formats. The result is the same though. |
FWIW, three.js has moved to use While investigating support for wide gamut colorspaces in WebGL and three.js, I've encountered an issue that might be relevant here. Images are unpacked by WebGL into a target color space identified by As a result — I think the glTF specification's current advice about ignoring ICC Profiles is still reasonable, however, I do not believe we should be encouraging situations where the embedded ICC Profile cannot possibly be accurate, as would be the case when the image contains mixed data from different color spaces. EDIT: Perhaps this is something the validator should try to warn about? |
By definition, glTF 2.0 textures use only ITU-R BT.709 primaries. Detecting and rejecting assets that have something else may be very difficult because differently encoded ICC profiles may define the same color space (e.g., precomputed LUTs vs parameter-based built-in functions). |
@lexaknyazev What I mean is that the textures embedded in a glTF 2.0 asset might not be the only textures that a client implementation is loading. We might have textures from other sources, properly identified in some other color space. In that situation, we cannot simply disable The case that I think we might want to detect and reject would be, for example, if a glTF 2.0 asset contains a texture that is used both for But even then, this is probably a minefield. How should a |
This is clearly out of scope of the glTF spec.
Pixel values from non-color textures, e.g., occlusion, normal, roughness, etc, must be used as-is, i.e., ignoring any color primaries or transfer function information. So they must be uploaded with all color space related conversions disabled. Pixel values stored in color textures referred from a glTF 2.0 asset must use BT.709 color primaries and sRGB transfer function. If the current display uses, e.g., Display-P3 primaries, it's an engine's responsibility to ensure correct look.
This is not explicitly disallowed (although could be a validation warning). An engine may have to upload the texture twice in this case using different options since both |
I feel that a validation warning for “textures used both for baseColorTexture and for occlusionTexture” would be a good thing. I don't think any other action, or changes to the spec, are being requested in this thread. |
The spec discusses image color spaces under Images, Section 3.8.3:
I believe this implies that the same texture object cannot be associated with multiple color spaces, and so cannot be used both as a
baseColorTexture
andocclusionTexture
. Would it be valid for the same image object to be used by two textures in those material slots?I've run into a question in glTF Transform, where it merges two identical textures, resulting in a color space difference in three.js (which expects 1 color space per glTF texture), and I'm not sure which is correct.
The text was updated successfully, but these errors were encountered: