[css-color-4] Minimum bit depth for serializing color() values.

[svgeesus]

As a first step, I said that 8 bits is the minimum for RGB and CMYK spaces. Much commercial software uses 8bits for CMYK, and the entire Web is on 8bit sRGB currently. The wider the gamut, the more bits are needed to avoid banding. If values are stored in linear-light you also need more bits compared to a gamma-encoded or L* encoded space (because the steps are unevenly distributed, perceptually).

But:

• 10 bits is better for P3 and a98rgb, to have the same spacing as 8bit sRGB
• 10 is suboptimal for 2020 but allowed; 12 is recommended, The Rec BT.2020 standard does not even allow 8, what should we do here
• prophoto-rgb really needs 16 due to the superwide gamut

For all of these, 16bit unsigned integer or half float is a more reliable and realistic storage format. So can we increase the minimum? Need implementer input here.

(Color.js uses JavaScript number, i.e. double precision float, for component value storage and calculation).

[svgeesus]

Agenda+ mainly to stimulate discussion, and feedback from implementers.

[svgeesus]

I understand that internally, WebKit is storing values in gamma-encoded display-p3 with a half-float encoding (and with values outside the range 0 to 1 allowed, I think, but not certain) @smfr @grorg

I understand from @tabatkins that Blink is considering using an internal representation of half-float, gamma-encodes, sRGB values; again with values outside the range 0 to 1 allowed.

I haven't heard what Gecko is considering but would love to know.

[smfr]

The way WebKit stores color values isn't necessarily the same as the pixel format used for drawing buffers.

In WebKit, non sRGB color values are stored as float[4]. Drawing buffers might be non-clamped 8-bit, 10-bit, or half-float depending on the platform.

[svgeesus]

How can 8 or 10 bit be non-clamped?

[svgeesus]

In WebKit, non sRGB color values are stored as float[4].

OK so whatever we decide regarding minimum bit depth for serialization, WebKit would comfortably meet it

[css-meeting-bot]

The CSS Working Group just discussed [css-color-4] Minimum bit depth for serializing color() values.

The full IRC log of that discussion

<dael> Topic: [css-color-4] Minimum bit depth for serializing color() values
<dael> github: https://github.com//issues/5667
<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
<smfr> q+
<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
<dael> chris: Haven't heard from Mozilla
<astearns> ack smfr
<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
<dael> chris: Internal storage where when you serialize for OM you can return with specificity
<dael> smfr: And that has not roundtripped between buffer
<dael> chris: Right
<dael> chris: Given that clarification can anyone from Mozilla answer?
<dael> astearns: Anyone from Mozilla willing to commit to finding the answer?
<dael> astearns: Or could say who we could ping
<dael> dholbert: Start with emilio maybe. Not sure
<dael> astearns: Chromium clarification?
<dael> rune: I thought we just stored 32 bit.
<dael> chris: I mean 8 bit per component which is not suffience except for sRGB
<dael> chris: I think TabAtkins was talking about future plan
<chris> 16bit half float
<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
<dael> smfr: But this is not about texture formals
<astearns> s/texter/texture/
<dael> s/formals/formats
<chris> s/formals/formats
<dael> TabAtkins: Underlying format of images we use to paint
<dael> smfr: This is storing colors in css data structure
<dael> TabAtkins: But if we're planning to deal with half-floats I presume we'd reflect across internal stack
<emilio> in Gecko we store 32-bit integer, 8-bit per channel of rgba
<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.
<smfr> generally code wouldn’t use half-float in data structures, so you’d probably store floats
<dael> iank_: Not sure explicit details. I think we did have concerns about increasing size of representing colors. I can find out about this
<dael> chris: That would help, thanks
<emilio> But we're going to probably do something else for new color spaces or what not
<smfr> iank_: webkit just sets a bit that says “go look at this other data structure"
<dael> chris: 8 bit is a nice round stable thing. If you go beyond you basically use 16 bits unless you're packing
<dael> chrishtr: When you say min 10, 12 bits what section?
<emilio> Yeah, same concern iank_ mentions about growing too much style data structures
<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.
<emilio> At least when they're not using non-rgba colors
<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
<dael> chrishtr: And what to know if min would be too large and make too large memory buffer
<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
<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
<dael> chrishtr: To rep all things in color space you need more resolution
<dael> smfr: Potentially yes
<dael> chrishtr: So you have 8 bits and map with different transfer function
<dael> smfr: Yeah, might get bounding. Have been shipping for years on iOS and no complaints.
<dael> chrishtr: Is that compliant
<dael> chris: Spec doesn't say how many ot render. Purely on rendering
<dael> chrishtr: Serialization or interpolation you need the bits. But if browser uses lossy way to render that's quality of impl
<dael> chris: It's fine. most frame buffers are still 8 bits. It's avoiding cumulative rounding errors in processing which can blow up
<dael> chrishtr: Got it, thank you
<dael> chris: Sounds like we shouldn't close b/c need to get back. Happy with discussion and okay to move on
<dael> astearns: Sounded like people are okay with spec something here
<dael> chrishtr: smfr, how many bits do you use in the WK CSS data structure
<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
<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
<dael> smfr: And only colors that are spec that way, not every color
<dael> chrishtr: And that's not similar memory impact b/c not commor
<dael> rune: Current Chrome impl uses 64 bits. 32bit RGB and flags on either side. System colors are keywords too
<dael> chris: That sounds like nice impl. Only pay cost if yo uneed it
<dael> chris: Thank you! This is all i wanted to know
<dael> astearns: Only have a couple minutes. Not sure anything on the agenda that's 2 minutes

[svgeesus]

astearns: Sounded like people are okay with spec something here

I added a table of minimum bit depths for round-tripping