hello_xr colors/non-linearity seems to be ill-defined and inconsistent, especially across different swapchain formats and headsets about openxr-sdk-source HOT 5 OPEN

Thanks for the thorough report.

Yeah I always think of it as being a weird Windows 95 desktop green, but I usually get funny looks when I say that 😅 I have no idea in whose universe "dark slate grey" is a sickly green, but fortunately naming colors is not my job.

Yeah I think with "linear unless otherwise specified", it tends to be mostly non-linear, because we do say "do not use linear 8bit per channel unless absolutely required".

We do test all the texture formats but we don't attempt to interactively render in all of them for perceptual comparison. (I suppose this would be easy enough to add, though making the test more usable and clear for pass vs failure might be tricky). I did think we had some linear vs gamma/srgb-eotf tests in the composition but presumably if we do, they miss this. I do know there are headsets out there where I see different interactive tests look different, which I have tracked internally as a conformance failure, but I didn't realize it was as widespread of a problem as you're showing.

(Note that hello_xr is not actually the conformance test, but the conformance tests do tend to look a lot like it in the interactive portions, including sharing the same color definitions.)

from openxr-sdk-source.

Did an additional test on Quest 2 and Quest3: They are perceptually identical to the Quest Pro for GL_RGBA16F and GL_SRGB8_ALPHA8.

from openxr-sdk-source.

An issue (number 2238) has been filed to correspond to this issue in the internal Khronos GitLab (Khronos members only: KHR:openxr/openxr#2238 ), to facilitate working group processes.

This GitHub issue will continue to be the main site of discussion.

from openxr-sdk-source.

Thanks for the thorough report.

Yeah I always think of it as being a weird Windows 95 desktop green, but I usually get funny looks when I say that 😅 I have no idea in whose universe "dark slate grey" is a sickly green, but fortunately naming colors is not my job.

Yeah I think with "linear unless otherwise specified", it tends to be mostly non-linear, because we do say "do not use linear 8bit per channel unless absolutely required".

We do test all the texture formats but we don't attempt to interactively render in all of them for perceptual comparison. (I suppose this would be easy enough to add, though making the test more usable and clear for pass vs failure might be tricky). I did think we had some linear vs gamma/srgb-eotf tests in the composition but presumably if we do, they miss this. I do know there are headsets out there where I see different interactive tests look different, which I have tracked internally as a conformance failure, but I didn't realize it was as widespread of a problem as you're showing.

(Note that hello_xr is not actually the conformance test, but the conformance tests do tend to look a lot like it in the interactive portions, including sharing the same color definitions.)

Super appreciated, and yeah the issue writeup was kinda broad only because I wasn't sure if I was looking at a hello_xr-specific issue, a CTS issue, or a spec specificity issue, and the more I looked the more confused I got 😅. I figured the perceptual screenshots would help at least kickstart some kind of conversation needed to resolve it in any case.

from openxr-sdk-source.

Currently looking into this.

KhronosGroup/OpenXR-CTS#20 may be relevant. Looks like it was noticed that sRGB was incorrect on the CTS on OpenGL, so sRGB formats were excluded from selection. This lends credence to the idea that hello_xr is at least partially at fault here, as the CTS rendering code is (seemingly) derived from hello_xr.

from openxr-sdk-source.