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/

Every example I thought "yeah, this is cool, but I can see there's space for improvement" — and lo! did the author satisfy my curiosity and improve his technique further.

Bravo, beautiful article! The rest of this blog is at this same level of depth, worth a sub: https://alexharri.com/blog

Very 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 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.

Not to take away from this truly amazing write-up (wow), but there's at least one generator that uses shape:

https://meatfighter.com/ascii-silhouettify/

See particularly the image right above where it says "Note how the algorithm selects the largest characters that fit within the outlines of each colored region."

There's also a description at the bottom of how its algorithm works, if anyone wants to compare.

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 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/

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;
  })

There is already a C library that does realtime ascii rendering using décision trees:

GitHub: https://github.com/symisc/ascii_art/blob/master/README.md Docs: https://pixlab.io/art

It reminds me quite a bit of collision engines for 2D physics/games. Could probably find some additional clever optimisations for the lookup/overlap (better than kd-trees) if you dive into those. Not that it matters too much. Very cool.

The contrast enhancement seems simpler to perform with an unsharp mask in the continuous image.

It probably has a different looking result, though.

This is amazing all round - in concept, writing, and coding (both the idea and the blog post about it).

I feel confident stating that - unless fed something comprehensive like this post as input, and perhaps not even then - an LLM could not do something novel and complex like this, and will not be able to for some time, if ever. I’d love to read about someone proving me wrong on that.

I did something very similar to this (searching for similar characters across the grid, including some fuzzy matching for nearby pixels) around 1996. I wonder if I still have the code? It was exceedingly slow, think minutes for a frame at the Pentiums of the time.

What a great post. There is an element of ascii rendering in a pet project of mine and I’m definitely going to try and integrate this work. From great constraints comes great creativity.

> 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.

I'm not sure if this exponent is actually enhancing contrast or just fixing the gamma.

that was so brilliant! i loved it! thanks for putting it out :)

Thanks! This article put a genuine smile on my face, I can still discover some interesting stuff on the Internet beyond AI slop.

It'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 able to define custom character bitmap, but not enough custom characters to cover the entire screen, so the problem became more complex. Which new character do you create to reproduce an image optimally?

And separately we could choose the foreground/background color of individual characters, which opened up more possibilities.

Tell me someone has turned this into a library we can use

Well-written post. Very interesting, especially the interactive widgets.

Nice! 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!

Next up: proportional fonts and font weights?