Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ASCII characters are not pixels: a deep dive into ASCII rendering

alexharri.com

Post reply on HN
Print view View original

41–50 of 158 posts

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#41

Post by dboon »

Fantastic article! I wrote an ASCII renderer to show a 3D Claude for my Claude Wrapped[^1], and instead of supersampling I just decided to raymarch the whole thing. SDFs give you a smoother result than even super sampling, but of course your scene has to be represented with distance functions and combinations thereof whereas your method is generally applicable.

Taking into account the shape of different ASCII characters is brilliant, though!

[1]: https://spader.zone/wrapped/

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#43

Post by smusamashah »

wonger_ wrote: post #18

Great 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…

But the chafa gallery isn't showing off ascii text rendering. Are there examples that use ascii text?

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#44

Post by fwipsy »

wonger_ wrote: post #18

Great 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…

Aha! The 8x8 bitmap approach is the one I used back in college. I was using a fixed font, so I just converted each character to a 64-bit integer and then used popcnt to compare with an 8x8 tile from the image. I wonder whether this approach results in meaningfully different image results from the original post? e.g. focusing on directionality rather than bitmap match might result in more legible large shapes, but fine noise may not be reproduced as faithfully.

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#47

Post by mwillis »

Fantastic technique and deep dive. I will say, I was hoping to see an improved implementation of the Cognition cube array as the payoff at the end. The whole thing reminded me of the blogger/designer who, years ago, showed YouTube how to render a better favicon by using subpixel color contrast, and then IIRC they implemented the improvement. Some detail here: https://web.archive.org/web/20110930003551/http://typophile....

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#49

Post by alexharri »

AgentMatt wrote: post #32

Great article! I think there's a small problem with intermediate values in this code snippet: const maxValue = Math.max(...samplingVector) samplingVector = samplingVector.map((value) => { value = x / maxValue; // Normalize value = Math.pow(x, exponent); value = x * maxValue; // Denormalize return value; }) Replace x by value.

Good catch, thanks! I’ll push a fix once I’m home

Re: ASCII characters are not pixels: a deep dive into ASCII rendering

#50

Post by snackbroken »

> 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=gg40RWiaHRY

Post reply on HN