KhronosGroup / KhronosGroup/OpenXR-Docs

Color rendering is device-specific

Open
#107 6 comments 0 reactions 0 assignees View on GitHub
synced to gitlab
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.