- From: Andrew Somers via GitHub <sysbot+gh@w3.org>
- Date: Tue, 02 Mar 2021 11:18:15 +0000
- To: public-css-archive@w3.org
Hi Mike @faceless2 Thanks for commenting. > +1 just for sheer effort. Well, thank you... > This is well beyond my level, but in terms of whether this sort of CSS could be converted to PDF: > * Lab space in PDF allows specification of white point, so D50/D65 are both possible. > * Excepting ICC profile based colors, any other CIE space is necessarily converted to Lab when converted to PDF. This seems to work well enough for LCH, the process would work as well for Luv. Obviously performance isn't as much of an issue for us as we're not doing it at 30fps. Um, I don't understand what you are either asking or saying, or the point or relevance? Depending on the type of PDF, it can use many different colorspaces and color models, including inside the same document for different elements. As for performance: performance is an issue for page loading on mobile, for streaming *anywhere*, for animation etc etc. Again, I don't understand what you are trying to say? > > Lab is not unbounded > > Purely for my education, can you help me understand why this is? Although normally clamped for practical purposes, as far as I'm aware neither _L_, _a_ or _b_ have a theoretical bound, and the transform between Lab and XYZ is lossless, discounting implementation rounding. `lab()` in css-color-4 has a lower bound of 0 on _L_ but that's it. Is that significant? I am most definitely not a color expert, just an engineer. What have I missed? 0 is a bound. In production environments and various working spaces, colors can be negative, and need to be in some compositing operations. If clipped, there can be ...uh... unexpected color mayhem. Officially, L* is bounded 0-100. There have been experiments in extending this for HDR with mixed results. Lab TIFF, Photoslop, ICC profiles are integer, and I can assure you integer implementations of Lab are most definitely bounded, and most definitely **not lossless.** Lab is also a grossly inefficient code space, only ~35% of code values map to real colors, and there is STILL gamut clipping. If the implementation uses floats, then sure, theoretically not "that" bounded other than 0. But it is also not linear, it's perceptual, and so if it exceeds perception, where are we? The practical bound is when exceeding the human gamut, and then you're in no-man's land. Here's a deeper dive for you: http://brucelindbloom.com/index.html?LabGamutDisplayHelp.html#IntegerLab And especially: http://brucelindbloom.com/index.html?RGB16Million.html Please let me know if you have additional questions.... Thank you! Andy -- GitHub Notification of comment by Myndex Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6061#issuecomment-788833217 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 2 March 2021 11:18:16 UTC