Tell me someone has turned this into a library we can use
I was investigating a fun webcam-to-ASCII project so now I am tempted to take an approach at porting the logic from the blog post into something reusable.
ASCII characters are not pixels: a deep dive into ASCII rendering
61–70 of 158 posts
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#62Hmm. This renderer is impressive. Will it be available for toy projects? (such as an online page with JavaScript for converting family pictures)
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#63I love that they don't just work on the edges and declare their work complete. No, shadows also have to be perfect!
Reminds me of this underrated library which uses braille alphabet to draw lines. Behold:
https://github.com/tammoippen/plotille
It's a really nice plotting tool for the terminal. For me it increases the utility of LLMs.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#64[dead]
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#65> I don’t believe I’ve ever seen shape utilized in generated ASCII art, and I think that’s because it’s not really obvious how to consider shape when building an ASCII renderer. Acerola worked a bit on this in 2024[1], using edge detection to layer correctly oriented |/-\ over the usual brightness-only pass. I think either technique has cases where one looks better than the other. [1] https://www.youtube.com/watch?v=…
I can imagine there's room for "style", here, too. Just like how traditional 2d computer art varies from having thick borders and sharp delineations between colour regions, through https://en.wikipedia.org/wiki/Chiaroscuro style that seems to achieve soft edges despite high contrast, etc.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#66I dunno, going to the last example at the bottom of the page and comparing the contrast slider all the way up and all the way down, all these enhancements combined turns it into a blurry mush where it's harder to distinguish the shapes. It's the exact same problem I had with anti-aliasing fonts on older monitors (smaller resolutions) and why I always disabled it wherever I could.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#67Application error: a client-side exception has occurred (see the browser console for more information).
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#68Great writeup! I put together a Python CLI implementation: https://github.com/mayz/ascii-renderer
Supports color output, contrast enhancement, custom charsets. MIT licensed.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#69I didn’t put nearly as much effort as this post into shape matching but I did try a few other things like
Non-ascii, I tried various subsets of Unicode. There’s the geometric shape area, CJK, dingbats, lots of others
Different fonts - there are lots of different monospace fonts. I even tried non-monospaced fonts tho still drawn in grid
ANSI color style https://16colo.rs/
My results weren’t nearly as good as the ones in this article but just suggesting more ways of exploration
https://greggman.github.io/doodles/textme10.html
Note: options are buried in the menu. Best to pick a scene other than the default
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#70Very cool effect! > It may seem odd or arbitrary to use circles instead of just splitting the cell into two rectangles, but using circles will give us more flexibility later on. I still don’t really understand why the inner part of the rectangle can’t just be split in a 2x3 grid. Did I miss the explanation?
I think this is connected to the overlap and offset that are used layer to account for complex or symmetrical letter shapes. If the author had just split the grid, those effects would have been harder to achieve.