What Makes sRGB a Special Color Space?
photosauce.net
photosauce.net
To a first approximation, humans perceive color on the basis of three different kinds of light sensitive "cone" cells. The three varieties are most sensitive to red, green, and blue light.
An image with control over intensities of a red, green, and blue component of emitted light can match the stimulation of cones over some range ("gamut") of colors a person could perceive. Orange wavelengths of light are between the wavelengths of a pure red and pure green, and a mixture of red and green light will be perceived as orange.
The only reason the RGB approximation to color works is because of how the human eye works. But it misses a bunch about how the eye works! Cones are not just sensitive to a single color; they have a response curve over a whole range of wavelengths. This means there are pure colors (wavelengths) which produce an eye response outside the span of what can be produced mixing pure red, green, blue light signals.
There are other dimensions of complexity to the human biology component: there is a 4th kind of light sensitive cell (rods) that contribute mostly to low-light vision. Some people have fewer kinds of cone cells (color-blindness) or more (tetrachromacy[1]).
Eyes are also sensitive to polarization of light [2], which as far as I know has still not entered the display-space discussion.
So the color space challenge is about reducing complex infinite-dimensional reality to a small dimension approximation based on limitations of human biology, but using incomplete flawed approximations of that biology.
[1] https://www.optimax.co.uk/blog/tetrachromacy-superhuman-visi...
https://www.youtube.com/watch?v=wh4aWZRtTwU
Colour theory can get pretty complicated, the video is however very understandable as well as interesting :)
What a ridiculous situation and a great example of why specs should be open.
(Speaking of which: anyone know how to get a free, legal copy of any revision of ISO/IEC 14496-15? I've had luck with some of its close friends, but not that one.)
When that happens, I can often find a copy of the spec by hunting down zip files of drafts attached to meeting records online or I can find a draft copy of the spec after a simple registration form. I can’t speak to this one for the 2019 latest version or newer, but I did find out what might be some earlier versions at the bottom of https://mpeg.chiariglione.org/standards/mpeg-4/carriage-nal-... for example. Or for newer work-in-progress: https://www.mpegstandards.org/standards/MPEG-4/15/ No promises that anything found this way will be used/useful yet.
Thanks for the other two links; I don't see anything useful for this one, but maybe they'll help next time...
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-ins...
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.
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.
There's an article about the guy here 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
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.
Accordingly, the conversion formulas given in the article will be wrong for 8bit sRGB images like they are usually used in JPEG or PNG, because they lack the gamma conversion.
(In practice this curve is a pain, so many systems over the years have just settled to approximate it as a 2.2 gamma curve.)
Modern screens are capable of an enormous range of colors that just aren't visible on the internet because of the sRGB standard.
Visit https://svija.love in Safari on a modern Mac, and you can see what Display P3 color, or ProPhoto RGB color can do.
Honestly, I will never forget the day a couple of years ago that I first saw what my monitor was actually capable of. I had been building websites in sRGB since 1995 and I was just blown away.
The sooner the new color profiles are widely adopted the better — I for one can't wait.