3 ms·

As a hobbyist, one of the issues I have with sRGB and color spaces in general is that debugging color spaces issues is difficult. For example, trying to figure

As a hobbyist, one of the issues I have with sRGB and color spaces in general is that debugging color spaces issues is difficult. For example, trying to figure out why images on Google Photos in Chrome look "off", and how to get the images look consistent between platforms (browser and OS) is frustrating.

ISL 5y ago
Color is really, really hard. I love the clarity of black-and-white imaging, but the thing that keeps me coming back to it more than anything else is the ability to successfully render my intended image on more electronic platforms. When working in color, I either gravitate toward images with unambiguous color or accept the fact that only those with calibrated screens will see what I intended to create. Moreover, those calibrated screens need to be calibrated to the same reference I'm using, or they'll see something different. Even with prints, without controlling the viewer's ambient light, you'll also get different perception. It is really hard. Agreed that debugging is hard, too. I've recently come across the notion of 'canary images' [1] , which can make some of the debugging effort into binary search. [1] https://instagram-engineering.com/bringing-wide-color-to-instagram-5a5481802d7d https://instagram-engineering.com/bringing-wide-color-to-ins...
- rocqua 5y ago
  I wonder how the canary image interacts with 'rendering intent'. I could well imagine 'relative colorimetric' or 'perceptual' methods of converting to sRGB color space essentially scaling down how red the square is to allow showing the embedded logo in a redder color than the rest of the square.
- JKCalhoun 5y ago
  Apple introduced their ColorSync technology a couple of decades ago. (Early in my career I worked on the ColorSync team.) Apple relied on ICC profiles (International Color Consortium?) to define the color characteristics of each device in a color workflow. You would not modify the bytes of the image source as it passed through your pipeline, merely rendered it differently using the ICC profiles and math. A computer display generally has a much wider, richer color gamut than an inkjet printer. Naturally an image rich in color can look better on the display than when printed. When going from a wide gamut of the source image to a much smaller gamut you have some choices as to whether you want to simply clip the outlying colors and therefore "mute" your dynamic color range or whether you want to scale down the entire gamut of the source image to try to fit it within your destination gamut; or some other compromise (called "rendering intent" in the ColorSync jargon). There were other issues like color temperature and issues specific to specific devices: white-point, black-point, etc. A nice thing about this workflow was of course that the source image was unmodified across the pipeline, rendered as best it could be for the specific output (with the specified intent). The math worked well enough in fact that you could map the source image to your printer profile, and then map those new values to your display and essentially "proof" the image: see what the image is likely to look like when the gamut is restricted by the print device. When Apple and other companies started introducing wide-gamut displays this was a very exciting development since it kicked open the gamut of our displays and a properly color-managed OS could, for example, really show you some of the rich reds the cameras had captured (in RAW of course) that previous display technologies could not. Funnily, a non-managed color workflow on the same display would look "off" as things like the red close buttons in the window corners looked blazingly red, painfully red almost. Specifying RGB as (1.0, 0.0, 0.0) for red was no longer going to look right, now needed to be pulled in to a gamut we were more used to using something like (0.9, 0.0, 0.0). (Software of course would naively still specify (1.0, 0.0, 0.0) but I believe when the window backing store then rendered those pixels to the display it did the color matching that pulled the red down — if you wanted to display a RAW image you would assign that camera's ICC profile to the backing store to prevent the default match.) The downside of the ColorSync model was of course every device had to be calibrated. Displays were fairly trivial but printers, as you probably know, needed a different profile for not only different inks but also different papers as the same magenta ink will look different on coated versus non-coated paper. And printers were particularly bad color devices because there were no good mathematical models using power-curves and black-body temperatures the way a display could be modeled, instead large 3D tables of color values, printed and carefully measured and later interpolated between were needed for each ink + paper combination. sRGB was something I remember Microsoft getting behind. The model was, I was explained, to define the color space that 8-but RGB values were supposed to conform to. So if you could dial in your display to display sRGB, your printer to print sRGB, then no color management is really needed — WYSIWYG. The downside of course was that sRGB was a narrow gamut that gimped displays capabilities and yet I suspect was outside the capability of many printers. Adobe only slightly remediated that by creating AdobeRGB that followed the same idea, just kicked open the gamut a bit more. Anyway, that's the way I remember/understood it.
  - aikinai 5y ago
    Your mention of blazingly red close buttons immediately brought to mind how the iPad looks when using SideCar. I've tried to use it many times, but can't stand the way MacOS renders color on the iPad, including eye-burning colors in the traffic light buttons. Is this what causes the issue? Does the Mac naively send high saturation colors to the iPad screen that has a wider gamut maybe? I've tried changing the color profile on the iPad, but SideCar doesn't support that, so it's stuck looking terrible and I never used SideCar for real. Now I'm just waiting for Universal Control since then the iPad will be managing its own color.
    - JKCalhoun 5y ago
      It is conceivable to me (but I have no first-hand knowledge) that the same color-matching for backing-stores is not in play in the iOS window server.
- mnahkies 5y ago
  I've seen landscape paintings done in such a way that they change based on the illumination, it was a very impressive effect. There's an article about the guy here https://thisnzlife.co.nz/queenstown-painter-tim-wilson-celebrates-beauty-light-and-spirituality-in-his-renowned-oil-landscapes/ https://thisnzlife.co.nz/queenstown-painter-tim-wilson-celeb... relevant quote: > I use a lot of translucent, transparent and interference pigments and when the light levels change, the underpainting punches through
rocqua 5y ago
It is inherently a difficult process. Firstly, true references are very hard to come by. That makes debugging hard already. Secondly, color is not just a property of light. The same lamp, with the same spectrum of emitted light can appear to have a different color to you depending on the surroundings. During daylight a lamp might look yellow-white, but when looking at the same lamp at night when you have your normal lamps on in your home, it could look blue. That is because your eyes 'adjust' how they see color depending on ambient conditions. This way your eyes always see a white sheet of paper as white. Instead of it looking yellow under warm light, or blue under very cold light. Things are even worse when considering the color of normal objects. The 'emitted spectrum' of an object depends on the spectrum of light that falls on the object. Take two light sources. One being 'wide spectrum' and white the other being a mix of a few wavelengths also looking white. Two objects could appear to have the same color under one lamp, but look different under the other lamp. And the above situation is also still affected by the general color of your surroundings. Hence it is quite hard to even say what 'color' an object has. Or even what color a light source has. Generally the approach is to standardize. For light that means specifying the 'color temperature' (and tint) of your ambient light. To ensure your eyes are adjusted to a known light situation. For the color of objects, if attempts are made to specify a color, it is specified under a specific broad-spectrum light source. But I believe generally they are defined as 'this mix of pigments'. This means that for objects, it is essentially impossible to take the color of an object and make a second object that has the same color, unless you know how the first object got its color.
fxtentacle 5y ago
X-rite for example sells color test cards, verified color PNGs and color measurement meters. You can use those to make sure the color matches up from paper to scanned file to screen. The opposite direction is more difficult, because most screens can display colors that you can't print with CMYK.

ISL 5y ago

Color is really, really hard. I love the clarity of black-and-white imaging, but the thing that keeps me coming back to it more than anything else is the ability to successfully render my intended image on more electronic platforms. When working in color, I either gravitate toward images with unambiguous color or accept the fact that only those with calibrated screens will see what I intended to create. Moreover, those calibrated screens need to be calibrated to the same reference I'm using, or they'll see something different. Even with prints, without controlling the viewer's ambient light, you'll also get different perception. It is really hard. Agreed that debugging is hard, too. I've recently come across the notion of 'canary images' [1] , which can make some of the debugging effort into binary search. [1] https://instagram-engineering.com/bringing-wide-color-to-instagram-5a5481802d7d https://instagram-engineering.com/bringing-wide-color-to-ins...

rocqua 5y ago
I wonder how the canary image interacts with 'rendering intent'. I could well imagine 'relative colorimetric' or 'perceptual' methods of converting to sRGB color space essentially scaling down how red the square is to allow showing the embedded logo in a redder color than the rest of the square.
JKCalhoun 5y ago
Apple introduced their ColorSync technology a couple of decades ago. (Early in my career I worked on the ColorSync team.) Apple relied on ICC profiles (International Color Consortium?) to define the color characteristics of each device in a color workflow. You would not modify the bytes of the image source as it passed through your pipeline, merely rendered it differently using the ICC profiles and math. A computer display generally has a much wider, richer color gamut than an inkjet printer. Naturally an image rich in color can look better on the display than when printed. When going from a wide gamut of the source image to a much smaller gamut you have some choices as to whether you want to simply clip the outlying colors and therefore "mute" your dynamic color range or whether you want to scale down the entire gamut of the source image to try to fit it within your destination gamut; or some other compromise (called "rendering intent" in the ColorSync jargon). There were other issues like color temperature and issues specific to specific devices: white-point, black-point, etc. A nice thing about this workflow was of course that the source image was unmodified across the pipeline, rendered as best it could be for the specific output (with the specified intent). The math worked well enough in fact that you could map the source image to your printer profile, and then map those new values to your display and essentially "proof" the image: see what the image is likely to look like when the gamut is restricted by the print device. When Apple and other companies started introducing wide-gamut displays this was a very exciting development since it kicked open the gamut of our displays and a properly color-managed OS could, for example, really show you some of the rich reds the cameras had captured (in RAW of course) that previous display technologies could not. Funnily, a non-managed color workflow on the same display would look "off" as things like the red close buttons in the window corners looked blazingly red, painfully red almost. Specifying RGB as (1.0, 0.0, 0.0) for red was no longer going to look right, now needed to be pulled in to a gamut we were more used to using something like (0.9, 0.0, 0.0). (Software of course would naively still specify (1.0, 0.0, 0.0) but I believe when the window backing store then rendered those pixels to the display it did the color matching that pulled the red down — if you wanted to display a RAW image you would assign that camera's ICC profile to the backing store to prevent the default match.) The downside of the ColorSync model was of course every device had to be calibrated. Displays were fairly trivial but printers, as you probably know, needed a different profile for not only different inks but also different papers as the same magenta ink will look different on coated versus non-coated paper. And printers were particularly bad color devices because there were no good mathematical models using power-curves and black-body temperatures the way a display could be modeled, instead large 3D tables of color values, printed and carefully measured and later interpolated between were needed for each ink + paper combination. sRGB was something I remember Microsoft getting behind. The model was, I was explained, to define the color space that 8-but RGB values were supposed to conform to. So if you could dial in your display to display sRGB, your printer to print sRGB, then no color management is really needed — WYSIWYG. The downside of course was that sRGB was a narrow gamut that gimped displays capabilities and yet I suspect was outside the capability of many printers. Adobe only slightly remediated that by creating AdobeRGB that followed the same idea, just kicked open the gamut a bit more. Anyway, that's the way I remember/understood it.
- aikinai 5y ago
  Your mention of blazingly red close buttons immediately brought to mind how the iPad looks when using SideCar. I've tried to use it many times, but can't stand the way MacOS renders color on the iPad, including eye-burning colors in the traffic light buttons. Is this what causes the issue? Does the Mac naively send high saturation colors to the iPad screen that has a wider gamut maybe? I've tried changing the color profile on the iPad, but SideCar doesn't support that, so it's stuck looking terrible and I never used SideCar for real. Now I'm just waiting for Universal Control since then the iPad will be managing its own color.
  - JKCalhoun 5y ago
    It is conceivable to me (but I have no first-hand knowledge) that the same color-matching for backing-stores is not in play in the iOS window server.
mnahkies 5y ago
I've seen landscape paintings done in such a way that they change based on the illumination, it was a very impressive effect. There's an article about the guy here https://thisnzlife.co.nz/queenstown-painter-tim-wilson-celebrates-beauty-light-and-spirituality-in-his-renowned-oil-landscapes/ https://thisnzlife.co.nz/queenstown-painter-tim-wilson-celeb... relevant quote: > I use a lot of translucent, transparent and interference pigments and when the light levels change, the underpainting punches through

rocqua 5y ago

It is inherently a difficult process. Firstly, true references are very hard to come by. That makes debugging hard already. Secondly, color is not just a property of light. The same lamp, with the same spectrum of emitted light can appear to have a different color to you depending on the surroundings. During daylight a lamp might look yellow-white, but when looking at the same lamp at night when you have your normal lamps on in your home, it could look blue. That is because your eyes 'adjust' how they see color depending on ambient conditions. This way your eyes always see a white sheet of paper as white. Instead of it looking yellow under warm light, or blue under very cold light. Things are even worse when considering the color of normal objects. The 'emitted spectrum' of an object depends on the spectrum of light that falls on the object. Take two light sources. One being 'wide spectrum' and white the other being a mix of a few wavelengths also looking white. Two objects could appear to have the same color under one lamp, but look different under the other lamp. And the above situation is also still affected by the general color of your surroundings. Hence it is quite hard to even say what 'color' an object has. Or even what color a light source has. Generally the approach is to standardize. For light that means specifying the 'color temperature' (and tint) of your ambient light. To ensure your eyes are adjusted to a known light situation. For the color of objects, if attempts are made to specify a color, it is specified under a specific broad-spectrum light source. But I believe generally they are defined as 'this mix of pigments'. This means that for objects, it is essentially impossible to take the color of an object and make a second object that has the same color, unless you know how the first object got its color.

fxtentacle 5y ago

X-rite for example sells color test cards, verified color PNGs and color measurement meters. You can use those to make sure the color matches up from paper to scanned file to screen. The opposite direction is more difficult, because most screens can display colors that you can't print with CMYK.