- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 09 Dec 2020 17:57:55 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color-4] Minimum bit depth for serializing color() values`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-color-4] Minimum bit depth for serializing color() values<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5667<br> <dael> chris: Request for impl feedback. Spec says you must preserve 8 bits. Fine for srgb but not for other color spaces. 2020 min is 10 and rec is 12. smfr said they're storing as floats so they're good with whatever<br> <smfr> q+<br> <dael> chris: I think TabAtkins said it's 16 bit range. Would be great to have more confirmation. I thought Chrome canvas rejected it b/c too many bits<br> <dael> chris: Haven't heard from Mozilla<br> <astearns> ack smfr<br> <dael> smfr: Clarify something. Careful to distinguish between bits to store css color values vs depth of backing store. backing store can use half float. Have to be very specific<br> <dael> chris: Internal storage where when you serialize for OM you can return with specificity<br> <dael> smfr: And that has not roundtripped between buffer<br> <dael> chris: Right<br> <dael> chris: Given that clarification can anyone from Mozilla answer?<br> <dael> astearns: Anyone from Mozilla willing to commit to finding the answer?<br> <dael> astearns: Or could say who we could ping<br> <dael> dholbert: Start with emilio maybe. Not sure<br> <dael> astearns: Chromium clarification?<br> <dael> rune: I thought we just stored 32 bit.<br> <dael> chris: I mean 8 bit per component which is not suffience except for sRGB<br> <dael> chris: I think TabAtkins was talking about future plan<br> <chris> 16bit half float<br> <dael> TabAtkins: What I heard is plan to handle higher color profiles was to switch underlying texter to be a 16 bit half float per channel. It gives more than 8 bits of precision. Don't know how that reflects rest of stack<br> <dael> smfr: But this is not about texture formals<br> <astearns> s/texter/texture/<br> <dael> s/formals/formats<br> <chris> s/formals/formats<br> <dael> TabAtkins: Underlying format of images we use to paint<br> <dael> smfr: This is storing colors in css data structure<br> <dael> TabAtkins: But if we're planning to deal with half-floats I presume we'd reflect across internal stack<br> <emilio> in Gecko we store 32-bit integer, 8-bit per channel of rgba<br> <dael> chris: Clear, but can you get someone to confirm. Else I'm going to start putting bigger minimums and don't want people saying can't do that.<br> <smfr> generally code wouldn’t use half-float in data structures, so you’d probably store floats<br> <dael> iank_: Not sure explicit details. I think we did have concerns about increasing size of representing colors. I can find out about this<br> <dael> chris: That would help, thanks<br> <emilio> But we're going to probably do something else for new color spaces or what not<br> <smfr> iank_: webkit just sets a bit that says “go look at this other data structure"<br> <dael> chris: 8 bit is a nice round stable thing. If you go beyond you basically use 16 bits unless you're packing<br> <dael> chrishtr: When you say min 10, 12 bits what section?<br> <emilio> Yeah, same concern iank_ mentions about growing too much style data structures<br> <dael> chris: Serialization on how you get back string of a color spec. How many digits do you round to. 2 digits is 100 values which isn't enough.<br> <emilio> At least when they're not using non-rgba colors<br> <dael> chris: I has said 8 bits but needs to be higher b/c will get bounding. Depends on the space how many bits to avoid bounding<br> <dael> chrishtr: And what to know if min would be too large and make too large memory buffer<br> <dael> chrishtr: I think need min possible because memory constraints are possible. Memory is main reason I hesitate to add these color spaces to chromium<br> <dael> smfr: Spec allows 8 bit even if allow extended svg. We render P3 colors b/c render to another color space. I don't htink this requires all buffers to be half float<br> <dael> chrishtr: To rep all things in color space you need more resolution<br> <dael> smfr: Potentially yes<br> <dael> chrishtr: So you have 8 bits and map with different transfer function<br> <dael> smfr: Yeah, might get bounding. Have been shipping for years on iOS and no complaints.<br> <dael> chrishtr: Is that compliant<br> <dael> chris: Spec doesn't say how many ot render. Purely on rendering<br> <dael> chrishtr: Serialization or interpolation you need the bits. But if browser uses lossy way to render that's quality of impl<br> <dael> chris: It's fine. most frame buffers are still 8 bits. It's avoiding cumulative rounding errors in processing which can blow up<br> <dael> chrishtr: Got it, thank you<br> <dael> chris: Sounds like we shouldn't close b/c need to get back. Happy with discussion and okay to move on<br> <dael> astearns: Sounded like people are okay with spec something here<br> <dael> chrishtr: smfr, how many bits do you use in the WK CSS data structure<br> <dael> smfr: If color is P3 we set a bit in our color data structure saying interprete this as a pointer to another data structure and the other data structure has the bits. We only pay the cost if it's outside sRGB<br> <dael> chrishtr: If page had a bunch of P3 it would use 4 flaots for every color in CSS in the stylesheet, but not for every pixel<br> <dael> smfr: And only colors that are spec that way, not every color<br> <dael> chrishtr: And that's not similar memory impact b/c not commor<br> <dael> rune: Current Chrome impl uses 64 bits. 32bit RGB and flags on either side. System colors are keywords too<br> <dael> chris: That sounds like nice impl. Only pay cost if yo uneed it<br> <dael> chris: Thank you! This is all i wanted to know<br> <dael> astearns: Only have a couple minutes. Not sure anything on the agenda that's 2 minutes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5667#issuecomment-741946807 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 9 December 2020 17:57:57 UTC