Unicode block glyphs for 2x2 super resolution trick

[tombh]

@blitzcode has come up with an ingenious method to get 2x2 resolution per character! It's in rust, but still, worth bearing in mind that it's possible.

https://github.com/blitzcode/term-gfx/blob/master/src/main.rs

That code also supports true colour terminals, aka, 16 million colours.

[jart]

This is really amazing. I'll have to take a closer look and see what's necessary to implement it in hiptext.

[jart]

• It looks like term-gfx could benefit from my O(1) xterm256 color quantizer (--fast). Consider using that for your X windows program if you want faster rendering.
• One cool feature of hiptext is the Macterm 512-color mode.
• The video preview of your program seems to be using ▒ for normal rendering. Why?
• I might have looked into the quarter block characters in the past but couldn't get them to align correctly. I'll look into it again. Even though it can still only show two colors within the 2x2 matrix, it's still advantageous when rendering the edges of solid color vector images.

[blitzcode]

Happy to answer any questions. It does look quite a bit better than just plain character sized blocks:

http://www.blitzcode.net/rust.shtml#term_gfx

Forget the Rust-factor as the current code is unusable for production use anyway. Both color quantization and finding the best block character is done by brute-force search, you'd need to implement something smarter there ;-) I only did a PoC implementation as I had no real need for this, was just curious if it could be done.

Some fixed-pitch fonts have box drawing / block characters with gaps or users have terminal settings with custom spacing, that might mess up the rendering. But then again, tons of other ncurses style terminal UIs will look equally broken with these settings.

[tombh]

That's a good point about the alignment of quarter-sized blocks, alignment may not be as consistent across fonts/terminals as single and half blocks.

Answering your other points Justine; It's O(1)! Okay, didn't realise that, will turn it on. Ha, I guess that approach won't be so practical for true colour though?

I think it just looks like ▒ because of the gif compression? The video doesn't have those same artefacts https://www.youtube.com/watch?v=TE_D_fx_ut8

[jart]

Ha, I guess that approach won't be so practical for true colour though?

The algorithm only works for xterm256. It doesn't work in --macterm mode since the Mac color palette (AFAIK) was an exercise in "intelligent design" by actual designers, rather than engineers who devised a simple mathematical formula to pick 256 colors. If you're curious, basically what Terminal.app does is it uses a slightly different shade of the same color for foreground and background. So I sat there for a few hours with ColorSnapper and recorded the exact value for each one.

However for true color, quantization isn't necessary, so the algorithm could be circumvented entirely.

I think it just looks like ▒ because of the gif compression?

Makes sense. One thing worth mentioning: years ago I looked into using that dot block to perform shading to get in-between colors. Color mixing is actually a very interesting problem. Our eyes perceive colors in a way that's very different from how they're represented in computer memory. I tried using Kubelka Munk color mixing which AFAIK represents the latest research. It helped. But it still looked ugly. So I ended up not going down that road.

[tombh]

You hand-sampled 256 foreground and another 256 background colours!!? My god.

And Kubelka Munk colour mixing, I was vaguely aware of the theories, but had no idea that particular paper was from all the way back in 1931!