HDR / WCG

[jimbankoski]

Could the screen API expose whether the screen supports HDR or some other form of WideColorGamut along with other monitor specific information?

[Garbee]

What is the use-case for having the requested information provided?

I think including too many things is something to be careful on due to fingerprinting ability. The more information there is, the more uniquely identifiable the configuration as a whole is.

These two things can be properly used in sites to provide specific content to a user. However, we may want to explore alternate ways of approaching having the information depending on the use-case. For example, if it's to primarily serve a better image/video for the given monitor, it may be best to have a property request elsewhere that gives this info based on the screen the current window is on (as things currently function) rather than providing it in a generic dump of information.

[jimbankoski]

I'm not claiming I have a great use case -> just that when I played with the api HDR seemed to me to fit in with some of the other bits of information we were exposing ( like color profile and resolution ).

That said I can imagine some use cases outside the what asset to show on what screen you suggested.

I'm imagining that I may have 2 monitors extending on to each other, in which 1 is hdr and the other is not.

• I might choose to start my movie / game / image viewing on the HDR optimized monitor and not just on whatever screen kicked off the request.
• If my screen is extended across both screens I might choose to do something different than if both are HDR.

Jim

On Wed, Jul 1, 2020 at 3:58 PM Jonathan Garbee notifications@github.com wrote:

What is the use-case for having the requested information provided?

I think including too many things is something to be careful on due to fingerprinting ability. The more information there is, the more uniquely identifiable the configuration as a whole is.

These two things can be properly used in sites to provide specific content to a user. However, we may want to explore alternate ways of approaching having the information depending on the use-case. For example, if it's to primarily serve a better image/video for the given monitor, it may be best to have a property request elsewhere that gives this info based on the screen the current window is on (as things currently function) rather than providing it in a generic dump of information.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/webscreens/screen-enumeration/issues/35#issuecomment-652685857, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXCYQSO5LN6SKFANWFCPITRZO5SDANCNFSM4OOCI2JQ .

[Garbee]

I might choose to start my movie / game / image viewing on the HDR optimized monitor and not just on whatever screen kicked off the request.

I feel like this could be annoying to users. They have a window on Screen 1 while they have something critical to work on with the HDR of Screen 2. Some app they are using decides to jump screen to Screen 2 since the dev feels that is the best place for what is being done.

If we allow that kind of behavior what controls would a user have to reject what the app is doing? The UX here would need to be explored. Initially my thoughts are all of really bad UXes since conveying information is already difficult. It gets even more-so when you start including technical details and there is no clear way to express the intent of the application to a user.

If my screen is extended...

I'd need to see how Windows does extended desktops. I don't believe they would let one sit in HDR while the other isn't. When extended it would make sense to go with the lowest quality options to normalize across all monitors as best you can.

[chrisn]

I must admit to not following Screen Enumeration too closely, but I wonder if we need to consider HDR/WCG in the context of other work happening at W3C, eg., in the Media Working Group (see https://github.com/w3c/media-capabilities/issues/118, https://github.com/w3c/media-capabilities/issues/135), and proposals to the CSS WG (see https://github.com/w3c/csswg-drafts/issues/4471)?

[ThomasTheDane]

While I don't have a motivating use case sufficient to the point that I think this is worth prioritizing, I don't think there is any issue with exposing this information. We explicitly put a permission prompt in front of this access to prevent sites from just accessing this information without reading it. Yes, a site that has good reason to get this permission granted could then use the information, but this is true of almost every powerful API behind a permission prompt. On top of this, this fingerprinting would certainly count as active fingerprinting that is detectable by the browser, allowing it to alert or for it to factor into things like privacy budget.

[michaelwasserman]

Thanks for the question and sharing those complex discussions! At the most basic level, any HDR or video-plane properties added to the Screen interface should also be available on the respective static screen information snapshot returned through the proposed multi-screen getScreens() API.

Did w3c/csswg-drafts#4471 resolve to add some new Screen properties?

[chrisn]

Thanks for the question and sharing those complex discussions! At the most basic level, any HDR or video-plane properties added to the Screen interface should also be available on the respective static screen information snapshot returned through the proposed multi-screen getScreens() API.

Did w3c/csswg-drafts#4471 resolve to add some new Screen properties?

Yes, the CSS discussion there was quite lengthy, and mostly relates to TV devices where the capabilities of video rendering differ from the capabilities for graphics rendering.

One option discussed was to extend Screen to add HDR and WCG attributes, but the outcome was to use media queries instead, so there's no proposal to extend Screen at this stage. Media Queries already supports 'color-gamut', so MQ level 5 proposes dynamic-range, as well as video- prefixed versions to query the video plane.

I'm not proposing that exposing both graphics and video capabilities is important for Screen Enumeration API. That's an even narrower use case than exposing HDR/WCG capability at all.

[michaelwasserman]

Thanks. It may still be of interest to add corresponding attributes to the Screen Enumeration work, which proposes to provide information about all connected screens, beyond the single screen currently hosting the content window.

Those other display device attributes could be used to inform the placement of content windows in web applications (e.g. place an image editor's color correction window on a WCG display), or to inform users in a helpful manner (e.g. let users know when another connected screen could render some content in HDR). The complexity of separate planes and capabilities for video and graphics is somewhat unfortunate.

I'll leave this issue open for now, and welcome any feedback about this topic.

[rektide]

What is the use-case for having the requested [ed: HDR] information provided?

I have been considering building a realtime video composer. It would be wonderful to know more about the output capabilities of the screens I am targeting, so I can understand what LUTs to apply to not to the the output. Without being able to query for this information, some users will have a bad default experience.

[rektide]

Perhaps DisplayCapabilities could be used here?

[ccameron-chromium]

This issue came up again in W3C color group, in the context of canvas HDR support. I have been given an AI to write a proposal for allowing web applications to access detailed color and luminance information. Before writing it up, I would like some initial feedback on the idea from the people who have been thinking about the same problem from this context.

Use cases & motivation:

• Applications may wish to have their own tone mapping support
  • e.g, to control exactly how a given video is mapped into the target device's color volume and luminance range).
  • e.g, for a game to tune its tone mapping parameters
• Applications may wish to make more fine-grained decisions about what content to use than is currently supported by the current media queries
  • e.g, to expose WCG content to a display that has a gamut larger than sRGB but still quite short of P3
• This is fingerprint-able information, and so the privacy policies for window placement (putting the information behind a permission prompt) is a natural fit.

Solution proposal

• Add red, green, blue, and white point chromaticity coordinates
• Add minimum luminance, maximum SDR luminance, maximum HDR luminance, and maximum full frame HDR luminance

On Windows, these values would come from DXGI_OUTPUT_DESC1. The maximum SDR luminance would come from the SDR slider.

On macOS, these values would come from the NSScreen. The maximum SDR luminance is always 100 nits, and the maximum HDR luminance is specified by a multiplicative factor of the maximum SDR luminance.

[michaelwasserman]

This is a still valid enhancement request that merits future consideration.