6 ms·

Unlocking Colors

0xff00ffee 7y ago
I appreciate trying to extend CSS to provide functions that move through a/the gammut more intuitively, but I also fear feature-creep. CSS was originally a method for setting parameters, now it is becoming a procedural (or sort-of functional) language. When it was just a parameter conifg file, there was only the need to check lexical and grammatical consistency. Now we've got to have functional regressions and computations standards... and everything that comes with a compiler verification suite. Ugh. On the one hand, I think it absolutely makes sense to keep color management in the CSS, but I also see a big ol' slippery slope.
jmiskovic 7y ago
The assumption is that using another color space (like proposed CIE) would unlock mathematical manipulation of color palettes in design. I don't think this is true. Our eyes are very sensitive to color shades and we'll easily notice if something is off. Colors are carefully picked by designers to fit together in quite subjective and non-mathematical manner. From observing some well constructed palettes, I derived the basic process used to create them. Pick the approximate colors you want, arrange them so they are all visible, and then tweak color shades so that all of them could exist under same lightning conditions in physical world. If some color seems jarring or wrong, that's because it could only exist under different lightning from rest of palette. The text seems to neglect the vast amount of information lost when we use just a single point in color space to represent the whole light spectrum. For example, magenta signifies presence of both bluish and reddish wavelengths. If your math is not based on spectrum components, how do you hope to arrive to correct color when mixing two spectrums? Linear interpolation between two points in color space? I think HSL is huge improvement over RGB model for designers, but other color spaces aren't really worth the effort. If you need light and dark theme for your UI, both will need to be hand crafted. Shifting hues by 5% or calculating complementary color won't be good enough.
- mark-r 7y ago
  I've seen the problems that can occur from using e.g. LAB for everything. It solves some problems but creates some new ones; it's not a panacea.
  - jacobolus 7y ago
    Can you elaborate? “It creates some problems” is a pretty vague.
    - thewebcount 7y ago
      For one thing, the vast majority of users, even technical users, don't know what it is or how it works. So sitting someone down with an Lab color picker would likely leave most designers confused. For another, its ranges are pretty bizarre. It's been a while since I hand-wrote the conversion, but if I recall correctly, the a and b axes had different minima and maxima, and the default conversion without any scaling ends up leaving you with ranges that are something like 0-200 for one axis and 0-500 for the other. You can scale these to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software. Its shape is also non-intuitive. The range of visible colors it represents is not a cube or cylinder or sphere. It's a multi-lobed 3D object that's hard to reason about. To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on. Users rarely have this information, and operating systems are pretty spotty on supplying it. (And users often misconfigure it.) I agree it's a good color space for the uses it was designed for. Unfortunately, there are a lot of confounding factors that make it difficult for typical users, even technical ones, to use.
      - jacobolus 7y ago
        If you have a specific color in mind you don’t want to be picking a* and b* but instead hue h* and chroma C* (polar coordinates). CIELAB isn’t perfect here (there’s some hue shift as you change chroma in the purple–blue range), but it’s pretty good, considering how simple it is. > You can scale [a and b axes] to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software. Please don’t rescale the a* and b* coordinates. These are standardized and have remained consistent since the model was introduced in the 1970s. > Its shape is also non-intuitive [...] hard to reason about The gamut of RGB displays is not intuitive. That’s the whole point. If you squash it into a regular shape then people using it end up misled into thinking they are dealing with a regular shape. In fact they are still dealing with the same weird irregular shape in terms of human-perceived color attributes, it’s just now their coordinates have been obscenely warped so they match the gamut but now have nothing to do with human perception. So e.g. changing the HSL “H” parameter will not only inconsistently affect perceived hue, but will also dramatically distort lightness and chroma relationships between colors. Anecdotally, having watched artists of various skill levels at work, this causes significant amounts of confusion. Pretty much everyone who uses HSL/HSV type models has no idea what they are dealing with, and the result is gross misunderstanding. When artists work with it long enough they can learn to work around it, but they end up with hilariously incoherent rationalizations and explanations for their heuristic techniques. Believe it or not, working with perceptually relevant coordinates is more rather than less intuitive, even for complete novices, after just a tiny bit of explanation. This is because the model matches their first-hand experience. Moreover, because the model is consistent, formal knowledge aligns with experience and grows over time. It helps if the UI reveals what they are dealing with though. (For example, Photoshop’s CIELAB mode is not ideally integrated, and not very obvious to non-experts. But once understood it still makes the image editing process much smoother and more predictable.) > To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on. You always need this information to ingest an image from a specific camera or display an image on a specific display. If you [either you personally as an artist, or the software system you are working with] aren’t aware of the basic attributes of your system you’re going to end up with bad results. There is no one “RGB”; every camera and every display is different. With some systems artists can let the software automatically make all of the choices along the way from image capture to display, but that would still be true under some change of working color space. > uses it was designed for The use CIELAB was designed for was colorimetric specification of surface colors, so that e.g. your plastic toy factory, paint mixing shop, or magazine printer could produce reliable results. It was designed to be simple enough that it could be computed in real time by hardware spectrophotometers of the 1960s–1970s. But it also works as a pretty decent color space for judging human perceptual attributes. There are some better alternatives (IPT, CIECAM02, ...) but they are more complicated and less widespread.
mark-r 7y ago
The post lost some credibility right away when they spelled "gamut" with two m's. https://en.wikipedia.org/wiki/Gamut https://en.wikipedia.org/wiki/Gamut The big rainbow has some problems too. It should be obvious by looking at the transition line from color to black-and-white that brightnesses are inaccurate. There's another problem that I don't ever see discussed - the yellow, cyan, and magenta colors really are brighter than the rest of the colors because of the way our monitors work, they have twice as many photons because they emit two different primary colors.
rubatuga 7y ago
> Your monitor does, and if you have a TV capable of HDR (hi dynamic range) that's got a wider gammut, for example... Not true, hdr just means a better contrast ratio.
- jacobolus 7y ago
  HDR means each primary can get much brighter. The range of possible chromaticities does not change, but the 3-dimensional gamut still gets much larger, and in particular it becomes possible to make much more colorful bright colors. You can simulate e.g. a flashing red light in a way that is impossible on a lower-dynamic-range display (where the light has to either look too dark or too pale). It still isn’t going to help you show a very intense dark teal color outside the capabilities of typical mix of RGB “G” and “B” primaries.
  - rubatuga 7y ago
    The problem is he is using the term "wider" which always refers to a change in the color range and not brightness. I agree gamut represents a 3D space.
    - jacobolus 7y ago
      There are 2 things here: (1) The latest generation of displays (and presumably most displays in the future) use more colorful [spectrally spikier] “R”, “G”, and “B” primaries, with the result that they can display a wider range of chromaticities than an sRGB display. (2) If you make the brightness of a diffuse white reference less than the maximum which can be produced by your display then you have more headroom in each primary, and you can produce a much wider gamut of bright colors. The possible dark colors which can be produced don’t change. This makes it possible to accurately display e.g. very colorful flowers – with linear RGB coordinates of say (2.0, 0.0, 1.5) relative to (1.0, 1.0, 1.0) meaning diffuse white – which could not otherwise be shown if diffuse white were set to be the brightest combination of primaries for the display, because then the flower would necessarily get clipped to (1.0, 0.0, 1.0). [Sorry, this is a lot easier to see if you start looking at some graphics. It is not easy to clearly describe/understand with text alone.]
dk8996 7y ago
In general, Yes this is a big issue when dealing with colors. One example where you run into this; is when you'r reducing color space from say 256 to say 12 color space (most common colors). Using LAB really helps but still not perfect.

I appreciate trying to extend CSS to provide functions that move through a/the gammut more intuitively, but I also fear feature-creep. CSS was originally a method for setting parameters, now it is becoming a procedural (or sort-of functional) language. When it was just a parameter conifg file, there was only the need to check lexical and grammatical consistency. Now we've got to have functional regressions and computations standards... and everything that comes with a compiler verification suite. Ugh. On the one hand, I think it absolutely makes sense to keep color management in the CSS, but I also see a big ol' slippery slope.

jmiskovic 7y ago

The assumption is that using another color space (like proposed CIE) would unlock mathematical manipulation of color palettes in design. I don't think this is true. Our eyes are very sensitive to color shades and we'll easily notice if something is off. Colors are carefully picked by designers to fit together in quite subjective and non-mathematical manner. From observing some well constructed palettes, I derived the basic process used to create them. Pick the approximate colors you want, arrange them so they are all visible, and then tweak color shades so that all of them could exist under same lightning conditions in physical world. If some color seems jarring or wrong, that's because it could only exist under different lightning from rest of palette. The text seems to neglect the vast amount of information lost when we use just a single point in color space to represent the whole light spectrum. For example, magenta signifies presence of both bluish and reddish wavelengths. If your math is not based on spectrum components, how do you hope to arrive to correct color when mixing two spectrums? Linear interpolation between two points in color space? I think HSL is huge improvement over RGB model for designers, but other color spaces aren't really worth the effort. If you need light and dark theme for your UI, both will need to be hand crafted. Shifting hues by 5% or calculating complementary color won't be good enough.

mark-r 7y ago
I've seen the problems that can occur from using e.g. LAB for everything. It solves some problems but creates some new ones; it's not a panacea.
- jacobolus 7y ago
  Can you elaborate? “It creates some problems” is a pretty vague.
  - thewebcount 7y ago
    For one thing, the vast majority of users, even technical users, don't know what it is or how it works. So sitting someone down with an Lab color picker would likely leave most designers confused. For another, its ranges are pretty bizarre. It's been a while since I hand-wrote the conversion, but if I recall correctly, the a and b axes had different minima and maxima, and the default conversion without any scaling ends up leaving you with ranges that are something like 0-200 for one axis and 0-500 for the other. You can scale these to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software. Its shape is also non-intuitive. The range of visible colors it represents is not a cube or cylinder or sphere. It's a multi-lobed 3D object that's hard to reason about. To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on. Users rarely have this information, and operating systems are pretty spotty on supplying it. (And users often misconfigure it.) I agree it's a good color space for the uses it was designed for. Unfortunately, there are a lot of confounding factors that make it difficult for typical users, even technical ones, to use.
    - jacobolus 7y ago
      If you have a specific color in mind you don’t want to be picking a* and b* but instead hue h* and chroma C* (polar coordinates). CIELAB isn’t perfect here (there’s some hue shift as you change chroma in the purple–blue range), but it’s pretty good, considering how simple it is. > You can scale [a and b axes] to be 0-1 or 0-100 or whatever, but there's no agreed-upon conversion used by different software. Please don’t rescale the a* and b* coordinates. These are standardized and have remained consistent since the model was introduced in the 1970s. > Its shape is also non-intuitive [...] hard to reason about The gamut of RGB displays is not intuitive. That’s the whole point. If you squash it into a regular shape then people using it end up misled into thinking they are dealing with a regular shape. In fact they are still dealing with the same weird irregular shape in terms of human-perceived color attributes, it’s just now their coordinates have been obscenely warped so they match the gamut but now have nothing to do with human perception. So e.g. changing the HSL “H” parameter will not only inconsistently affect perceived hue, but will also dramatically distort lightness and chroma relationships between colors. Anecdotally, having watched artists of various skill levels at work, this causes significant amounts of confusion. Pretty much everyone who uses HSL/HSV type models has no idea what they are dealing with, and the result is gross misunderstanding. When artists work with it long enough they can learn to work around it, but they end up with hilariously incoherent rationalizations and explanations for their heuristic techniques. Believe it or not, working with perceptually relevant coordinates is more rather than less intuitive, even for complete novices, after just a tiny bit of explanation. This is because the model matches their first-hand experience. Moreover, because the model is consistent, formal knowledge aligns with experience and grows over time. It helps if the UI reveals what they are dealing with though. (For example, Photoshop’s CIELAB mode is not ideally integrated, and not very obvious to non-experts. But once understood it still makes the image editing process much smoother and more predictable.) > To do the conversion from RGB (which is not only what you get from monitors, but also from camera sensors), you need to know things like the white point of the device it's being displayed on. You always need this information to ingest an image from a specific camera or display an image on a specific display. If you [either you personally as an artist, or the software system you are working with] aren’t aware of the basic attributes of your system you’re going to end up with bad results. There is no one “RGB”; every camera and every display is different. With some systems artists can let the software automatically make all of the choices along the way from image capture to display, but that would still be true under some change of working color space. > uses it was designed for The use CIELAB was designed for was colorimetric specification of surface colors, so that e.g. your plastic toy factory, paint mixing shop, or magazine printer could produce reliable results. It was designed to be simple enough that it could be computed in real time by hardware spectrophotometers of the 1960s–1970s. But it also works as a pretty decent color space for judging human perceptual attributes. There are some better alternatives (IPT, CIECAM02, ...) but they are more complicated and less widespread.

mark-r 7y ago

The post lost some credibility right away when they spelled "gamut" with two m's. https://en.wikipedia.org/wiki/Gamut https://en.wikipedia.org/wiki/Gamut The big rainbow has some problems too. It should be obvious by looking at the transition line from color to black-and-white that brightnesses are inaccurate. There's another problem that I don't ever see discussed - the yellow, cyan, and magenta colors really are brighter than the rest of the colors because of the way our monitors work, they have twice as many photons because they emit two different primary colors.

rubatuga 7y ago

> Your monitor does, and if you have a TV capable of HDR (hi dynamic range) that's got a wider gammut, for example... Not true, hdr just means a better contrast ratio.

jacobolus 7y ago
HDR means each primary can get much brighter. The range of possible chromaticities does not change, but the 3-dimensional gamut still gets much larger, and in particular it becomes possible to make much more colorful bright colors. You can simulate e.g. a flashing red light in a way that is impossible on a lower-dynamic-range display (where the light has to either look too dark or too pale). It still isn’t going to help you show a very intense dark teal color outside the capabilities of typical mix of RGB “G” and “B” primaries.
- rubatuga 7y ago
  The problem is he is using the term "wider" which always refers to a change in the color range and not brightness. I agree gamut represents a 3D space.
  - jacobolus 7y ago
    There are 2 things here: (1) The latest generation of displays (and presumably most displays in the future) use more colorful [spectrally spikier] “R”, “G”, and “B” primaries, with the result that they can display a wider range of chromaticities than an sRGB display. (2) If you make the brightness of a diffuse white reference less than the maximum which can be produced by your display then you have more headroom in each primary, and you can produce a much wider gamut of bright colors. The possible dark colors which can be produced don’t change. This makes it possible to accurately display e.g. very colorful flowers – with linear RGB coordinates of say (2.0, 0.0, 1.5) relative to (1.0, 1.0, 1.0) meaning diffuse white – which could not otherwise be shown if diffuse white were set to be the brightest combination of primaries for the display, because then the flower would necessarily get clipped to (1.0, 0.0, 1.0). [Sorry, this is a lot easier to see if you start looking at some graphics. It is not easy to clearly describe/understand with text alone.]

dk8996 7y ago

In general, Yes this is a big issue when dealing with colors. One example where you run into this; is when you'r reducing color space from say 256 to say 12 color space (most common colors). Using LAB really helps but still not perfect.