That annoying shade of blue (2018)
bsago.me
bsago.me
In Vim it's been a fixed problem for ages if you use "set background=dark" by the way.
This was not an issue on computer monitors that were meant to display crisp text.
It's not great for terminal text on a black background, but it's better than the CGA palette, IMO.
Since it’s a digital signal, levels are dictated by IBM hardware. I remember there were numerous different monitors with slightly different palettes (defined by resistors between reference voltages and the analog electron gun power)
Like: for each character cell on this terminal, we have an eight-bit memory budget for color. For each of foreground and background, we're going to allocate one bit for "bright" and one bit each for "red", "green" and "blue" ... in the output circuit to the DAC that drives the display, we're going to send a full-scale value for each of R/G/B when the "bright" bit is set and a half-scale value when it's not set.
Here is a photo i took some time ago from a CRT and a flat panel i have with the same software showing the same picture (with the picture at the top) - both monitors are of relatively high quality:
https://i.imgur.com/xlsGRRw.png
In both images you can see the pixels clearly and that was in 640x480 (which doesn't get double scanned) for the CRT - they also pretty much look the same (the small color fringes are because of my awful phone camera, in person they are almost identical).
Here is another one, same shitty camera (hence the glow) but at the top left and right side (where there isn't much glow) you can see how clear the pixels are - this is double scanned:
https://i.imgur.com/10oa6xe.jpg
The main difference between decent CRT monitors and flat panels is that with the CRT monitors you get to use a bunch of different resolutions without visual degradation from scaling. Also scanlines, but that depends on the CRT (more visible in larger CRTs with lower resolutions) and you get a somewhat similar effect with some flat panel monitors (especially larger ones). Beyond that when there isn't any scaling (i.e. both display the art pixels at 1:1 ratio) there will only be very minor differences. Anything else would be due to a faulty CRT (nowadays many are in bad condition due to their age) and not really inherent in the tech.
LCD sharpness was basically mind-blowing in comparison at the time.
Even some early text mode computers used a colored/bright background - my personal experience was on the TI-99 in its onboard BASIC environment.
Scanlines were normal at the time - I think we only see them as ugly now after getting used to LCDs.
(Of course, that wasn't always the case: the Sinclair ZX81 and ZX Spectrum, both very cheap microcomputers introduced in the early 80s - and I think also maybe the Acorn Electron - defaulted to white backgrounds.)
I think the sensible use case for this color is as background color, like the Norton Commander, derivatives of it, and several other ncurses programs do.
That means that a half blue (00 00 7F) would be 22% as bright as full blue (00 00 FF) with an apparent luminosity (Lab) of 2.2% compared to full green (FF 00 00) or 1.6% of the luminosity of full white (FF FF FF). No wonder it's hard to see!
There is a thing called white balance. Although the eye/mind will adjust to different levels of blue (absent an environmental source) the apparent 10x gain adjustment needed to do this is unlikely to be effective or comfortable to anyone using such a monitor. I suspect the violet halo of such a "white" would be searing and likely not appear balanced in any way.
[1] https://en.wikipedia.org/wiki/Color_Graphics_Adapter#Color_p...
For example Angband just sets the background colour to black (not sure about Nethack), so if you defined colours that work well on a light background you're still going to have a bad time. Quite a few other terminal programs (especially those using ncurses or other interactive TUI interfaces) tend to set a background colour.
There isn't really a good way to deal with this using the default 16 colours other than never setting any background colours, which can be a bit limiting for interactive applications. The best solution is to have application support for this and using 256 or 24 bit "true" colours (256-colour support is pretty much universal, and 24 bit colour support is very wide-spread).
256 or more colors has the drawback that the user can’t configure the colors anymore to his/her needs (light vs. dark, high-contrast, color blindness, etc.), unless the application also provides comprehensive theming support. In that case, the 16-color variant is a much simpler solution.
Small things are important.
A short list of falsehoods programmers believe about vision:
- sRGB is the only graphics standard.
- Monitors are actually sRGB and follow that standard.
- Colour intensities are on a linear scale.
- White is 0x00FFFFFF or 255,255,255
- 50% Grey is half of the above: 127,127,127.
- Blending colours is just a matter of linear interpolation.
- Red, green, and blue have a single consistent definition.
- 8 bits is enough for each colour channel.
- Okay, 10 bits is enough.
- 12 bits is enough, surely.
- 0 means black.
- Okay, 16 means black on televisions.
- Fine, black can have different levels in different standards, but it's always clear which level is black.
- At least the white level is consistently defined.
[1] Narrator: it's not even remotely linear.
[2] Including myself until recently.
I just bought a new 2022 model flagship television, and its colour management is very visibly broken![1] My partner, who knows nothing about colour standards mentioned that she thought the colours were "off" within minutes of using it.
This is the good brand and model according to reviews. I've seen the other brands in the store, and they're markedly worse.
Like... stupidly bad. Garish beyond belief. People looking like they're wearing clown makeup. Normal colours looking like neon tubes.
Are most people colour blind? Am I weird? Did I marry someone equally weird?
Or is it a mistake to just say: red = 0xFF0000, commit the code, and call it a day?
It's probably just me. Never mind.
[1] Unless I connect an Apple TV to it, on which nothing is broken. It's amazing that only one company on this planet is able to comprehend colour. Every other organisation, propriety limited, corporation, and charity is staffed entirely by colourblind people or robots that see only black and white.
One of the most enlightening things for me long ago was trying to write a converter between wavelength and rgb value. It led to all the right questions.
Ultimately I still dont understand color perception. It is hideously complex. But also so fascinating. The mothers of colorblind men are often tetrachromatic. I really wonder what TV's look like to them, since they assume 3 normal frequency responses.
Also, you see people saying "motion smoothing needs to be turned off to respect the artist's intent" but have you seen what those people get up to? It's like a moral obligation to disrespect them.
There are other things to do, but usually just turning down red significantly gets you a lot of the way there for minimal effort.
Generally if you tune your TV to any other "mode" as a base mode, you'll get much better colors. At first it'll look dull next to Claw Your Eyes Out Mode, but stick with it a bit and your eyes will rapidly come to appreciate not being clawed out.
You can also generally find suggested settings for your TV from people who calibrate them with professional tools. You'll see them also say you shouldn't just take them directly because your TV may be different, but from my point of view, the upgrade from CYEOM to "calibrated based on the same model even if it is a different instance" is probably about 99% of the upgrade you can expect and I don't consider the remaining single-percent upgrades that may be theoretically possible to be worth the effort required.
Any half-decent review should mention both out-of-the-box colors and "calibrated" colors, or colors in different modes.
Its kinda open secret that the default modes and settings of TVs are absolute bullshit. Most "good" TVs can be adjusted to decent color reproduction (albeit not always without compromises).
It feels like the tide might be turning; stuff like "Filmmaker Mode(tm)" is popping up, and generally people are becoming more aware of the stuff. But that is not without its downsides, just recently there was a story about how big-box stores are price gouging unaware consumers with their "calibration" services that they are very aggressively selling with TVs.
Did you calibrate the Apple TV using an iPhone? (e.g., https://www.macworld.com/article/344476/iphone-apple-tv-colo...)
If you didn't buy an LG OLED, I also recommend returning it and getting one of those.
I recall there being a particularly contentious bug report for Adobe Photoshop eight or nine years ago. The original thread is here: https://community.adobe.com/t5/photoshop-ecosystem-ideas/p-g... - but all the users have been replaced by "FeedbackCommunityMember", so it's a bit hard to figure out who is talking to who (perhaps someone can find a properly archived url).
In any case, an Adobe product person was unbelievably stubborn about their assumption there is just a single way colours can blend one to another, and that all the other ways couldn't possibly be desirable. It was pretty hard to read.
I remember a youtube video from years ago explaining this problem with photoshop's gradient tool (and other naive implementations), but I can't find it now.
Colors are hard.
Calling this a falsehood isn't even beginning to describe the problem: - does not distinguish between a white surface (reflects all light) and a white emitter (emits blackbody radiation in a specific temperature range) - there is no maximum intensity for emitted light, but there is a maximum for reflection - RGB (255,255,255) does not produce a blackbody curve -- though it can cause the same reaction as a blackbody curve for people with exactly three working cone types. This point may be wrong on this list because it may be thought of as a solved problem. - RGB (255,255,255) does not specify the temperature - that is before monitors even start being imperfect
Oh, and a general one: An emitted color (e.g. monitor) and a reflected color (e.g. printout) cannot be the "same", ever, because only the latter depends on how it is illuminated.
Edit: Oops, I read "there is a maximum for reflection - RGB (255,255,255)" as one statement rather than two fragments but I still like my response. :P
Maybe some old night scopes with photon amplifiers could be coaxed into making "over 100% reflective" mirrors? A fun idea to reasearch.
Also, in TVs it's 16-235 not 0-255. They're not even 8-bit!
Surely there is a case when the light coming into your eye is the same for both? If the printout is lit by the monitor wouldn't it be the same?
Often this is a daylight lamp shining on the paper with a specified intensity, in an otherwise dark room (I believe) compared to watching the screen in a specific ambient light (again daylight with a given intensity).
- Pixels are squares
- Pixels are as wide as they are tall
- Limiting the colour gradient across an area will make it look smooth (Mach banding yay)
- The number of bytes in a line of an image is bits_per_pixel * pixels_per_line
- High frame rate means smooth animation
- If not instantaneous, it’s linear
- The phosphor’s response to the gun intensity is linear.
- An isolated lot pixel on a CRT is a circle.
There is no relationship between the physical nature of light and what we call "color". A wave has a frequency. There is no concept of "color" associated to a wave.
We statistically put names on some convoluted detector/brain transformations and everyone does the transformation differently. This is why most of the people agree that a tomato is "red".
As an ex-physicist, I hate to speak about colors in a physical context (and yes, we have charts that show that higher frequencies are "blue" and lower ones "red"). Color is a biological concept and should stay that way.
And then, as a farther, I have to explain to my children the convoluted course on colors in high school in France.
Sorry, I had to let off some steam.
Fundamentally these words have lots of reasonable wiggle room to expand or narrow their definitions. Still, lots of technical domains would like to be explicit about what is meant, especially when reusing common words, which is why man invented the glossary.
Unfortunately this hasn't stopped endless argumentation over whether a tomato is a fruit or a vegetable. For whatever reason, it's often presumed that the definition of fruit used in botany has "won", even though botany has nothing to tell us about what a vegetable is or how to distinguish one from a fruit.
On the one hand you have light waves that hit some receptors in the eye. These receptors (various kinds) sensitive to frequencies according to a function. This creates a specific signal that is analyzed by the brain which assigns a "color" to that signal.
Everyone's, to some extent, functions are different. There is a general trend so most people agree on "colors". When you are colorblind, the functions differ drastically (or are just flat).
This is why "color" is a biological concept (same as, say, "pain") to which we are desperately trying to attach three or four numbers (or, worse, a wavelength)
If you look up some colors in Wolfram-Alpha you will have precise ranges of frequencies, I am not sure they are officially defined ranges, but colors, at least pure colors correspond to physical quantities.
There is some overlap with biology, and there are some colors are special (brown, purple, ...) and can't be defined by a single frequency. Then you can introduce color perception, and how very real and physical red photons are perceived as red, why a combination of red and green photons are perceived the same way as yellow photons and how spectrometers reveal the difference, and how there are no purple photons.
Composite colors are a bit more complicated, you need to add a bit of math (namely, a color space) in order to formally define them from physical quantities, but saying that it is not a physical concept is going a bit far.
No need to make physics more abstract than it is. Because what's next? Temperature is not a physical concept because we don't all agree on how hot something is? Like color, temperature is a well defined physical concept that is based on our perception.
Or in other words: is "salmon", "fuschia" and other colors located on the frequency spectrum? If so - why do we have zillions of color spaces instead of just a simple frequency? (or wavelength)
At the moment when you introduce color spaces, you start accounting for how our eye receptors are sensitive to frequencies and leave the realms of physics (mostly because the receptors differ from person to person)
When you take a 450 THz wave, you say it it is "unambiguously red" because it is what happens to be the word for the signal which is triggered by that wave. In most of the people. Roughly the same way.
What I am trying to say here is that a color is a concept as well defined as "pain". You can have all sorts of measures, but none is strict.
Finally, there are no "red photons", or green or blue (you mention them) - this simply does not exist at all as a concept.
Funny because when I explained radiant heat to my daughter I used it as an example of light, but infrared is a color we can’t see (but we can feel the light the same way we feel the sun on our skin). She asked about other colors and I went into ultra violet, X rays (a color to which we are transparent), gamma rays, and so on.
This is absolutely true, but the wave does not carry any of these sensations on its own, it is its interaction with sensors/receptors in her body that creates it.
Like I said elsewhere, a color is like pain - a needle does not have any "pain" in it and a couch hit with a needle will not create "pain".
Hear, hear. A neat tool to tell you who will be able to read a combination of background and foreground colors: https://www.whocanuse.com/
It's really hard for a terminal developer to trust that what it looks like on your system looks much at all like it will for your users.
Also, I see with the new Windows colors that black has a glow now? Does anyone have any more screenshots of that or is that just something the author added? I ask because it is 100% solid black everywhere for me still.
At least some of the colors weren't pure binary RGB values as claimed in the article. For example, "dark yellow" was closer to a brown #804000 than #808000. Maybe that depended on the graphics card? Otherwise, I'm not sure why many terminal emulators would have gone with a pure dark yellow instead.
Also, maybe the overall contrast was lower on CRTs. At least I think the blacks were less dark on early monitors, which might have helped to make the colors look less harsh.
Unfortunately a lot of terminal emulators get it wrong, the normal colors are too dark and the intensified ones are too saturated!
I also remember blue being easier to see in the past, but that is likely my eyes getting worse.
My advice with respect to Emacs themes, the built in themes are quite good and especially the modus themes (and also the package ef-themes) both by Protesilaos Stavrou.
a) how far apart each of the color pairs was from one another (hue only),
b) how far apart each dark/bright color in a pair were from one another,
c) how high the contrast against a specific background color (provided as a parameter),
d) how far the perceived brightness of any "bright" color differed from the rest of the "bright" colors,
e) how far the perceived brightness of any "dark" color differed from the rest of the "dark" colors,
f) how far each of the 8 base colors strayed from a range that could passably be called the de facto colors mapped to each of the palette members (e.g. cyan, blue, black, white, etc) so that TUI apps using colors not to distinguish but to draw (expecting "blue" to be a shade of blue) would not be thrown off.
Unfortunately I never found the results to be pleasing to the eye. I also think there was something wrong in either the math of the individual cost function factors themselves or the weights assigned to each factor because I didn't feel like the results were properly spaced out or representative of what even a local minima what look like if the math was all correct. I didn't really want to put more time into it than I already had, but I'm convinced that it's possible to generate a fixed set of 2x8 colors that meet these conditions for any given background color (at least one for a black or dark grey background and another palette for a white or off-white background).
The author is just using a terminal with non-sensible defaults (on way more things than color palette), but tries to pin the flaw into everything else (from nethack to our eyes), instead of putty.
It was also more common to adjust brightness and contrast to suit your preferences. A blue like 4 wasn’t necessarily as invisible then as it is now with our perfectly linear and 100% responsive screens.
Is it really hard to understand why these colors were chosen? #000 = black. After that, just iterate through the combinations of each combination of replacing the 0 with an F. Full on, full off. That's your choices. never mind 1-E of the in betweens.
It was frustrating to have such a fast computer, high resolution (640×256) and be stuck with those awful colours.
OTOH, the BBC’s palette matched the one from Videotext.
Naturally I have given much thought to what the next step might be.
No, not prettier pictures, realtime or 3d. All those newfangled mmorpgs took the obvious, and wrong, turn.
Sometimes I think that a different tesselation (than square grid. Something with more directions). And variable size icons.
Would that detract?
On "graphical" games, Shadowrun for the Genesis with the 2058 patch (ips.pl it's your friend) it's the only "modern" game I play.
And yet Shadowrun pales against Nethack/Slashem's interactivy between monsters, objects, statuses and the world.
I used to think this was limited to computer monitors until I saw a large piece of stained glass that on which the artist juxtaposed red glass and blue glass to the same effect. It was fascinating.
It's the blue and yellow only, but IMHO it made Solvespace a lot more readable.
Irritating for screen sharing with people who use default putty settings, small size courier new, default colors. Ugh. Savages.
I had one where I had to change settings to keep any text with red from being a muddy mess.
They mostly don't even use good resampling algorithms either.
I'm visually impaired, so if I were to screen-share my PuTTY window, you'd be treated to 22-point bold Consolas and mostly white on black.
This points out, though, that for accessibility, frame-buffer sharing is really not ideal. What we really need is some kind of high-level content sharing, where the content is re-rendered on the viewer's machine with their settings.
I wish Git(Hub|Lab) READMEs could embed asciinema sessions instead of blurry, bulky, un-seekable GIF clips.
>Impossible Colors:
Ah yes, MAGENTA+CYAN. Everybody's favorite palette.