ASCII characters are not pixels: a deep dive into ASCII rendering • Hacker News Board

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

#21

Post by c7b » Sat, Jan 17, 2026, 1:32 PM UTC

chrisra wrote: post #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.

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.

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

#22

Post by CarVac » Sat, Jan 17, 2026, 1:43 PM UTC

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

It probably has a different looking result, though.

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

#23

Post by symisc_devel » Sat, Jan 17, 2026, 1:49 PM UTC

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

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

#24

Post by shiandow » Sat, Jan 17, 2026, 1:58 PM UTC

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

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

#25

Post by alexharri » Sat, Jan 17, 2026, 2:03 PM UTC

adam_patarino wrote: post #6

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.

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

#26

Post by finghin » Sat, Jan 17, 2026, 2:06 PM UTC

chrisra wrote: post #16

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.

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

#27

Post by alexharri » Sat, Jan 17, 2026, 2:13 PM UTC

Jyaif wrote: post #3

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

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.

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

#28

Post by jrmg » Sat, Jan 17, 2026, 2:13 PM UTC

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.

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

#29

Post by finghin » Sat, Jan 17, 2026, 2:15 PM UTC

c7b wrote: post #21

chrisra wrote: post #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.

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…

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.

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

#30

Post by Sesse__ » Sat, Jan 17, 2026, 2:18 PM UTC

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.