- From: Fredrik Hubinette via GitHub <sysbot+gh@w3.org>
- Date: Fri, 26 Oct 2018 19:16:48 +0000
- To: public-css-archive@w3.org
Saying that this is "not a good way forward" seems highly subjective, and a bit odd since this is already how Chrome, Microsoft Windows, Apple and many games actually implement HDR. Any system that deals with inputs in many color spaces is going to be using some representation that can contain all of them internally, and using extended sRGB with half-floats, either in linear or non-linear form is exactly that. Having implemented both color management and HDR in chrome, I find it much easier to work with extended sRGB than lots of different color spaces. Extended sRGB is also entirely backwards compatible, which makes it easy to mix legacy and HDR content. Pointing out that additional precision is needed seems redundant when I already suggested that floating-point values should be allowed. Additional precision is required to implement HDR, regardless of what color space is chosen, so that point seems moot. How would you guys suggest that a color like rgb(688.17, 688.17, 688.17) (which is 10x brighter than rgb(255,255,255) in my proposed scheme) *should* be written? -- GitHub Notification of comment by profezzorn Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3249#issuecomment-433515343 using your GitHub account
Received on Friday, 26 October 2018 19:16:49 UTC