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
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.
You can see this, for example in Firefox's image pipeline which seems to assume everything is 601 (because JPEG), and this means 709 AVIFs won't render correctly (and are thus off by default currently).
Or in Chrome, the MediaRecorder API will create HD H.264 streams that are untagged, and are 601. Which Chrome then assumes is 709 based off the res.
Or, also in Chrome, the WebCodecs team not having talked to the Media Team, seemingly (?) before starting work on what kind of buffer gets returned to the user, and what the semnatics of its color are. (I think this is resolved now, though - this was a year or two back when they engaged with VideoLAN over this API)
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!
Intead we get: "Colour information may be supplied in one or more ColourInformationBoxes placed in a VisualSampleEntry. These should be placed in order in the sample entry starting with the most accurate (and potentially the most difficult to process), in progression to the least. These are advisory and concern rendering and colour conversion, and there is no normative behaviour associated with them; a reader may choose to use the most suitable."
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
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?
I think the issue is more about consistency than true color/fidelity as true fidelity/color sharing between individuals is impossible at this time. Professional video equipment exists for a reason.
Another is the desire for product photos to look relatively true-to-life, so you don't order something and it's too dark, or too red, etc.
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 would hope that similar frameworks on Windows and Linux distributions are too.
[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...
> 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.
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.
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?
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!
> 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.
The spec isn't that bad to read, though it's not loading for some reason right this moment: http://www.itu.int/rec/R-REC-BT.709-6-201506-I/en
https://www.littlecms.com can come in handy if you have tricky color space issues.
> 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.
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_...
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.
As an illustration for the in your head position: Human eyes can't directly perceive yellow tones. What we think of as yellow is a computation on the signals of both the M and L cones. If both say they perceived radiation at approx. the same intensity, that gets calculated as yellow afterwards.
That's why RGB displays are not reproducing the correct wavelengths, but only those our eyes can read directly: red, green and blue.
Coming back to the color of the sun, it (the sun + the atmosphere) emits light over a range of wavelengths, which we usually perceive as white.
As for the confusion... oh my, such a rich area.
The Stanford Solar Center outreach site[1] could be a fun place to start. It manages "It is a common misconception that the Sun is yellow, or orange or even red." On a site heavily themed in, yes, yellow and orange and red. Other outreach sites don't even manage that warning, despite similar colors. It then continues with a common color misconception "However, the Sun is essentially all colors mixed together, which appear to our eyes as white." Followed by a miscolored ground spectrum[2], of which there's a diversity[3], on a page named GreenSun, reflecting a misconception that ground irradiance spectrum peaks in green (rather than 490 nm cyan/blue), and another misconception that spectrum peak determines object color, and thus another that the Sun is in some sense green.
In US popular culture, Sun color is yellow[4]. And that's pervasively used in K-12 astronomy and earth sciences illustrations, competing with orange.[5]
Astronomy textbooks, including the top 10-ish introductory astronomy college texts (thanks Library Genesis!), similarly use yellow. This is reinforced by "G2 class yellow star", while failing to mention that classification's blue "white"-point (Vega). And further reinforced by a diversity of aphysically colored H-R diagrams.[6]
We've known Sun color for a century, had detailed limb darkening and tint numbers for decades, and now years of intensive effort on stellar atmospheres in support of occultation and exoplanet work. And science education content manages to remain decoupled from all of that.
Confusion... sigh. There's a physics education research line, "if you think your lectures are working, your assessment also isn't". I'd extend it to "if you think your science students, content, and instructors, aren't deeply steeped in misconceptions, then your knowledge of your field's education research also is". Confused mess doesn't begin to cover it. The juxtaposition of good caring people putting in lots of (tragically not-broadly-collaborative) effort, with baseline that's so very ghastly... sigh.
If you know of anyone/project/lab/forum/etc with an interest in speculative exploring "what might science education conceptions/progressions/interactives look like if they weren't a disaster?", even if, as with Sun color, there's little hope of fixing it any year soon, I'd very much appreciate hearing of them. Thanks!
[1] http://solar-center.stanford.edu/SID/activities/GreenSun.htm... [2] http://solar-center.stanford.edu/SID/activities/images/solar... [3] https://www.google.com/search?q=solar+sunlight+spectrum&tbm=... [4] https://www.google.com/search?q=drawing+of+Sun&tbm=isch [5] https://www.google.com/search?q=solar+system&tbm=isch https://www.google.com/search?q=winter+summer+sun+diagram&tb... [6] https://www.google.com/search?q=Hertzsprung-Russell+Diagram&...
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].
[2] https://codesandbox.io/s/video-canvas-playground-gp0hk?from-...
I suppose that makes yet another fingerprinting method.
Color spaces are hard yo.
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).
Even microLED spikes are tens of nm wide.[1] Calling that "one wavelength" seems problematic, given all the confusion here today, and in TFA, between wavelength and spectrum and perceptual color.
[1] https://www.researchgate.net/figure/a-Measured-RGB-red-green...
My result: Yes, they are. Totally different. Crab people everywhere. Player does not matter.
All modern phones have some sort of friendly color space selector, this particular Samsung is set to be rather neutral. The interesting part is how dramatically different the preview in gmail is vs the photos app. My guess is Gmail is just doing something horribly wrong with the attached color profile in the photo.
Chrome and Safari both fail to complete acid2 and acid3 for me on MacOS.
[1] https://en.wikipedia.org/wiki/Acid2#Timeline_of_passing_appl...
[1] https://github.com/web-platform-tests/wpt [2] https://wpt.fyi/
What has changed is that more functionality got pulled into WebCodecs as it became clear that existing web platform objects (eg. ImageBitmap) were not an ideal fit.
Unfortunately, WPT is missing the actual feature that made the Acid tests interesting: a design that could be used and understand by anyone. Most people are not going to go do the incredibly complex work required to actually run the WPT tests (which apparently involves its own command line utility to manage the process, requires knowledge of python/pip/virtualenv, and understanding platform-specific documentation for both setting up and running the tests.
For Acid2/Acid3, anybody could simply load the test URL to run the tests themselves, on their own browser and OS, and see the results first-hand. It doesn't matter that most people didn't know the various CSS/Javascript/etc features being tested. Seeing that your browser completely failed Acid3 was obvious[1]. It was exciting to see for yourself if the latest browser update scored higher on Acid3.
But yes, if you want to run the full test suite and get overall results there's more work to do.
