You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current css-color-4, chapter 10 is titled "Profiled, Device-dependent Colors". This title seems to neglect the existence of ColorSpace profiles, which are used to specify a device-independent colorspace.
CIELAB is quite a lot better than doing stuff in RGB, but some of its flaws (blue hue, etc.) are quite well known. There is a point in using an alternate space in the blending defined in css-color-5, or to pick colors out of an alternate lch-style wheel in css-color-4 using color(). This change does not alter the data-model of color().
The specification should probably add an exhaustive list of the ICCv4 profile types (see http://www.color.org/specification/ICC1v43_2010-12.pdf#page=36). I am pretty sure that only the Input, Display, Output, and ColorSpace types are good candidates for specifying colors anyways. DeviceLink has no information about a colorspace the system itself uses; Abstract is just for... fun(?); and NamedColor certainly doesn't work with the pass-in-floating-point-number model.
The text was updated successfully, but these errors were encountered:
The current css-color-4, chapter 10 is titled "Profiled, Device-dependent Colors". This title seems to neglect the existence of ColorSpace profiles, which are used to specify a device-independent colorspace.
Not to neglect them, but more to distinguish the from device-independent colorspaces (which is the previous section). This section is therefore about profiled RGB and CMYK (etc) colorspaces. I see your point though, if you equate "profiled" with "uses an ICC profile". As you point out, ICC profiles can be used to do a lot more than this.
CIELAB is quite a lot better than doing stuff in RGB,
Yes, which is why Lab and LCH are explicitly allowed for CSS in this specification
but some of its flaws (blue hue, etc.) are quite well known.
They are, yes. The choice of Lab is a conservative one, based on most current use in industry. There are other spaces which may well be better (where better depends on the task at hand - the metric needs to be specified and some are better on one metric but wore on others). Also, ICC v4 only accepts XYZ and Lab as a PCS so using a different device-independent colorspace implies additional work.
There is current discussion on adding spaces with better perceptual uniformity (Jzazbz, ICpCt, OKLab) although that might happen in a later level rather than level 4, which is seeing active implementation now.
The specification should probably add an exhaustive list of the ICCv4 profile types
The current css-color-4, chapter 10 is titled "Profiled, Device-dependent Colors". This title seems to neglect the existence of ColorSpace profiles, which are used to specify a device-independent colorspace.
CIELAB is quite a lot better than doing stuff in RGB, but some of its flaws (blue hue, etc.) are quite well known. There is a point in using an alternate space in the blending defined in css-color-5, or to pick colors out of an alternate lch-style wheel in css-color-4 using
color()
. This change does not alter the data-model ofcolor()
.The specification should probably add an exhaustive list of the ICCv4 profile types (see http://www.color.org/specification/ICC1v43_2010-12.pdf#page=36). I am pretty sure that only the Input, Display, Output, and ColorSpace types are good candidates for specifying colors anyways. DeviceLink has no information about a colorspace the system itself uses; Abstract is just for... fun(?); and NamedColor certainly doesn't work with the pass-in-floating-point-number model.
The text was updated successfully, but these errors were encountered: