KhronosGroup / KhronosGroup/OpenXR-Docs
Color rendering is device-specific
- Dominant language
- Python
- Stars
- 181
- Forks
- 74
- PR merge metrics
- No merged PRs in 30d
Description
It seems that currently, there's no consistent way to distinguish which device somone is actually using (independent of the runtime in use). From what I've read there seems to be a consensus that such a behaviour is "by design", and that OpenXR should be beyond the idea of device-specific code paths.
However, I think this fails a reality check, namely, that different devices have vastly different characteristics in terms of colors. Vive, Vive Pro, Quest, Rift S all display very different brights and darks, with nuanced color differences across the supported color space.
These brightness and color differences cause issues in business cases, where perceptual color matches are very important for brand identities etc (if a company's midnight blue comes over as black or light blue depending on device, that's an issue for adoption of both XR in general and OpenXR specifically).
This is somewhat related to #54 , but only tangentially; the mobile device space has shown that despite many devices having officially matching color spaces, vendors still bump contrast here and there, change colors, adjust toning, ... in a device-specific way to have the most vibrant colors, the deepest blacks, etc.
While there might be a theoretical solution to this in a color space extensions, for the reasons mentioned above I think it's still very important that there's a clear, correct way to know which device someone is using to correct the experience based on that in case that's needed.
This might be less relevant far in the future when there's thousands of devices and we have the same mess as in the mobile landscape (at which point we'd simply give up and accept defeat), but I'd
a) be interested in a solution for today with 5-6 VR devices covering 95% of users and
b) how to not get into that future situation of "it's a mess, just accept that colors are wrong".
For reference, when using
- runtime: SteamVR/OpenXR, one cannot differentiate between Quest 1, Quest 2 and Rift (both are "SteamVR/OpenXR : oculus")
- runtime: SteamVR/OpenXR, one cannot differentiate between Vive, Vive Pro, and Vive Index
- runtime: Oculus, one can differentiate between them (Quest 1, Quest 2, Rift)
There's all kinds of hacks and workarounds floating around online, ranging from "differentiate by controller type" to "just check the HIDs on the machine for which device is actually attached" to my personal "favorite", "if it's 80fps it's a Rift, 72fps and aspect of 1.1:1 is a Quest, aspect 1:1 is a Quest".
I hope the above explains why I think better ways and specs for distinguishing between devices are important, especially to properly adjust color perception across business cases and color-relevant areas.
Potential solutions:
- Device ID should be accessible (compare to HID), separate devices shouldn't have the same ID
- Actual strict rules around color spaces for devices to be OpenXR compliant
- give up and just accept that colors don't look the same anywhere
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the OpenXR-Docs specification material related to device identification and color spaces, then read the discussion in issue #54 for related context. The issue presents multiple possible directions rather than naming a file, test, or agreed behavior; done would require an accepted specification approach and corresponding documented requirements.
Written by the indexing model from the issue text.
Assessment
- Domain
- computer-graphics, documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100