71–80 of 88 posts
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.
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 ot…
I suppose that makes yet another fingerprinting method.
Earlier quoted context omitted.
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 webpag…
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.
Earlier quoted context omitted.
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…
[1] https://github.com/web-platform-tests/wpt [2] https://wpt.fyi/
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!
Earlier quoted context omitted.
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…
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/
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.
Earlier quoted context omitted.
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.
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.
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
Earlier quoted context omitted.
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.
My result: Yes, they are. Totally different. Crab people everywhere. Player does not matter.
(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…
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
