(Mux founder here, but adding some additional community bits to the conversation)
Probably unsurprisingly, the (honestly absurd world of) color is a pretty consistent topic among video engineers. Color theory is one of those areas that people working directly with it see it as a completely unsolved problem, and everyone else largely takes it for granted. This is a small sample size, but these are all talks just from a local SF Video meetup and the Demuxed conference, and the speakers work at YouTube, Vimeo, Mux, and a fruit company.
I would say that much of it is actually solved in theory, just not in practice. (I.e. we know what it should display, but browsers get it wrong still) There are both outstanding issues with browsers being accidentally wrong/incomplete (e.g. both Firefox and Chrome have issues with full-range videos displaying incorrectly, just with different videos), and also with various implementations deviating from standards to "do the right thing" (though this is also a central dilemma of hdr display/tone-mapping).
There are definitely cases where it's clear what we (as browsers) are supposed to do, but some implementations have chosen to err on the side of user preference rather than correctness. I hope we can move that needle back towards "implement the specs". There's no good reason for any 601- or 709-marked content to display incorrectly in the year 2021.
> Project leaders from Ffmpeg, Google, Mozilla, Microsoft (and probably Nvidia and AMD) need to all get together and decide on a single method.
Speaking non-officially as a browser implementer, VUI isn't always reliable as a source of color, both because the encoders don't always know, and the decoders don't always extract it reliably. The container is a more reliable place to put it (eg. MP4 'colr' box).
Browsers do differ in behavior when these sources of metadata differ. It currently looks likely that WebCodecs will require implementations to use app-provided color metadata over in-band metadata, which would be good for interoperability!
Sad to see that even today the results don't line up with the expected... and in different ways than before, even?
Something the article doesn't touch upon is that colorspace assumptions can also vary between different video formats across browsers (at least back when I made this test), which adds another unfortunate dimension into the color accuracy mess.
Anyway, good to see more attention brought on the subject once again, though unlike the article, I would personally say that if we're going to make assumptions in the absence of concrete colorspace information, I think we should rather consistently assume BT.709 rather than BT.601, for the simple reason that we can reasonably expect that basically any camera in existence today would likely record in BT.709 by default, and I'd expect most editing software with their HD presets and whatnot to default to BT.709 as well.
(I hate having to make these statements but I am not trolling)
I was told search for "perfect" parity across users was in vain because perception of colour varied too much, from blood sugar level to physiology and etc.
What is the true benefit of going after this on software side? I mean I am not understanding the difference it causes on artistic statement or emotional impact.
I understand and support "true colour" across all hard/software but is it really that impactful?
Agreed, digital color can be a huge rabbit hole once you start understanding all of the pieces involved. Reminds me of one of my favorite xkcd comics (the alt text is particularly relevant here)
Reminded me of Colorful Notions[1], a BBC documentary from the 80s. I found it illustrated a lot of the weird quirks of colors with rather nice demonstrations.
> And many people know that specific colors are really just wavelengths in the electromagnetic spectrum.
Colors that can be stimulated using a single wavelength are spectral colors, which are only a small subset of perceptible colors. In the CIE xy model, spectral colors are on the curved boundary, while the straight boundary is the line of purples - impossible colors.
Edit: And because CIE XYZ is used as a sort of universal connecting and definition space, all our color spaces are defined in terms of it. But this leads to a the-map-is-not-the-territory fallacy: CIE XYZ was based on just a handful of observations and generously extrapolating. CIE XYZ does not define the set of visible colors. It's a map of colors.
---
This post is about conversion from the video's color space to a rendering color space, and the problems with that. Another fun question is whether that rendering color space is actually the display device's color space, or nah. While browser do output color management (i.e. they use the color profile of the output device and convert all their output to the ad-hoc color space that represents), I don't think they do that for video actually. In fact, there are virtually no video players supporting color management on the output side of things.
I've been working on a Vulkan rendering engine for an embedded bit of hardware, and even though I spend an insane amount of time getting the colour spaces correct (textures, tools, presentation format, etc) in the end the cheap LCD screen cheated with it's firmware (I wanted BT2020, but it kept on giving 601, I couldn't even get BT709). The firmware lied that it supported multiple formats (including P3), but it was just a menu option with no effect. My reference desktop monitor did show all the differences, so I know that engine code path was correct.
> And many people know that specific colors are really just wavelengths in the electromagnetic spectrum. [...]
> There are many systems involved to turn an RGB triplet value into a specific wavelength of light
I think this wavelenght-color connection, often perpetuated in high-school classrooms, confuses people more than helps. In particular when talking RGB colors, your display (or really, any part of the process) will not really change the wavelenghts of outputted light based on the input.
Also colors really are not just wavelengths in EM spectrum. Color is more of a perceptual phenomenon, something that happens in our heads, more than physical phenomenon. And there are many things that can impact the color perception, most obviously the other surrounding colors and ambient lighting.
That’s when you’re talking about color production (how the artist/content creator intends a specific visual image to be perceived).
Color reproduction is 100% an engineering thing about wavelengths. To my knowledge monitors do indeed change the wavelength. Sure it’s several separate colored emitters, but using constructive and destructive interference to generate a wavelength doesn’t take anything away from it.
There are places where things get messy where reproduction blends in a bit of production (eg applying an HDR filter, applying monitor-specific tweaks, etc). It’s a complex topic for sure. But the position of “color is purely a perception in our head and not wavelengths” position is too extreme in the opposite direction and isn’t helpful in building things.
Recently I went down the rabbit hole of JPEG encoding. The default encoder - libjpeg turbo - is going to write lookup tables for CRT monitors of yesteryear where the signal is analogue and the picture is magically made good looking by the 1280 X 1024 CRT. Trinitron was the gold standard then.
The Mozilla JPEG encoder mozjpeg assumes a high density digital display and encodes for that, typically with less banding but softer.
Not a lot of people cared for mozjpeg and the barely perceptible differences, even though file sizes were smaller into the deal.
This experience made me aware of how few people are working at the cutting edge of image processing, for images or video. It is amazing how much we take their work for granted.
Frustrating differences may be between screens, browsers and operating systems, we are lucky to have what we have got and also lucky to have such forgiving eyes. The whole shebang is nothing short of a miracle.
> Most people know some basics of color theory. [...] And many people know that specific colors are really just wavelengths in the electromagnetic spectrum. [...] There are many systems involved to turn an RGB triplet value into a specific wavelength of light.
A 5-year old asks you "The Sun is a big hot ball! What color is the ball?". What do you tell them? They ask "And sunlight?" You say?
Most first-tier astronomy graduate students simply get Sun color wrong. A widespread misconception, perhaps first learned in Kindergarten, then reinforced by incorrect textbooks, persisting unintegrated into grad school. But more interesting here, is that first-tier non-astronomy physical-sciences graduate students often answer with some variation on "it doesn't have a color; it's rainbow color".
Confusing wavelength and spectrum and optical color. As in TFA, and discussion here. So I suggest very few people have a firm grasp on even core basics of color theory.
OT (from an email draft in my other window): What if those students had instead learned Sun color correctly in Kindergarten? How might it then have been used over the years, to teach other topics better? For example, color is often taught preK-1. So how might color be better taught, with improved conceptions, progressions, and interactives, building in part on this firmer grasp of Sun color?
The article is focused on video, but fwiw (at least several years ago), the browsers do bad stuff with images, too. It is (was?) impossible to get Firefox and I think also Chrome to correctly render PNG, JPEG, and other formats, especially when they provided a color profile.
At the time (again, like a decade ago) at least, it was roughly: Firefox thinks every JPEG is sRGB and every PNG is “huh?”, Chrome got JPEG right (treat as sRGB when no profile is present) but couldn’t do Adobe RGB (and wouldn’t even open a TIFF), and Safari used Apple’s long-standing color code to basically get this right (though I don’t recall if it went with “assume sRGB if no profile”).
I’d be curious to reproduce those old results, especially given the cool “oh yeah, Chrome doesn’t show the same colors in software mode” shown here!
Fun example of at least making an attempt...the Demuxed website for 2019[1] had a big, animated hero image on top of a deep purple background. Obviously we went with a video first, which looked great, but then...we ran into this problem and different browsers/hardware all would show slight-but-obvious differences between the video background and the hero background.
Ultimately we decided to just use a gif, but the other, more fun solution we experimented with was to use canvas to render the video, grab the hex value from one of the purple pixels, and set the background to that[2].
I remember the first time I got two same model monitors and spent far too long failing to get the colour to match on both. The killer with colour problems is that it's not a problem until you see it and then you can't un-see it.
On my Samsung Note 8, photos are rendered with very different colors in email previews vs if you download then view them, the email preview shows the colors as being very blown out.
These issues are much less about wanting the color that shows up on the user’s screen to precisely match the color the designer intended, and far more about making sure that if you send the same color to display on the same screen via PNG, WEBM, WebGL and CSS, that they should end up looking the same.
If you’ve got an embedded video that has inter titles whose background color is the same corporate red as your webpage header, you should be able to get the pixels to be the same color, right?
First thing I do when buying a new TV/monitor is search the internet for others calibration efforts (usually avforums). It's amazing what even basic calibration like this can do to improve image quality (unassisted by professional tools).
For anyone looking to get a better understanding of digital color, I'd recommend "The Hitchhiker's Guide to Digital Color":https://hg2dc.com/. The tone is a tad rude at times (though it's not directed at you), but it's done a good job of explaining stuff to me so far (I haven't finished reading it yet).
I wish all browsers would heed color space hints consistently. Seems like some things are always going to assume the generic sRGB, and some thing will notice the profile and convert accordingly.
One good thing about HDR is that it is sort of forcing more software to address color management in some way, because you simply can not mix SDR and HDR content without some color management.
I made https://colorcontroversy.com/. At some point I should go through the logs and figure out which colors are the most controversial across different browsers.
There was a website that showed different browsers rendered CSS differently, it reminds me vaguely of a square / maybe divided in triangles. Anyone know the website? I have been looking for it but to no avail.
It is not perfect, but Apple at least does this on every piece of hardware as it finishes assembly. Of course things slowly get out-of-spec from there, but at least they try.
It's an image from one of the examples showing the situation. Specifically, this is how Firefox renders the different videos.
> There is a lot to unpack here. Since 709.mp4 and 709vui.mp4 look the same, we can deduce Firefox assumes BT.709 when the VUI is not present. 601vui.mp4 rendering correctly means the VUI is honored for BT.601 content. However, when a BT.601 file without a VUI is rendered as 709 it becomes very dark. Obviously, it's impossible to render things correctly without the necessary information, but the choice Firefox made distorts the color more drastically than the method Safari and Chrome use.
mmcclure|4 years ago
Probably unsurprisingly, the (honestly absurd world of) color is a pretty consistent topic among video engineers. Color theory is one of those areas that people working directly with it see it as a completely unsolved problem, and everyone else largely takes it for granted. This is a small sample size, but these are all talks just from a local SF Video meetup and the Demuxed conference, and the speakers work at YouTube, Vimeo, Mux, and a fruit company.
Color (SF Video 2016) - https://www.youtube.com/watch?v=PiAiOl1Pvgk
Early Experiments in Color Vision and Their Applications to Modern Color Theory (SF Video 2017) - https://www.youtube.com/watch?v=fXd6HLqpoMk
A Jaunt Through Color Technology in Video (Demuxed 2017) - https://www.youtube.com/watch?v=XMnvY7a4-As&list=PLkyaYNWEKc...
Your browser and my browser see different colors (SF Video 2020, by the author of this post) - https://www.youtube.com/watch?v=9JXx0bao7ho
jdashg|4 years ago
There are definitely cases where it's clear what we (as browsers) are supposed to do, but some implementations have chosen to err on the side of user preference rather than correctness. I hope we can move that needle back towards "implement the specs". There's no good reason for any 601- or 709-marked content to display incorrectly in the year 2021.
Unfortunately, if you don't mark the videos, that's on you though. Fwiw Firefox generally does follow Chrome in inferring unmarked bt601/709 based on size: https://searchfox.org/mozilla-central/rev/1df3b4b4d27d413675...
Honestly I would rather issue warnings in these cases rather than silently guess.
rwxsh|4 years ago
Speaking non-officially as a browser implementer, VUI isn't always reliable as a source of color, both because the encoders don't always know, and the decoders don't always extract it reliably. The container is a more reliable place to put it (eg. MP4 'colr' box).
Browsers do differ in behavior when these sources of metadata differ. It currently looks likely that WebCodecs will require implementations to use app-provided color metadata over in-band metadata, which would be good for interoperability!
Daiz|4 years ago
https://daiz.github.io/yuv-to-rgb-in-html5-video/
Sad to see that even today the results don't line up with the expected... and in different ways than before, even?
Something the article doesn't touch upon is that colorspace assumptions can also vary between different video formats across browsers (at least back when I made this test), which adds another unfortunate dimension into the color accuracy mess.
Anyway, good to see more attention brought on the subject once again, though unlike the article, I would personally say that if we're going to make assumptions in the absence of concrete colorspace information, I think we should rather consistently assume BT.709 rather than BT.601, for the simple reason that we can reasonably expect that basically any camera in existence today would likely record in BT.709 by default, and I'd expect most editing software with their HD presets and whatnot to default to BT.709 as well.
[1] A related comment I wrote on HN about it back in the day: https://news.ycombinator.com/item?id=12022163
KONAir|4 years ago
I was told search for "perfect" parity across users was in vain because perception of colour varied too much, from blood sugar level to physiology and etc. What is the true benefit of going after this on software side? I mean I am not understanding the difference it causes on artistic statement or emotional impact.
I understand and support "true colour" across all hard/software but is it really that impactful?
lattalayta|4 years ago
https://xkcd.com/1882/
magicalhippo|4 years ago
[1]: https://archive.org/details/ColourfulNotions
formerly_proven|4 years ago
Colors that can be stimulated using a single wavelength are spectral colors, which are only a small subset of perceptible colors. In the CIE xy model, spectral colors are on the curved boundary, while the straight boundary is the line of purples - impossible colors.
Edit: And because CIE XYZ is used as a sort of universal connecting and definition space, all our color spaces are defined in terms of it. But this leads to a the-map-is-not-the-territory fallacy: CIE XYZ was based on just a handful of observations and generously extrapolating. CIE XYZ does not define the set of visible colors. It's a map of colors.
---
This post is about conversion from the video's color space to a rendering color space, and the problems with that. Another fun question is whether that rendering color space is actually the display device's color space, or nah. While browser do output color management (i.e. they use the color profile of the output device and convert all their output to the ad-hoc color space that represents), I don't think they do that for video actually. In fact, there are virtually no video players supporting color management on the output side of things.
galad87|4 years ago
I would hope that similar frameworks on Windows and Linux distributions are too.
mncharity|4 years ago
[meta] Proper colorspace support and color rendering for video playback https://bugzilla.mozilla.org/show_bug.cgi?id=1494381
Properly support ICC v4 profiles and enable it https://bugzilla.mozilla.org/show_bug.cgi?id=1500737
And many more https://bugzilla.mozilla.org/buglist.cgi?quicksearch=color+m...
smallstepforman|4 years ago
zokier|4 years ago
> There are many systems involved to turn an RGB triplet value into a specific wavelength of light
I think this wavelenght-color connection, often perpetuated in high-school classrooms, confuses people more than helps. In particular when talking RGB colors, your display (or really, any part of the process) will not really change the wavelenghts of outputted light based on the input.
Also colors really are not just wavelengths in EM spectrum. Color is more of a perceptual phenomenon, something that happens in our heads, more than physical phenomenon. And there are many things that can impact the color perception, most obviously the other surrounding colors and ambient lighting.
JJMcJ|4 years ago
Paradoxical title - for the notion that magenta is something we perceive, not a wavelength.
An example of https://en.wikipedia.org/wiki/Spectral_color#Extra-spectral_...
vlovich123|4 years ago
Color reproduction is 100% an engineering thing about wavelengths. To my knowledge monitors do indeed change the wavelength. Sure it’s several separate colored emitters, but using constructive and destructive interference to generate a wavelength doesn’t take anything away from it.
There are places where things get messy where reproduction blends in a bit of production (eg applying an HDR filter, applying monitor-specific tweaks, etc). It’s a complex topic for sure. But the position of “color is purely a perception in our head and not wavelengths” position is too extreme in the opposite direction and isn’t helpful in building things.
Theodores|4 years ago
The Mozilla JPEG encoder mozjpeg assumes a high density digital display and encodes for that, typically with less banding but softer.
Not a lot of people cared for mozjpeg and the barely perceptible differences, even though file sizes were smaller into the deal.
This experience made me aware of how few people are working at the cutting edge of image processing, for images or video. It is amazing how much we take their work for granted.
Frustrating differences may be between screens, browsers and operating systems, we are lucky to have what we have got and also lucky to have such forgiving eyes. The whole shebang is nothing short of a miracle.
mncharity|4 years ago
A 5-year old asks you "The Sun is a big hot ball! What color is the ball?". What do you tell them? They ask "And sunlight?" You say?
Most first-tier astronomy graduate students simply get Sun color wrong. A widespread misconception, perhaps first learned in Kindergarten, then reinforced by incorrect textbooks, persisting unintegrated into grad school. But more interesting here, is that first-tier non-astronomy physical-sciences graduate students often answer with some variation on "it doesn't have a color; it's rainbow color".
Confusing wavelength and spectrum and optical color. As in TFA, and discussion here. So I suggest very few people have a firm grasp on even core basics of color theory.
OT (from an email draft in my other window): What if those students had instead learned Sun color correctly in Kindergarten? How might it then have been used over the years, to teach other topics better? For example, color is often taught preK-1. So how might color be better taught, with improved conceptions, progressions, and interactives, building in part on this firmer grasp of Sun color?
recursive|4 years ago
boulos|4 years ago
At the time (again, like a decade ago) at least, it was roughly: Firefox thinks every JPEG is sRGB and every PNG is “huh?”, Chrome got JPEG right (treat as sRGB when no profile is present) but couldn’t do Adobe RGB (and wouldn’t even open a TIFF), and Safari used Apple’s long-standing color code to basically get this right (though I don’t recall if it went with “assume sRGB if no profile”).
I’d be curious to reproduce those old results, especially given the cool “oh yeah, Chrome doesn’t show the same colors in software mode” shown here!
galad87|4 years ago
> If you are using ffmpeg and you don't have color flags set, you are doing it wrong.
This.
Set the color tag in your files. Please.
IshKebab|4 years ago
rorykoehler|4 years ago
mmcclure|4 years ago
Ultimately we decided to just use a gif, but the other, more fun solution we experimented with was to use canvas to render the video, grab the hex value from one of the purple pixels, and set the background to that[2].
[1] https://2019.demuxed.com
[2] https://codesandbox.io/s/video-canvas-playground-gp0hk?from-...
mywacaday|4 years ago
com2kid|4 years ago
Color spaces are hard yo.
jameshart|4 years ago
If you’ve got an embedded video that has inter titles whose background color is the same corporate red as your webpage header, you should be able to get the pixels to be the same color, right?
tomnipotent|4 years ago
First thing I do when buying a new TV/monitor is search the internet for others calibration efforts (usually avforums). It's amazing what even basic calibration like this can do to improve image quality (unassisted by professional tools).
unknown|4 years ago
[deleted]
jdashg|4 years ago
zamadatix|4 years ago
maroider|4 years ago
tingletech|4 years ago
https://www.littlecms.com can come in handy if you have tricky color space issues.
zokier|4 years ago
lrobinovitch|4 years ago
simy|4 years ago
xnx|4 years ago
dredmorbius|4 years ago
cratermoon|4 years ago
pmoriarty|4 years ago
larkost|4 years ago
bloaf|4 years ago
billytetrud|4 years ago
mmcclure|4 years ago
> There is a lot to unpack here. Since 709.mp4 and 709vui.mp4 look the same, we can deduce Firefox assumes BT.709 when the VUI is not present. 601vui.mp4 rendering correctly means the VUI is honored for BT.601 content. However, when a BT.601 file without a VUI is rendered as 709 it becomes very dark. Obviously, it's impossible to render things correctly without the necessary information, but the choice Firefox made distorts the color more drastically than the method Safari and Chrome use.