Too Much Color(keithcirkel.co.uk) |
Too Much Color(keithcirkel.co.uk) |
Case in point: many years ago I was working on some software to generate 3D models from drone pictures. The first step of the pipeline was to convert from WGS84 to ECEF (https://en.wikipedia.org/wiki/Earth-centered,_Earth-fixed_co...), an absolute Cartesian coordinate system. Well, it turns out that at the scales involved, 6.371 million meters, 32-bit floats have a precision of half a meter, so the resulting models were totally broken.
Moving to 64-bit floats fixed this issue.
Granted, just storing it as a 32 bit integer is probably difficult for most uses. BCD just isn't common for most programmers. (Or fixed point, in general.)
(It both is and isn't, depending on the use case, but I'm pretty sure nobody's design needs to make a difference between #123456 and #123457.)
Do I need that kind of precision in my CSS? Probably not. But for gradients, it seems helpful.
That said, the article is very interesting, and that claim applies on different contexts. It's just aimed at the wrong one.
Do CSS minifier really adjust the colors in the CSS files to get better compression rates or to reduce the number of rules in the CSS?
Maybe he understands the field so much that he prefers to exercise it minimally in his hobby. Or maybe he just can't decide. It also makes perfect sense for a study in colors to be against a neutral background.
Except for a tetrachromat. Specifically, a strong tetrachromat that has both four colour channels in the brain and a different frequency on the fourth cone.
Who are, admittedly, hella rare. Apparently there are less than a few dozen confirmed world-wide.
But they do exist.
What is a NASA number?
Allegedly, within NASA, there is only a need for so many decimal places. If I can remember correctly, nine digits would get a spacecraft to land within a metre on the rock formerly known as the planet Pluto. So no need for that, unless you are going to 'occupy Pluto', building a few AI datacentres there.
In the context of SVG, usually it is icons that I encounter, where the artworker has exported something like a search icon, which is a circle and a line. These can be specified in SVG using integers, and single digit integers, if you really want, but let's make it two digits.
However, does the SVG file from the artworker have a viewbox containing a circle and a line? Nope. Instead you get one circle for the outer part of the circle in black and another smaller circle in white. Oh, and a line. The circles will be written as polygons with about two hundred vertices, with all vertices specified with NASA numbers (as I call them), typically six decimal places.
As a consequence, the file, which should be six lines of human readable code balloons to many kilobytes of nonsense. Yes, this can be put through SVGO but that will just remove some decimal places and make the file even less human readable.
As a developer, the simple file is great as the inevitable adjustments can be applied easily, maybe to make the icon bold or to adjust alignment within the viewbox. However, when given artworker files with NASA numbers, I then have to raise a ticket so that I can get the corrected file two weeks later from the guy sat in front of a massive Apple monitor with headphones welded on.
The reason for not using NASA numbers has nothing to do with bloat, as no optimisation will make up for the mountain of javascript the marketing guys have bundled into their Google Tag Manager, it has everything to do with efficient workflows.
Generally the customer does not care about fonts, colours and much else that designers fret over. If we went back to the 216 'web safe' colours of yesteryear (for CSS, not images), would anyone notice? If we could not load custom fonts, would most people notice? They might, but this would not prevent them from surfing the web.
What's actually hella rare is tests for tetrachromacy. Given the total number of people who have ever taken such a test, I think it's reasonable to assume there are significantly more than a few dozen actual tetrachromats out there.
> More precisely, she had an additional cone type L′, intermediate between M and L in its responsivity, and showed 3 dimensional (M, L′, and L components) color discrimination for wavelengths 546–670 nm (to which the fourth type, S, is insensitive). Source: Wikipedia
It turns out that my left and right eyes are skewed apart along a magenta/cyan axis. Left is more cyan, right is more magenta. It’s not as strong an effect as 3d glasses, maybe no more than a 1-2% light gel, and under normal circumstances I mostly don’t notice it unless I’m doing color matching work.
If I try to do color matching with one eye, it’s boringly fine - 0.0022 JND, same as everyone else above. I’ll get some things slightly wrong as usual, in patterns that make sense for the hue shift.
But when I use both eyes, the binocular process that leads to 3d vision also locks on to color differentials as well as spatial, and synthesizes imaginary color gradients out of flat surfaces diagonally from contrasting corner edges. It’s not a problem for writing on paper or anything, but if you give me a grid of flat paint chips I can order them by hue because their gradient depths are wrong — like, the whole sort by hue in 2d grid thing is just “equalize the difference vector intensity across the vector field” and that’s a nice relaxing thing to do, right? In essence, it’s sort of like MIMO 3x2 vs. normal vision’s 3x1 or tetrachromacy’s 4x1.
I know this isn’t true 4x1 tetrachromacy because I discovered, through the video game Intake (in which I reached 10th place on the world leaderboard), that my ability to snap-differentiate color is considerably more error prone when the two colors are the exact hues of magenta-cyan that my eyes differ by. Which makes sense: those would be my lowest fidelity colors, because they have the least distance from the differential centerline, so trying to figure out which eye to use causes little stutters in my color parsing and more frequent errors in outcome. If it was “the same tetrachromatic in both eyes” I wouldn’t have trouble telling magenta and cyan apart, because I’d have a fourth receptor with which to detect R/B vs G/B shifts easily by their B/T difference.
I’m not sure if this is a normal circumstance or not, but since my vision is extremely bizarre (-5 left, +2 right) and I can function and drive without eye correction due to forming partial stereo depth out of blurry hue fields from the left eye and telescopic light fields from the right, I think that growing up without eye correction forced my brain to use hue matching to stabilize my visual field in the absence of the usual higher-fidelity “both eyes have the same focal plane” convenience that most people have. And my depth perception remains to this day extremely flawed; it works, enough that I can drive with absolute precision, but I can’t catch a thrown object for crap and I occasionally parse 2d shapes with contrast interplay as 3d shapes and then realize a moment later that there is no 3d shape there — painted lines on a particularly damaged bit of road might at first blink read as a curb — b/c my depth perception was formed by prioritizing hue and contrast at a reflexive level.
There’s probably a formula somewhere that I could use to calculate the theoretical boost in hue SNR by modeling two towers, each with tri-frequency radio receivers with slightly offset frequencies, and then calculating the net boost effect of frequency trilateration across a spectrum for radio signals of different frequencies. Someday I hope learn enough about radio to document that and prove where my nodes of worsened acuity are! Not that it much matters, but what a fun test it would be.
Do they?
"This shouldn't be possible. I'm not saying that you cheated, but not not saying that."
0.0011. The quote seems a bit hyperbolic. There were maybe 2-3 that I didn't see and missed. 1-2 that I didn't hit perfectly but close enough. Display probably affects results (but didn't change any settings for this). I have a Dell IPS. I also moved my head around a bit, felt natural while trying to discern the colors.
I do have a good vision (including color). Reminds me of the other color-game where you order some colored boxes to form a spectrum.
Edit: just tried hard mode and got 0.0084. Missed maybe 3 that I couldn't see. Usually some magenta or blue colored. Grey and red / brown seem to be the easiest.
There's was 2 or 3 where i had no idea, guessed and was a way off.
There's was 1 where i did a hail Mary and got it. It was interesting how some even towards the end were really obvious and others were really subtle - I'd say I did better with purple tones and worst with the blue / greys.
I can see what they mean about .02 though. If I weren’t specifically looking for difference that’s where the colors become less noticeable.
In the early 00's, I used two pro grade NEC flat panel monitors... they weighed a lot... my desk at that time had a permanent bow in the middle. It was around 2008 or so when I'd moved them a few times in a year and a half and decided to switch to flat panels... It became very clear to me around that time, that most people really didn't care about color accuracy in designs. Couldn't tell you how often I'd get "it doesn't look like our printed logo" only to adjust their monitor settings and voiala. Even then.
LCD flat panels are much easier to move around without killing your back. OLED is pretty amazing, but I've got to turn my brighness down a bit to make it tolerable... and I just about have to use dark mode. But there aren't many options in the 45" 3440x1440 display range, which is where I'm most comfortable today.
I need a better display for sure :)
I do work with colors pretty much every day as a UI engineer
“Show HN: What's my JND? – a colour guessing game” 54 points | 8 days ago | 62 comments
"Genuinely remarkable. You sailed past the theoretical human limit like it owed you money. I'd accuse you of cheating but I don't actually know how you'd cheat at this."
I'm on a Vivo X300 pro in a dim room, max brightness. Some of these looked impossible but then suddenly I'd see the line.
https://www.keithcirkel.co.uk/whats-my-jnd/ #WhatsMyJND
What's My JND? 0.0072 #WhatsMyJND
> At its core this formula gives you a single number: how far apart two colours look. 0.0 means identical, 100.0 means you're comparing black and white. The magic number to remember is the "Just Noticeable Difference" (JND). For dE00, JND is around 2.0. Below that, people struggle to tell two colours apart. Below 1.0, basically no one can. So anything under 2.0 is "close enough" and anything under 1.0 is "you're kidding yourself."I think it fundamentally comes down to whether your sense anomaly represents a significant disability. Colour blindness is a disability, but not one that's significant for the vast majority of people who suffer from it - I've worked with multiple colour blind graphic designers & they were good at their job. There's very little impetus to even seek diagnosis - if they weren't working in a colour-focused industry I suspect they may not have ever realised they had a disability at all.
Tetrachromacy then is an even harder case because it's not a disability at all. The impetus to seek "diagnosis" is zero. Also, even though as you mention there's technically multiple ways of detecting the various factors that need to coexist in tetrachromacy (i.e. (1) sensory testing, (2) physical presence of extra primaries, (3) neurological processing pathways), the latter two are either not directly detectable or never directly tested for - even in speculative cases of people having a 4th primary, the number of primaries present is generally hypothesised via some other avenue like testing for anomalous trichromacy. Ultimately we're heavily relying on direct sensory testing which is almost nonexistent in the general population. There's no way to accurately speculate on how prevalent it might be.
But any kind of calculation will involve a great deal of trigonometry, square roots, and the like. It is just easier to use floating point. Examples:
https://en.wikipedia.org/wiki/Geographic_coordinate_conversi...
I would actually think fixed point would be beneficial for its accuracy being a bit more controlled than floating point is. Yes, you lose the range of floating point. But I just don't see how that is relevant for numbers that are constrained to +/- 180 by definition.
That all said, I cannot and do not argue against that it is faster to get going with basic float/doubles, due to how commonly those are supported in base libraries.
OTOH sacks seems to have fabricated a lot of shit over the years so who knows if this is even real. Another thing I think about a lot now.