Very nice!

Ah okay yeah I see. Sub pixel antialiasing definitely goes wrong with an unexpected layout. Will your test be able to make a distinction between that and 4:2:0 chroma subsampled signal that also breaks ClearType?

Alright actually there was a linear regression fit to the hue experiment data, presumably via the "reg post" and "reg pre" buttons in the screenshot earlier. Constraints such as constant lightness was verified visually by plotting other datasets. Makes sense Oklab could improve on it.

Also, had to wait until page 107 before I found the first joke. And uh, the IPT color space based on the experimental data was interactively tweaked by hand in a GUI instead of a numerical fit?

The GOTOs discussed in the paper are closer to setjmp and longjmp and not the "goto" keyword in C that's restricted to the function scope. So definitely scary from a modern perspective ("a function can return to _anywhere_ in the program??") but also totally extinct, except ofc in assembly language.

Is "de-fringing" something you need only on HDR content or something more general? I couldn't find a test with that name on the testufo site.

Whoops here's a fixed link en.wikipedia.org/wiki/Color_a...

My apologies, I only tested the download links locally. Should be fixed now. And thanks for the interest.

It's a good question. Fabien Sanglard's book suggests the palette conversion was done on a NeXT workstation before being transferred to a DOS machine for a Deluxe Paint clean up. But no mention of the palette origins.

Really makes it sound like a bigger deal than it is

Perhaps in that case it's also possible to fit some kind of better weights of the filter kernel? At least if you focus on a selected corpus of images.