Closed andreasplesch closed 1 year ago
I was a bit wrong, because Safari always does gl.UNPACK_COLORSPACE_CONVERSION_WEBGL
with gl.NONE
, which is what has to be done to get the right rendering behavior.
glTF ignores ICC color profiles and custom gamma in images, but not X3D.
images SHOULD NOT contain ..., or embedded ICC profiles. Such features, if present, MUST be ignored by client implementations.
Here is a example image with custom ICC color profile:
Either we should always do gl.UNPACK_COLORSPACE_CONVERSION_WEBGL
with gl.NONE
(what Safari always does), or ImageTexture should have a new field colorspaceConversion
(think this is the right capitalization).
I haven't found anything in X3D spec about textures and ICC color profiles:
Thank you for the investigation. Probably time to ask on x3d-public for guidance. I can do that.
Let's see if there is a response on x3d-public.
I remembered why I did not focus on that at the time. It is clear that the test glTF asset in the issue and the image used in the comments have unrealistic, extreme ICC profiles which is not a fair representation. For most textures the problem would be subtle. So this is not an urgent problem. Also, authors can always decide to use images without embedded profiles.
But there is a problem if pixel accurate glTF rendering with exact colors is a goal.
Castle renders the test correctly:
It converted the gltf to this x3d: textureencodingtest.zip
The x3d has the textures converted to giant PixelTextures without the ICC applied.
So that could be an option but it is not practical for larger images.
https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer renders the Texture Encoding Test as:
but the reference image at https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/2.0/TextureEncodingTest is:
x3dom has the same issue https://github.com/x3dom/x3dom/issues/1258.