- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Fri, 26 Oct 2018 13:37:46 +0000
- To: public-css-archive@w3.org
> We should extend rgb() and rgba() to accept values outside of 0-255, and values outside of 0-100%. This would allow you to specify colors outside of the sRGB gamut using extended sRGB. You would think this would at least give a wider color gamut (WCG) (and indeed, I used to argue so) but in fact, no, it doesn't for several reasons. Firstly, the transfer curve is undefined outside the 0% to 100% range. But okay, this can be dealt with in various ways (and you suggest several). Secondly, having done so, there are still colors inside the Lab surface gamut - or even, inside the Rec.2020 gamut - which are unrepresentable in an extended but gamma-encoded sRGB colorspace. Basically the curve flattens off too much. OK so thirdly, one could use a linearized, extended sRGB space. But then, the advantage of sticking with sRGB for familiarity becomes even less and the precision required (16bit, or half float) is greater. Lastly, existing color management systems still tend to either clip to 0-100%, or are poorly tested beyond those limits. The correct way to encode a wider color gamut is to use a wider gamut colorspace (like P3, or 2020, or Lab) and existing color management systems will handle that just fine. That is the approach taken in CSS Color 4. The correct way to handle high dynamic range (HDR) is to use a transfer function designed to cope with the much larger dynamic range, such as PQ or HLG, plus enough bits per component to encode it (and usually, a WCG colorspace as well). -- GitHub Notification of comment by svgeesus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3249#issuecomment-433410322 using your GitHub account
Received on Friday, 26 October 2018 13:37:47 UTC