- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Feb 2025 20:30:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-hdr] CSS syntax for HDR colors parameterized by headroom`, and agreed to the following: * `RESOLVED: add current proposal as proposal into the spec` <details><summary>The full IRC log of that discussion</summary> <ccameron> hello!<br> <joshtumath> ccameron: Taking some ideas in ICC, and also colour matching with 8 map images in ISO<br> <joshtumath> ... A good way to deal with HDR colours<br> <joshtumath> ... We're not going to expose headroom directly<br> <joshtumath> ... recomputing every time there are changes is painful<br> <ChrisL> q+<br> <joshtumath> ... want to say headroom for this and that, and interoplate between the two in UA<br> <joshtumath> ... the UA and device can limit it<br> <smfr> q+<br> <joshtumath> ... wanted to present the idea. not the definitive way to do it<br> <joshtumath> ... good to wait until ICC stuff is in a good place<br> <joshtumath> ... but that's the idea. wanted to see if anyone has thoughts<br> <astearns> ack ChrisL<br> <joshtumath> ChrisL: I really like the idea<br> <weinig> q+<br> <joshtumath> ... for SDR, everything relative to medium white<br> <cpn> s/8 map/gain map/<br> <joshtumath> ... but HDR there is no single value to use but we can't expose the headroom<br> <joshtumath> ... in the original proposal, you can say what the headroom is for two colours<br> <joshtumath> ... but when would it not be 0?<br> <joshtumath> ... it's only defined in between. what if headroom is 2 and 4 on an SDR display?<br> <joshtumath> ccameron: it needs to be defined down to 0<br> <joshtumath> ... I'm still working on proposal for what to do with different headroom values<br> <joshtumath> ... maybe we should build that into the syntax<br> <joshtumath> ... for images, you can say-- Oh. There is a reason why not to have 0<br> <joshtumath> ... suppose you had content that you don't want to become HDR<br> <joshtumath> ... is that the most useful thing, I don't know<br> <joshtumath> ChrisL: we have to define what happens when headroom is 0<br> <joshtumath> ... could make the headroom 0 the default value. removes verbosity<br> <joshtumath> ... could have n values<br> <joshtumath> ... I don't want to make this too complicated. I want it to be good enough<br> <ChrisL> q?<br> <joshtumath> ccameron: I like that idea. I also think that if we workshop this, having an initial version with only two values, one headroom 0 sounds good<br> <joshtumath> ... maybe we do want the whole p?? wise thing<br> <joshtumath> ... it adds complexity, but I'd be happy to leave that out for v1<br> <joshtumath> ... make sure the common case is super simple<br> <joshtumath> smfr: The colour that you render, the comutation of that colour takes into account screen brightness?<br> <joshtumath> ccameron: yes<br> <joshtumath> smfr: need to treat it like accent colour and not paint it into canvas?<br> <joshtumath> ccameron: I think canvas right now, it's a snapshot at a fixed headroom. not possible to realise values at rendering<br> <pal> q+<br> <joshtumath> ... so I haven't written this up. but 2d canvas has a headroom that's 0 SDR<br> <joshtumath> ... so maybe render canvas by 2, but you need to tell canvas what the effective headroom is<br> <joshtumath> smfr: so there's no way of using the colour painted as a proxy for screen brightness?<br> <joshtumath> ccameron: there better not be!<br> <joshtumath> ... the goal is to make it so you can't exfoltrate that<br> <joshtumath> ... you have to re-render your entire page when the headroom changes, so we're aligned on that<br> <joshtumath> smfr: the screen brightness things are ramped<br> <joshtumath> ... I really want to avoid re-rendering on brightness change<br> <joshtumath> ChrisL: what is the alternative?<br> <joshtumath> ???: let the rendering change deal with the viewing environment<br> <astearns> s/???/pal/<br> <joshtumath> weinig: you can't write arbitrary PQ values<br> <joshtumath> pal: as long as we allow that, that's fine right?<br> <joshtumath> ... you're just writing HDR values and let the renderer deal with it<br> <joshtumath> ... as long as that's possible, everything else is optional convinience<br> <smfr> q+<br> <ccameron> q+ (for the topic of churning the WindowServer during ramp-up)<br> <joshtumath> ChrisL: Understand that will be possible but that's not topic<br> <joshtumath> pal: I think it's important. apps that will want additional control, may want this, but otherwise should be able to let renderer do its thing<br> <pal> q-<br> <joshtumath> weinig: I was thinking about this. if getting to parity with what images and video can do... if images have to recompute each pixel value...<br> <joshtumath> ... then this will have to, too<br> <astearns> q+ ccameron<br> <ChrisL> Agree that this is CSS parity for images/video<br> <joshtumath> ... it's as if you have lots of tiny images that you've loaded that have metadata with 'between these ranges'<br> <joshtumath> ... comfortable for implementation if it mirrors what images and video can already do<br> <joshtumath> ... so I think that should quell smfr's concerns<br> <joshtumath> ... it's something that engines already have to deal with<br> <joshtumath> ... we should discuss alternative of this proposal. new property with CSS colour values that should be treated as if they are HDR values and the system can do whatever tone mapping it wants<br> <joshtumath> ... I think there are some formats with no colour map. system decides how to tone map that<br> <joshtumath> ChrisL: yes PNG and ???? has that<br> <joshtumath> ... it's just the values<br> <joshtumath> weinig: so I think benefit to having the gain map, matching something that uses PQ values directly<br> <astearns> ack ccameron<br> <joshtumath> ccameron: yes absolutely. right now it's going on in ICC where you say 'here's my headroom dependent ICC profile'<br> <joshtumath> ... here's the transformation to get to headroom 3 1 0<br> <joshtumath> ... my goal with that is that can be something you can attach to canvas<br> <joshtumath> ... 'here's the tone mapping for different headrooms'<br> <joshtumath> ... and that packet, I'd like to have the same packet between video, images, CSS, canvas<br> <joshtumath> ... so that's another option<br> <smfr> q-<br> <joshtumath> ... perhaps that's better than the suggestion I had<br> <joshtumath> weinig: we just want to get the model of what's happening in the system. something like: you can attach to px some metadata about how to tone map<br> <joshtumath> ... and the compositor does it<br> <joshtumath> smfr: I think both. you map at paint time and ????. I'm not sure whether we redraw in the first case but I think we do<br> <joshtumath> ccameron: for us, if something is in a layer, we can delegate to the OS<br> <joshtumath> ... otherwise we rewrite every pixel when headroom changes<br> <joshtumath> ... we throttle it<br> <ChrisL> s/???/re-render the whole buffer/<br> <joshtumath> ... interopolate it out or in<br> <joshtumath> weinig: but for systems with display lists, etc, they don't have to block paint<br> <joshtumath> ... a concern is, if we're privacy minded, we don't leak this info through perf characteristics<br> <joshtumath> ccameron: on some platforms it's observable<br> <joshtumath> ... but the goal is to push as far down pipeline as possible<br> <joshtumath> weinig: but if we parallel what images can do, simplifies model<br> <joshtumath> astearns: where are we at. can we resolve to adopt?<br> <joshtumath> ... or the idea of a different packet to send around something to explore?<br> <ChrisL> q+<br> <joshtumath> ccameron: I want something written down and give ICC something public to point at<br> <joshtumath> ... it's an idea worth getting out to marinate<br> <joshtumath> ... get an idea of concerns. but I like the packet idea.<br> <joshtumath> ... we should try to incorporate that<br> <joshtumath> weinig: agreed needs to marinate. let engines experiment to see what is feasable<br> <astearns> ack ChrisL<br> <joshtumath> ... makes a lot more sense to figure out how for images and video it will start playing before we tackle this<br> <joshtumath> ChrisL: would like to see this in spec so people can see what we're looking at<br> <joshtumath> ... can't currently make a HDR colour<br> <joshtumath> ... rather people get to see something<br> <joshtumath> ... am rep to ICC. I know they tend to hide things until they're public.<br> <joshtumath> ... these are things to look at, and we need experimentation that's coordinated. get a stick in the ground to kick around<br> <joshtumath> weinig: maybe we could say in the spec that this is changing<br> <joshtumath> ChrisL: yes<br> <joshtumath> ... an explicit 'DO NOT SHIP!!!'<br> <joshtumath> astearns: we can point to the issue and put in a competing proposal too<br> <joshtumath> ccameron: everyone same page about: on chrome, you specify the colour and you get something bright<br> <joshtumath> ... the goal is for that to not be the case. you opt into a brighter colour is the goal<br> <joshtumath> ... otherwise you get gamut mapped to SDR<br> <joshtumath> PROPOSED RESOLUTION: put current proposal in spec with a note that we need to solve this and where discussion is happening<br> <joshtumath> RESOLVED: add current proposal as proposal into the spec<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11616#issuecomment-2654776232 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 February 2025 20:30:36 UTC