Amazing post, I didn’t think this through a lot, but since you are normalizing the vectors and calculating the euclidean distance, you will get the same results using a simple matmul, because euclidean distance over normalized vectors is a linear transform of the cosine distance.
Since you are just interested in the ranking, not the actual distance, you could also consider skipping the sqrt. This gives the same ranking, but will be a little faster.
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
>ASCII characters are not pixels: a deep dive into ASCII rendering
in general, ascii rendering is when ascii character codes are converted to pixels. if you wish to render other pixels onto a screen using characters, they are not ascii characters, they are roman or latin character glyphs, no ascii involved. that is all.
I do enjoy these kinds of write ups, especially when it's about something that might seem so simple on the surface, but in order to get looking great you really have to go in deep.
Lucas Pope did a really nice write up on how he developed his dithering system for Return of The Obra Dinn. Recommended if you also enjoyed this blog post.
> 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:
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.
In the "Image to Terminal character" space this is also a known solution. Map characters to their shape and then pick the one with the lowest diff to the real chunk in the image. If you consider that you have a foreground and a background colour you can get a pretty close image in the terminal :D
> 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.
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.
Great work! While I was building ascii-side-of-the-moon [0][1] I briefly considered writing my own ascii renderer to capture differences in shade and shape of the Lunar Maria[2] better. Ended up just using chafa [3] with the hope of coming back to ascii rendering after everything is working end to end.
Are you planning to release this as a library or a tool, or should we just take the relevant MIT licensed code from your website [4]?
No plans to build a library right now, but who knows. Feel free to grab what you need from the website's code!
If I were to build a library, I'd probably convert the shaders from WebGL 2 to WebGL 1 for better browser compatibility. Would also need to figure out a good API for the library.
One thing that a library would need to deal with is that the shape vector depends on the font family, so the user of the library would need to precompute the shape vectors with the input font family. The sampling circles, internal and external, would likely need to be positioned differently for different font families. It's not obvious to me how a user of the library would go about that. There'd probably need to be some tool for that (I have a script to generate the shape vectors with a hardcoded link to a font in the website repository).
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.
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.
But results are not as good as the OP's work. https://wonger.dev/assets/chafa-ascii-examples.png So I'll revise my claim that chafa is great for unicodey colorful environments, but hand-tailored ascii-only work like the OP is worth the effort.
> 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?
But it seems like you only need the stagger and overlap because you’re using circles in the first place. Would it look worse if you just divided the rectangle into 6 squares without any gaps or overlap?
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.
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....
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!
The resulting ASCII looks dithered, with sequences like e.g. :-:-:-:-:. I'd guess that it's an intentional effect since a flat surface would naturally repeat the same character, right? Where does the dithering come from?
Only tangentially related, but the title reminds me of hack you could do on old DOS machines to get access to a 160x100 16-color display mode on a CGA graphics adapter.
The display mode is actually a hacked up 80x25 text mode. So in that specific narrow case, you have a display mode where text characters very much function as pixels.
I'm hoping people who harness ASCII for stuff like this consider using Code Page 437, or similar. Extended ASCII sets comprising Foreign Chars are for staid business machines, and sort of familiar but out of place accented chars have a bit of a distracting quality.
437 and so on taps the nostalgia for BBS Art, DOS, TUIs scene NFOs, 8 bit micros.... Everything pre Code Page 1252, in other words. Whilst it was a pragmatic decision for MS, it's also true that marketing needs demanded all text interfaces disappeared because they looked old. Text graphics, doubly so. That design space was now reserved for functional icons. A bit of creativity went from (home) computing right there and then. Stuffing it all into a separate font ensured it died.
But, that stuff is genuinely cool to a lot of people in a way VIM, (for example) has never been and nor will it ever. This is a case of Form Over Function. Foreign chars are not as friendly or fun as hearts, building blocks, smileys, musical notes, etc.
I'm playing with a related problem in my spare time - braille character-based color graphics; while we have enough precision for sharp edges, the fundamental issues with color are the still the same: if we begin with a supersampling pass for assignment, we lack precision, so we may need to do some contrast fixups afterward. I think some contrast enhancement based on your sampling schemes might be useful :) Thank you so much for posting this!
(I've previously tried pre-transforming on the image side to do color contrast enhancement, but without success: I take the Sobel filter of an image, and use it to identify regions where I boost contrast. However, since this is a step preceding "rasterization", the results don't align well with character grids.)
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.
To develop this approach you need to think through the reasoning of what you want to achieve. I don't think the reasoning in LLMs is nonexistent, but it is certainly somewhat limited. This is disguised by their vast knowledge. When they successfully achieve a result by relying on knowledge you get an impression of more reasoning than their is.
Everyone seems now familiar with hallucinations. When a model's knowledge is lacking and it is fine tuned to give an answer. A simplistic calculation says that if an accurate answer gets you 100%, then an answer gets you 50% and being accurate gets you 50%. Hallucinations are trying to get partial credit for bullshit. Teaching a model that a wrong answer is worse than no answer is the obvious solution, turning that lesson into training methods is harder.
That's a bit of a digression but I think it helps explain the difference to why I think a model would find writing an article like this.
Models have difficulty in understanding what is important. The degree to which they do achieve this is amazing, but it is still trained on data that heavily biases their conclusions to the mainstream thinking. In that respect I'm not even sure if it is a fundamental lack in what they could do. It seems to be that they are implicitly made to think of problems as "it's one of those, I'll do what people do when faced with one of those"
There are even hints in fiction that this is what we were going to do. There is a fairly common sci-fi trope of an AI giving a thorough and reasoned analysis of a problem only to be cut off by a human wanting the simple and obvious answer. If not done carefully RLHF becomes the embodiment of this trope in action.
This gives a result that makes the most people immediately happy, without regard for what is best long term, or indeed what is actually needed. Asimov explored the notion of robots lying so as to not hurt feelings. Much of the point of the robot books was to express the notion that what we want AI to be is more complicated than it appears at first glance.
This. With good prompting you can get Opus 4.5 to do amazing things, but you have to know what you're doing -- it has to be the case that you could have implemented everything that Claude will do for you, and that what Claude is doing more than anything is a) go faster, b) be your well-read rubber ducky.
I'm confident that they can. This isn't a new idea. Something like this would be a walk in the park for Opus 4.5 in the right harness.
Of course it likely still needs a skilled pair of eyes and a steady hand to keep it on track or keep things performant, but it's an iterative process. I've already built my own ASCII rendering engines in the past, and have recently built one with a coding model, and there was no friction.
Ok, but if you have a wooden hammer and chisel, and a steel hammer and chisel, choosing the wooden one is an artisanal choice, not a practical one. These tools enable an amount of velocity I've never had before, both in research and development.
really great! adjacent well-done ASCII using Braille blocks on X this week:
nolen: "unicode braille characters are 2x4 rectangles of dots that can be individually set. That's 8x the pixels you normally get in the terminal! anyway here's a proof of concept terminal SVG renderer using unicode braille", https://x.com/itseieio/status/2011101813647556902
ashfn: "@itseieio You can use 'persistence of vision' to individually address each of the 8 dots with their own color if you want, there's some messy code of an example here", https://x.com/ashfncom/status/2011135962970218736
What about the explanation presented in the next paragraph?
> Consider how an exponent affects values between 0 and 1. Numbers close to experience a strong pull towards while larger numbers experience less pull. For example 0.1^2=0.01, a 90% reduction, while 0.9^2=0.81, only a reduction of 10%.
That's exactly the reason why it works, it's even nicely visualized below. If you've dealt with similar problems before you might know this in the back of your head. Eg you may have had a problem where you wanted to measure distance from 0 but wanted to remove the sign. You may have tried absolute value and squaring, and noticed that the latter has the additional effect described above.
It's a bit like a math undergrad wondering about a proof 'I understand the argument, but how on earth do you come up with this?'. The answer is to keep doing similar problems and at some point you've developed an arsenal of tricks.
In general for analytic functions like e^x or x^n the behaviour of the function on any open interval is enough to determine its behaviour elsewhere. By extension in mathematics examining values around the fundamental additive and multiplicative units \{ 0, 1 \} is fruitful in illustrating of the quintessential behaviour of the function.
I 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.
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.
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.
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.
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.
Yeah, this is good to point out. The primary constraint I was working around was "this needs to run at a smooth 60FPS on mobile devices" which limits the type and amount of work one can do on each frame.
I'd probably arrive at a very different solution if coming at this from a "you've got infinite compute resources, maximize quality" angle.
You said “best results”, but I imagine that the theoretical “best” may not necessarily be the most aesthetically pleasing in practice.
For example, limiting output to a small set of characters gives it a more uniform look which may be nicer. Then also there’s the “retro” effect of using certain characters over others.
> limiting output to a small set of characters gives it a more uniform look which may be nicer
And in the extreme that could totally change things. Maybe you want to reject ASCII and instead use the Unicode block that has every 2x3 and 2x4 braille pattern.
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.
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.
And a (the?) solution is using an algorithm like k-means clustering to find the tileset of size k that can represent a given image the most faithfully. Of course that’s only for a single frame at a time.
Author here. There isn't a library around this yet, but the source code for the blog is open source (MIT licensed): https://github.com/alexharri/website
The code for this post is all in PR #15 if you want to take a look.
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.
Update: I tested a port of the OP's methodology using Claude Code/Claude Opus 4.5 with some specific performance optimizations, and per the benchmarks, converting a 1024x1024 image to ASCII takes 16 microseconds. I suspect that will decrease after some more polish/iteration but that's enough for potentially real-time generation even on mobile hardware.
Benchmark says 15.654 µs. Rendering the text as a 1024x1024 image is 2.8737 ms.
However, the ASCII output quality is nondiverse despite using the same technique, so will need to do significantly more testing and this likely won't be released soon.
This at the same time super cool and really disappointing, as I've been carrying around this idea in my head for maybe ten years as a cool side project and never got around to implementing it.
However, there might still be room for competition, heh. I always wanted to do this on the _entirety_ of Unicode to try getting the most possible resolution out of the image.
very cool. I may have to look a bit closer at the pipeline I used to create the art at ssh funky.nondeterministic.computer. The graphics could always be improved, however I will note that it needs color for best effect.
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!
At least six dimensions, right? For each character, color of background, color of foreground, and each color has at least three components. And choosing how the components are represented isn’t trivial either - RGB probably isn’t a good choice. YCoCg?
I am however am struck with the from an outsider POV highly niche specific terminology used in the title.
"ASCII rendering".
Yes, I know what ASCII is. I understand text rendering in sometimes painful detail. This was something else.
Yes, it's a niche and niches have their own terminologies that may or may not make sense in a broader context.
HN guidelines says "Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."
I'm not sure what is the best course of action here - perhaps nothing. I keep bumping into this issue all the time at HN, though. Basically the titles very often don't include the context/niche.
I had been thinking of messing around with a DOM-based ‘console’ in Tauri that could handle a lot more font manipulation for a pseudo-TUI application similar to this. It's definitely possible! It would be even simpler to do in TS.
Wait...wh...why?!?
Of all the things, actual pictures of the planet Saturn are readily available in the public domain. Why poison the internet with fake images of it?
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."
> > The image of Saturn was generated with ChatGPT.
> Wait...wh...why?!?
It has just begun. Wait until nobody bothers using Wikipedia, websites, or even one day forums.
This is going to eat everything.
And when it's immediate to say something like, "I need a high contrast image of Saturn of dimensions X by Y, focus on Saturn, oblique angle" -- that's going to be magic.
We'll look at the internet and Google like we look at going to the library and grabbing an encyclopedia off the shelves.
The use of calculators didn't kill ingenuity, nor did the switch to the internet. Despite teachers protesting both.
Humans will always use the lowest friction thing, and we will never stop reaching for the stars.
I’ve been having The Talk with my kids recently. They’ll say “I looked up this question and the answer was X.” And I’ll ask “was that answer on a credible website, or was it an AI summary?” And then explain, again, that LLMs are great at producing plausible sounding explanations for things, but that you have to ground-truth anything that they tell you if it’s important that it’s correct.
Some countries are banning social media for teenagers, but they really should be banning "AI" all teenagers. Most adults can't even be trusted with asking an "AI" about anything, so children are going to have a very warped world view the more they interact with "AI". The tech really is not ready for prime time.
I, for one, have been hoping that AI slop would cause people to be a LOT more cynical about the information they get (from the internet in particular, but from any source in general)
Amazing post, I didn’t think this through a lot, but since you are normalizing the vectors and calculating the euclidean distance, you will get the same results using a simple matmul, because euclidean distance over normalized vectors is a linear transform of the cosine distance.
Since you are just interested in the ranking, not the actual distance, you could also consider skipping the sqrt. This gives the same ranking, but will be a little faster.
It's stuff like this I would have loved to know when I was doing game engine dev in the 90s.
I want to do game programming again like it's 1999. No more `npm i` or "accept all cookies" :/ rant off :)
Go make a game for the Sega Genesis https://mdengine.dev/
Or, the GameBoy Advance https://github.com/GValiente/butano
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
>ASCII characters are not pixels: a deep dive into ASCII rendering
in general, ascii rendering is when ascii character codes are converted to pixels. if you wish to render other pixels onto a screen using characters, they are not ascii characters, they are roman or latin character glyphs, no ascii involved. that is all.
I do enjoy these kinds of write ups, especially when it's about something that might seem so simple on the surface, but in order to get looking great you really have to go in deep.
Lucas Pope did a really nice write up on how he developed his dithering system for Return of The Obra Dinn. Recommended if you also enjoyed this blog post.
https://forums.tigsource.com/index.php?topic=40832.msg136374...
> 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.
In the "Image to Terminal character" space this is also a known solution. Map characters to their shape and then pick the one with the lowest diff to the real chunk in the image. If you consider that you have a foreground and a background colour you can get a pretty close image in the terminal :D
https://hpjansson.org/chafa/
My go version: https://github.com/BigJk/imeji
Love the monochrome gallery of examples https://meatfighter.com/ascii-silhouettify/monochrome-galler...
Appears to be around 150 times slower. I suspect increasing the sample circle cell resolution would give similarly crisp edges.
> 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
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.
Great work! While I was building ascii-side-of-the-moon [0][1] I briefly considered writing my own ascii renderer to capture differences in shade and shape of the Lunar Maria[2] better. Ended up just using chafa [3] with the hope of coming back to ascii rendering after everything is working end to end.
Are you planning to release this as a library or a tool, or should we just take the relevant MIT licensed code from your website [4]?
[0] https://aleyan.com/projects/ascii-side-of-the-moon
[1] https://news.ycombinator.com/item?id=46421045
[2] https://en.wikipedia.org/wiki/Lunar_mare
[3] https://github.com/hpjansson/chafa
[4] https://github.com/alexharri/website/tree/master/src
The ASCII moon tool is fun to play around with!
No plans to build a library right now, but who knows. Feel free to grab what you need from the website's code!
If I were to build a library, I'd probably convert the shaders from WebGL 2 to WebGL 1 for better browser compatibility. Would also need to figure out a good API for the library.
One thing that a library would need to deal with is that the shape vector depends on the font family, so the user of the library would need to precompute the shape vectors with the input font family. The sampling circles, internal and external, would likely need to be positioned differently for different font families. It's not obvious to me how a user of the library would go about that. There'd probably need to be some tool for that (I have a script to generate the shape vectors with a hardcoded link to a font in the website repository).
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/
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.
But the chafa gallery isn't showing off ascii text rendering. Are there examples that use ascii text?
Good point. I haven't found many ascii examples online.
Here's a copy-paste snippet where you can try chafa-ascii-fying images in your own terminal, if you have uvx:
But results are not as good as the OP's work. https://wonger.dev/assets/chafa-ascii-examples.png So I'll revise my claim that chafa is great for unicodey colorful environments, but hand-tailored ascii-only work like the OP is worth the effort.my favorite ascii glyphs are the classic IBM Code Page 437: https://int10h.org/oldschool-pc-fonts/fontlist/
and damn that article is so cool, what a rabbithole.
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?
It's because circles allow for a stagger and overlap as shown later on. It's not really possible to get the same effect from squares.
But it seems like you only need the stagger and overlap because you’re using circles in the first place. Would it look worse if you just divided the rectangle into 6 squares without any gaps or overlap?
My thought exactly. The sampling circles only enable you to (awkwardly) solve a problem that was fabricated by using circles in the first place.
I wondered the same thing, but characters usually don't reach the edges, so I guess circles fit the average character better?
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.
I 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
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....
+1 yo wanting to see the cognition logo with contrast. It was set up as the target, but no payoff!
Lovely article, and the dynamic examples are :chefs-kiss:
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/
Looks very cool! Thanks for sharing.
The resulting ASCII looks dithered, with sequences like e.g. :-:-:-:-:. I'd guess that it's an intentional effect since a flat surface would naturally repeat the same character, right? Where does the dithering come from?
Great article!
I think there's a small problem with intermediate values in this code snippet:
Replace x by value.Just pushed a fix, should be live in a minute or two, thanks again!
Good catch, thanks! I’ll push a fix once I’m home
The contrast enhancement seems simpler to perform with an unsharp mask in the continuous image.
It probably has a different looking result, though.
Only tangentially related, but the title reminds me of hack you could do on old DOS machines to get access to a 160x100 16-color display mode on a CGA graphics adapter.
The display mode is actually a hacked up 80x25 text mode. So in that specific narrow case, you have a display mode where text characters very much function as pixels.
- https://en.wikipedia.org/wiki/Color_Graphics_Adapter
- https://github.com/drwonky/cgax16demo
Quite amazing breakdown, thank you!
I'm hoping people who harness ASCII for stuff like this consider using Code Page 437, or similar. Extended ASCII sets comprising Foreign Chars are for staid business machines, and sort of familiar but out of place accented chars have a bit of a distracting quality.
437 and so on taps the nostalgia for BBS Art, DOS, TUIs scene NFOs, 8 bit micros.... Everything pre Code Page 1252, in other words. Whilst it was a pragmatic decision for MS, it's also true that marketing needs demanded all text interfaces disappeared because they looked old. Text graphics, doubly so. That design space was now reserved for functional icons. A bit of creativity went from (home) computing right there and then. Stuffing it all into a separate font ensured it died.
But, that stuff is genuinely cool to a lot of people in a way VIM, (for example) has never been and nor will it ever. This is a case of Form Over Function. Foreign chars are not as friendly or fun as hearts, building blocks, smileys, musical notes, etc.
I'm playing with a related problem in my spare time - braille character-based color graphics; while we have enough precision for sharp edges, the fundamental issues with color are the still the same: if we begin with a supersampling pass for assignment, we lack precision, so we may need to do some contrast fixups afterward. I think some contrast enhancement based on your sampling schemes might be useful :) Thank you so much for posting this!
(I've previously tried pre-transforming on the image side to do color contrast enhancement, but without success: I take the Sobel filter of an image, and use it to identify regions where I boost contrast. However, since this is a step preceding "rasterization", the results don't align well with character grids.)
Great article!
https://alumni.media.mit.edu/~nelson/courses/mas814/
Great writeup! I put together a Python CLI implementation: https://github.com/mayz/ascii-renderer
Supports color output, contrast enhancement, custom charsets. MIT licensed.
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
The OP's ASCII art edges look way better than this
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.
To develop this approach you need to think through the reasoning of what you want to achieve. I don't think the reasoning in LLMs is nonexistent, but it is certainly somewhat limited. This is disguised by their vast knowledge. When they successfully achieve a result by relying on knowledge you get an impression of more reasoning than their is.
Everyone seems now familiar with hallucinations. When a model's knowledge is lacking and it is fine tuned to give an answer. A simplistic calculation says that if an accurate answer gets you 100%, then an answer gets you 50% and being accurate gets you 50%. Hallucinations are trying to get partial credit for bullshit. Teaching a model that a wrong answer is worse than no answer is the obvious solution, turning that lesson into training methods is harder.
That's a bit of a digression but I think it helps explain the difference to why I think a model would find writing an article like this.
Models have difficulty in understanding what is important. The degree to which they do achieve this is amazing, but it is still trained on data that heavily biases their conclusions to the mainstream thinking. In that respect I'm not even sure if it is a fundamental lack in what they could do. It seems to be that they are implicitly made to think of problems as "it's one of those, I'll do what people do when faced with one of those"
There are even hints in fiction that this is what we were going to do. There is a fairly common sci-fi trope of an AI giving a thorough and reasoned analysis of a problem only to be cut off by a human wanting the simple and obvious answer. If not done carefully RLHF becomes the embodiment of this trope in action.
This gives a result that makes the most people immediately happy, without regard for what is best long term, or indeed what is actually needed. Asimov explored the notion of robots lying so as to not hurt feelings. Much of the point of the robot books was to express the notion that what we want AI to be is more complicated than it appears at first glance.
This. With good prompting you can get Opus 4.5 to do amazing things, but you have to know what you're doing -- it has to be the case that you could have implemented everything that Claude will do for you, and that what Claude is doing more than anything is a) go faster, b) be your well-read rubber ducky.
I'm confident that they can. This isn't a new idea. Something like this would be a walk in the park for Opus 4.5 in the right harness.
Of course it likely still needs a skilled pair of eyes and a steady hand to keep it on track or keep things performant, but it's an iterative process. I've already built my own ASCII rendering engines in the past, and have recently built one with a coding model, and there was no friction.
> skilled pair of eyes and a steady hand
But that's key here.
"A hammer and a chisel can build a 6ft wooden sculpture by themselves just fine .. as long as guided by a skilled pair of eyes and steady hands"
Ok, but if you have a wooden hammer and chisel, and a steel hammer and chisel, choosing the wooden one is an artisanal choice, not a practical one. These tools enable an amount of velocity I've never had before, both in research and development.
Amazing post, I was able to take what you did and recreate it and have some fun, matrix green etc. Thanks for the great post
really great! adjacent well-done ASCII using Braille blocks on X this week:
nolen: "unicode braille characters are 2x4 rectangles of dots that can be individually set. That's 8x the pixels you normally get in the terminal! anyway here's a proof of concept terminal SVG renderer using unicode braille", https://x.com/itseieio/status/2011101813647556902
ashfn: "@itseieio You can use 'persistence of vision' to individually address each of the 8 dots with their own color if you want, there's some messy code of an example here", https://x.com/ashfncom/status/2011135962970218736
It would be interesting to see how things changed if you included extended ascii characters [1], which were widely used for ascii UI.
[1] https://www.lookuptables.com/text/extended-ascii-table
I did actually try out various alphabets e.g. Cyrillic, Greek and symbols (e.g. box drawing symbols), but ended up removing them: https://github.com/alexharri/website/commit/d969ef839
Using only ASCII felt more in the "spirit" of the post and reduced scope (which is always good)
Wonderful article and illustrations! I got sucked in by the successive disclosures of "but this is a problem, so we do that to solve it." Bravo!
> 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.
What about the explanation presented in the next paragraph?
> Consider how an exponent affects values between 0 and 1. Numbers close to experience a strong pull towards while larger numbers experience less pull. For example 0.1^2=0.01, a 90% reduction, while 0.9^2=0.81, only a reduction of 10%.
That's exactly the reason why it works, it's even nicely visualized below. If you've dealt with similar problems before you might know this in the back of your head. Eg you may have had a problem where you wanted to measure distance from 0 but wanted to remove the sign. You may have tried absolute value and squaring, and noticed that the latter has the additional effect described above.
It's a bit like a math undergrad wondering about a proof 'I understand the argument, but how on earth do you come up with this?'. The answer is to keep doing similar problems and at some point you've developed an arsenal of tricks.
In general for analytic functions like e^x or x^n the behaviour of the function on any open interval is enough to determine its behaviour elsewhere. By extension in mathematics examining values around the fundamental additive and multiplicative units \{ 0, 1 \} is fruitful in illustrating of the quintessential behaviour of the function.
I 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.
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.
This is such a great article!
I found myself thinking, “I wonder if some of this could be used to playback video on old 8-bit machines?” But they’re so underpowered…
Might checkout what people have done on the 6502 in an Apple II.
https://youtu.be/wM3deQAgMpE?si=h2O1uTQqxFtCRCsh
Very impressive blogpost. No wonder it took 6 months. Makes me think I need to step up the game with my photo ASCII art compositor, printscii.com
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.
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.
I'm not sure if this exponent is actually enhancing contrast or just fixing the gamma.
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.
Yeah, this is good to point out. The primary constraint I was working around was "this needs to run at a smooth 60FPS on mobile devices" which limits the type and amount of work one can do on each frame.
I'd probably arrive at a very different solution if coming at this from a "you've got infinite compute resources, maximize quality" angle.
You said “best results”, but I imagine that the theoretical “best” may not necessarily be the most aesthetically pleasing in practice.
For example, limiting output to a small set of characters gives it a more uniform look which may be nicer. Then also there’s the “retro” effect of using certain characters over others.
> limiting output to a small set of characters gives it a more uniform look which may be nicer
And in the extreme that could totally change things. Maybe you want to reject ASCII and instead use the Unicode block that has every 2x3 and 2x4 braille pattern.
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.
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.
And a (the?) solution is using an algorithm like k-means clustering to find the tileset of size k that can represent a given image the most faithfully. Of course that’s only for a single frame at a time.
Mesmerizing, the i, ! shading is unreasonably effective.
Those 3D interactive animations are the smoothest 3D rendering I've ever seen in a mobile browser. I'm impressed
Nice work! ASCII rendering will never be the same, in a good way.
that was so brilliant! i loved it! thanks for putting it out :)
This is something I've wanted to do for 50 years, but never found the time or motivation. Well done!
Wow. Pretty cool. Now just replace the characters with the set from the Matrix and swallow the blue pill.
Tell me someone has turned this into a library we can use
Author here. There isn't a library around this yet, but the source code for the blog is open source (MIT licensed): https://github.com/alexharri/website
The code for this post is all in PR #15 if you want to take a look.
Well there's aalib and libcaca, but I'm not sure about their fidelity compared to this.
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.
Update: I tested a port of the OP's methodology using Claude Code/Claude Opus 4.5 with some specific performance optimizations, and per the benchmarks, converting a 1024x1024 image to ASCII takes 16 microseconds. I suspect that will decrease after some more polish/iteration but that's enough for potentially real-time generation even on mobile hardware.
That doesn’t seem right.
Surely you mean 16 milliseconds ?
Benchmark says 15.654 µs. Rendering the text as a 1024x1024 image is 2.8737 ms.
However, the ASCII output quality is nondiverse despite using the same technique, so will need to do significantly more testing and this likely won't be released soon.
Don't know what algorithm are used by the famous libcaca:
https://github.com/cacalabs/libcaca
This at the same time super cool and really disappointing, as I've been carrying around this idea in my head for maybe ten years as a cool side project and never got around to implementing it.
However, there might still be room for competition, heh. I always wanted to do this on the _entirety_ of Unicode to try getting the most possible resolution out of the image.
Application error: a client-side exception has occurred (see the browser console for more information).
This is fantastic
very cool. I may have to look a bit closer at the pipeline I used to create the art at ssh funky.nondeterministic.computer. The graphics could always be improved, however I will note that it needs color for best effect.
Holy moly, i Love this kinds of work
Thanks! This article put a genuine smile on my face, I can still discover some interesting stuff on the Internet beyond AI slop.
Well-written post. Very interesting, especially the interactive widgets.
I 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.
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!
"finally"? We were playing Quake II in AAlib in 2006. https://www.jfedor.org/aaquake2/
At least six dimensions, right? For each character, color of background, color of foreground, and each color has at least three components. And choosing how the components are represented isn’t trivial either - RGB probably isn’t a good choice. YCoCg?
Seems like stellar work. Kudos.
I am however am struck with the from an outsider POV highly niche specific terminology used in the title.
"ASCII rendering".
Yes, I know what ASCII is. I understand text rendering in sometimes painful detail. This was something else.
Yes, it's a niche and niches have their own terminologies that may or may not make sense in a broader context.
HN guidelines says "Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."
I'm not sure what is the best course of action here - perhaps nothing. I keep bumping into this issue all the time at HN, though. Basically the titles very often don't include the context/niche.
Next up: proportional fonts and font weights?
I had been thinking of messing around with a DOM-based ‘console’ in Tauri that could handle a lot more font manipulation for a pseudo-TUI application similar to this. It's definitely possible! It would be even simpler to do in TS.
> The image of Saturn was generated with ChatGPT.
Wait...wh...why?!? Of all the things, actual pictures of the planet Saturn are readily available in the public domain. Why poison the internet with fake images of it?
"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."
"Eschew flamebait. Avoid generic tangents."
https://news.ycombinator.com/newsguidelines.html
https://www.theverge.com/2023/3/13/23637401/samsung-fake-moo...
Are we sure the planets are real?
How can planets be real if our eyes aren’t real?
More like, why have it regurgitate something likely to have been in its training data?
> > The image of Saturn was generated with ChatGPT.
> Wait...wh...why?!?
It has just begun. Wait until nobody bothers using Wikipedia, websites, or even one day forums.
This is going to eat everything.
And when it's immediate to say something like, "I need a high contrast image of Saturn of dimensions X by Y, focus on Saturn, oblique angle" -- that's going to be magic.
We'll look at the internet and Google like we look at going to the library and grabbing an encyclopedia off the shelves.
The use of calculators didn't kill ingenuity, nor did the switch to the internet. Despite teachers protesting both.
Humans will always use the lowest friction thing, and we will never stop reaching for the stars.
I’ve been having The Talk with my kids recently. They’ll say “I looked up this question and the answer was X.” And I’ll ask “was that answer on a credible website, or was it an AI summary?” And then explain, again, that LLMs are great at producing plausible sounding explanations for things, but that you have to ground-truth anything that they tell you if it’s important that it’s correct.
Some countries are banning social media for teenagers, but they really should be banning "AI" all teenagers. Most adults can't even be trusted with asking an "AI" about anything, so children are going to have a very warped world view the more they interact with "AI". The tech really is not ready for prime time.
I, for one, have been hoping that AI slop would cause people to be a LOT more cynical about the information they get (from the internet in particular, but from any source in general)
But it's not happened yet
What statistical measures of "people" are you doing to measure this? How can you be sure nothing has changed?
Anecdotally, I'm seeing a lot of "it looks like AI" comments on photos and videos now. That's the new "is it Photoshop?"
I'd hold off on judgment until we get population studies on this.
What statistical measures i use to measure is of what importance to you?
I haven't presented a measurement, just an expectation.
You said it hasn't happened yet and he's asking how you arrived at that conclusion.
Hmm. This renderer is impressive. Will it be available for toy projects? (such as an online page with JavaScript for converting family pictures)