Different browsers see different colors
mux.com(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.
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
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.
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.
It's been my experience that part of the reason browsers get stuff wrong even when it's clear what to do, is that entirely different teams work on parts of the browser that all need a poper color pipeline, and while one team will learn and do it correctly, the new team working on the diffrent part has to go through the same process again.
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)
Honestly a big reason is that there simply aren't tests.
I miss the days when browsers took pride in announcing[1] their new version passed Acid2/Acid3. Sure, the tests had issues, but they were self contained and anyone could see which browsers mostly passed and which were missing half of the features. Unfortunately, the modern trend towards monopoly is increasingly hostile to ideas like "open standards" and "interoperability", so I doubt we'll see this kind of test used again anytime soon.
[1] https://en.wikipedia.org/wiki/Acid2#Timeline_of_passing_appl...
The modern equivalent is the Web Platform Tests[1], which are far more extensive than the Acid tests were. Browser conformance is tracked continuously[2].
[1] https://github.com/web-platform-tests/wpt [2] https://wpt.fyi/
The WPT is the exact opposite of what I was talking about. The interesting thing about the Acid tests isn't their utility as a conformance test. Sure, that's what the were, but even at the time the problems with the tests were well known. The features they tested were incomplete and somewhat arbitrary. Most browsers didn't even bolter trying to get the last 3 points on Acid3, which tested SVG fonts. I'm sure WPT is far more useful from a technical perspective.
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.
If you want to run a specific wpt, you just load the URL. See https://wpt.live/ (which is linked to from the wpt.fyi bits).
But yes, if you want to run the full test suite and get overall results there's more work to do.
I probably shouldn't nitpick here, but Chrome's WebCodecs team is a subset of the Media team. Color simply wasn't the first priority to implement.
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.
> 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!
This is one place the ISOBMFF spec really screwed up, in my opinion. They should have included semantics for the colr box, i.e. which takes precedence.
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."
To add to the resources here, I also ran into this issue a long time ago myself and wrote this little test tool for it some five years ago[1]:
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 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?
We're not talking about perceived colour in these articles. Instead at best we're talking about absolute colour as might be sent over a display cable or as might be presented on a calibrated screen. Even if the screen isn't calibrated or the user is partially colour blind, the values that are sent over the HDMI or DisplayPort cable do still matter. Those values tend to be 8-bit 0-255 values for R, B and G, though that's starting to change. I won't get into how 255,255,255 might be a different colour depending on what mode your computer monitor is in or how your cable signals the mode to the computer monitor, but the point of this article is that the colours in a video can vary based on how and when the video was recorded, mastered, etc. This is partially historical: if watching a DVD you'll have a smaller colour range than if watching a UHD 4K HDR Blu-Ray because back then most TVs couldn't display high contrast images or what we now refer to as HDR or Dolby Vision. There are other concerns, of course, such as framerate and resolution and even the shape of a pixel can change in some video files. So ... it's a complicated topic. :)
I doubt the blood sugar level is more important to color than different display types/models and/or different rendering software.
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.
One of the major user stories is "I have CSS and a video on my page, and my colors should match".
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.
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)
I've always found it interesting that XKCD uses a slightly beige background color in all of the comics.
Which browser are you using...?
Opera version 4 on a Sun SPARCstation 5 rendered in black and white onto a twenty five year old CRT.
Why - is it not beige to some people?
I just took a screenshot of the site and used the color pipette, it's pixel-perfect #FFFFFF white, not beige.
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.
Apple's AVFoundation is color managed: https://developer.apple.com/library/archive/technotes/tn2227...
I would hope that similar frameworks on Windows and Linux distributions are too.
There are for Windows, too. I don't know about Linux. The catch is that for really exact color work, you have to calibrate and tune for your computer/OS/video card/monitor combination, and check the calibration against a known standard periodically. It's a bit of pain.
Well this is pretty easy to test. Use a wide-gamut display and use the display's profile. Yeah, sure that might not be accurate, but it tells color-managed applications what the display color space roughly is. Then play a video. Observe whether the colors are drastically different from no profile and sRGB emulation in the display. In a color managed system, both of these should look roughly the same (and they do).
My result: Yes, they are. Totally different. Crab people everywhere. Player does not matter.
Open firefox tickets:
[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...
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.
https://hirund.in/blog/magenta-doesnt-exist
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_...
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.
No. Displays make (relatively) sharp peak emissions at one wavelength. We blend their relative intensities to trick our mind into thinking it's seeing the wavelength in between those three spectral peaks. All the colors we can see are from the spectral response of our three cones (hence why we use three spectral emission lines). We simply cannot tell the difference between magenta and red+blue. The actual photons are not interacting with each other. Take a prism to your display and you'll see the discrete emissions. This wouldn't happen with an actual magenta emission (which also doesn't exist, further highlighting the limits of color in the human vision system).
> Displays make (relatively) sharp peak emissions at one wavelength.
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...
> 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.
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?
I don't even know what the confusion is. Is the sun not white? It looks white.
I think the confusion arises because because people (the author of the article included) confuse "color" and "spectral color". Spectral colors are what you when you look at light of a single wavelength, e.g. a green 520nm laser pointer. Not all colors are spectral colors, e.g. you'll see purple if you look at a source that produces 600nm and 450nm light, which is a color that can't be produced by any single wavelength.
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.
Interesting related fact: Kids in the west usually draw the sun yellow, but in Japan, they draw it red.
Is that because of how it looks, cultural priming (other similar concepts are red, for example), or because of the red sun on the flag?
Most people describe it as yellow, and if you google image search for "sun", most of them range from orange to yellow. Though it actually covers the full visual spectrum, much of the blue gets scattered, making the sky blue and the sun yellow.
Yes, it's white. In space, and from the ground when it's not near the horizon, under almost all atmospheric conditions.
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&...
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!
> First and foremost, ALWAYS set the colorspace metadata on your videos.
> 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.
This is a really great article! That fi ligature in the monospaced font makes my eyes twitch though.
Screens also display colours differently. Trying to get the perfect colour is futile in the same way trying to get pixel perfect web designs is.
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].
[2] https://codesandbox.io/s/video-canvas-playground-gp0hk?from-...
> use canvas to render the video, grab the hex value from one of the purple pixels
I suppose that makes yet another fingerprinting method.
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.
Color spaces are hard yo.
Some smartphones have a feature to "enhance" the colours automatically. You should check if you have such a feature enabled.
Additional note, this only happens with photos sent from an Iphone. :-D
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.
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?
We are losing the ability to ignore device coloration though - since some activities are intended to be carried out on multiple displays at once (i.e. a phone and monitor or switch with tv display). Being consistent across devices is beginning to matter and is an incredibly hard problem to solve.
I'd argue it's completely unsolvable because devices tend to have different color gamuts. My laptop screen generally covers significantly less of the sRGB gamut than any external monitor I plug into it. Meanwhile the OLED in my phone covers more.
> Screens also display colours differently.
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).
All-zeros isn't even really a valid ycbcr value, since even "full-range" "pc" is 1-255 for cb and cr! (Only full-range y has a range of [0,255])
I think 255 is reserved as well.
Not in full-range. Narrow-range "tv" is [16,235] for Y and [16,240] (128 +/- 112) for Cb and Cr. Full-range is [0,255] and [1,255] (128 +/- 127) respectively.
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
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.
https://www.littlecms.com can come in handy if you have tricky color space issues.
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.
Oh man this brings back memories. Remember when Microsoft used to hardcode acid compliance into IE even though Trident didn’t support half those features in on any other website?
Oh, ironically, this old test breaks on Google Chrome 90.0.4430.212 on macOS.
If you go to acidtests.org, they say the tests are no longer maintained, and that acid3 has some controversial tests that not everyone agrees on anyway.
Chrome and Safari both fail to complete acid2 and acid3 for me on MacOS.
Firefox still has 100/100 on both acid2 and acid3.
Oops, yeah, same here on Chrome 90 on Android. Firefox 88 on Android also has the same problem. What did happen? Was the original Acid2 test wrong?
I see you and raise my (16 shade grayscale) E-ink display.
Yeah, colorspaces are deep voodoo (but good voodoo). I say that as a photographer who started out before digital imaging was a thing.
I wonder if there'll ever come a time when display calibration at the hardware level ever becomes common in consumer products.
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.
Indeed. Apparently the iPhone 12 Pro (and I’d imagine their other phones as well) is very well calibrated: https://youtu.be/n_czpXW3yKE
I wonder if this is why h.265 HEVC video playback on firefox is noticeably darker than in edge/chrome.
I don't get the image at the top. Why are they showing a different color in the two left most squares?
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.
Its labeled with a different color value tho (0, 77, 0). Is it just saying that's the value it is rendering as, but implying that it was encoded as the same green color?
Ah got it, those are the value it's rendering as, all of them were encoded with the exact same green.
Ah gotcha. I expected that's what it had to have meant, but it wasn't clear just from looking at the image.