Tell me someone has turned this into a library we can use
Well there's aalib and libcaca, but I'm not sure about their fidelity compared to this.
ASCII characters are not pixels: a deep dive into ASCII rendering
11–20 of 158 posts
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#12Tell me someone has turned this into a library we can use
Don't know what algorithm are used by the famous libcaca:
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#13> To increase the contrast of our sampling vector, we might raise each component of the vector to the power of some exponent.
How do you arrive at that? It's presented like it's a natural conclusion, but if I was trying to adjust contrast... I don't see the connection.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#14[deleted]
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#15It's important to note that the approach described focuses on giving fast results, not the best results. Simply trying every character and considering their entire bitmap, and keeping the character that reduces the distance to the target gives better results, at the cost of more CPU. This is a well known problem because early computers with monitors used to only be able to display characters. At some point we were ab…
Thinking more about the "best results". Could this not be done by transforming the ascii glyphs into bitmaps, and then using some kind of matrix multiplication or dot production calculation to calculate the ascii character with the highest similarity to the underlying pixel grid? This would presumably lend itself to SIMD or GPU acceleration. I'm not that familiar with this type of image processing so I'm sure someone with more experience can clarify.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#16Next up: proportional fonts and font weights?
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#17Earlier quoted context omitted.
In practice isn’t a large HashMap best for lookup, based on compile-time or static constants describing the character-space?
In the appendix, he talks about reducing the lookup space by quantising the sampled points to just 8 possible values. That allowed him to make a look up table about 2MB in size which were apparently incredibly fast.
I've been working on something similar (didn't get to this stage yet) and was planning to do something very similar to the circle-sampling method but the staggering of circles is a really clever idea I had never considered. I was planning on sampling character pixels' alignment along orthogonal and diagonal axes. You could probably combine these approaches. But yeah, such an approach seemed particularly powerful for the reason you could encode it all in a table.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#18Great breakdown and visuals. Most ASCII filters do not account for glyph shape.
It reminds me of how chafa uses an 8x8 bitmap for each glyph: https://github.com/hpjansson/chafa/blob/master/chafa/interna...
There's a lot of nitty gritty concerns I haven't dug into: how to make it fast, how to handle colorspaces, or like the author mentions, how to exaggerate contrast for certain scenes. But I think 99% of the time, it will be hard to beat chafa. Such a good library.
EDIT - a gallery of (Unicode-heavy) examples, in case you haven't seen chafa yet: https://hpjansson.org/chafa/gallery/
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#19Nice! Now add colors and we can finally play Doom on the command line.
More seriously, using colors (not trivial probably, as it adds another dimension), and some select Unicode characters, this could produce really fancy renderings in consoles!
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#20Well-written post. Very interesting, especially the interactive widgets.