4 ms·

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 abili

by 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

by ISL 5y ago

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