[HN Gopher] Different browsers see different colors
___________________________________________________________________
Different browsers see different colors
Author : slimscsi
Score : 136 points
Date : 2021-05-26 17:13 UTC (5 hours ago)
(HTM) web link (mux.com)
(TXT) w3m dump (mux.com)
| formerly_proven wrote:
| > 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.
| galad87 wrote:
| 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.
| cratermoon wrote:
| 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.
| tingletech wrote:
| 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.
| zokier wrote:
| 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.
| galad87 wrote:
| > 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.
| pmoriarty wrote:
| I wonder if there'll ever come a time when display calibration at
| the hardware level ever becomes common in consumer products.
| larkost wrote:
| 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.
| rorykoehler wrote:
| 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.
| mywacaday wrote:
| 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.
| mmcclure wrote:
| 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].
|
| [1] https://2019.demuxed.com
|
| [2] https://codesandbox.io/s/video-canvas-playground-
| gp0hk?from-...
| jameshart wrote:
| 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?
| munk-a wrote:
| 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.
| com2kid wrote:
| 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.
| speedgoose wrote:
| Some smartphones have a feature to "enhance" the colours
| automatically. You should check if you have such a feature
| enabled.
| com2kid wrote:
| 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.
| tomnipotent wrote:
| > 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).
| zokier wrote:
| > 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.
| JJMcJ wrote:
| 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_...
| vlovich123 wrote:
| 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.
| willis936 wrote:
| 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).
|
| https://en.wikipedia.org/wiki/Cone_cell
| mncharity wrote:
| > 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...
| mncharity wrote:
| > 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?
| recursive wrote:
| I don't even know what the confusion is. Is the sun not white?
| It looks white.
| z2trillion wrote:
| 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.
| glandium wrote:
| Interesting related fact: Kids in the west usually draw the
| sun yellow, but in Japan, they draw it red.
| mncharity wrote:
| 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...
| mmcclure wrote:
| (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
| jdashg wrote:
| 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.
| Daemon404 wrote:
| 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)
| rwxsh wrote:
| > 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!
| Daemon404 wrote:
| 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."
| lattalayta wrote:
| 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)
|
| https://xkcd.com/1882/
| munk-a wrote:
| I've always found it interesting that XKCD uses a slightly
| beige background color in all of the comics.
| KONAir wrote:
| (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?
| jdashg wrote:
| 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.
| thefounder wrote:
| 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.
| jdashg wrote:
| 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])
| zamadatix wrote:
| I think 255 is reserved as well.
| simy wrote:
| 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.
| xnx wrote:
| http://acid2.acidtests.org/ ?
| djxfade wrote:
| Oh, ironically, this old test breaks on Google Chrome
| 90.0.4430.212 on macOS.
| barosl wrote:
| 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?
| rootusrootus wrote:
| 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.
| simy wrote:
| Nope, that's not it :(
| arendtio wrote:
| http://acid3.acidtests.org/reference.html?
| laumars wrote:
| 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?
| Theodores wrote:
| 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.
| [deleted]
| cratermoon wrote:
| Yeah, colorspaces are deep voodoo (but good voodoo). I say that
| as a photographer who started out before digital imaging was a
| thing.
| IshKebab wrote:
| This is a really great article! That fi ligature in the
| monospaced font makes my eyes twitch though.
| billytetrud wrote:
| I don't get the image at the top. Why are they showing a
| different color in the two left most squares?
| mmcclure wrote:
| 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.
| billytetrud wrote:
| 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?
| mmcclure wrote:
| Ah got it, those are the value it's rendering as, all of
| them were encoded with the exact same green.
| billytetrud wrote:
| Ah gotcha. I expected that's what it had to have meant,
| but it wasn't clear just from looking at the image.
___________________________________________________________________
(page generated 2021-05-26 23:00 UTC)