davideisinger.com

alexharri-com-d1kmv9.txt (44568B)

---

 [1]Alex Harri
 [2]About[3]Blog
 
 ASCII characters are not pixels: a deep dive into ASCII rendering
 
 January 17, 2026
 
 Recently, I’ve been spending my time building an image-to-ASCII renderer. Below
 is the result — try dragging it around, the demo is interactive!
 
 One thing I spent a lot of effort on is getting edges looking sharp. Take a
 look at this rotating cube example:
 
 Try opening the “split” view. Notice how well the characters follow the contour
 of the square.
 
 This renderer works well for animated scenes, like the ones above, but we can
 also use it to render static images:
 
 The image of Saturn was [4]generated with ChatGPT.
 
 Then, to get better separation between different colored regions, I also
 implemented a [5]cel shading-like effect to enhance contrast between edges. Try
 dragging the contrast slider below:
 
 The contrast enhancement makes the separation between different colored regions
 far clearer. That was key to making the 3D scene above look as good as it does.
 
 I put so much focus on sharp edges because they’re an aspect of ASCII rendering
 that is often overlooked when programmatically rendering images as ASCII.
 Consider this animated 3D scene from Cognition’s landing page that is rendered
 via ASCII characters:
 
 Source: [6]cognition.ai
 
 It’s a cool effect, especially while in motion, but take a look at those blurry
 edges! The characters follow the cube contours very poorly, and as a result,
 the edges look blurry and jagged in places:
 
 [cube-logo-zoomed-in]
 
 This blurriness happens because the ASCII characters are being treated like
 pixels — their shape is ignored. It’s disappointing to see because ASCII art
 looks so much better when shape is utilized. 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.
 
 I started building my ASCII renderer to prove to myself that it’s possible to
 utilize shape in ASCII rendering. In this post, I’ll cover the techniques and
 ideas I used to capture shape and build this ASCII renderer in detail.
 
 We’ll start with the basics of image-to-ASCII conversion and see where the
 common issue of blurry edges comes from. After that, I’ll show you the approach
 I used to fix that and achieve sharp, high-quality ASCII rendering. At the end,
 we’ll improve on that by implementing the contrast enhancement effect I showed
 above.
 
 Let’s get to it!
 
 Image to ASCII conversion
 
 ASCII contains [7]95 printable characters that we can use. Let’s start off by
 rendering the following image containing a white circle using those ASCII
 characters:
 
 ASCII art is (almost) always rendered using a [8]monospace font. Since every
 character in a monospace font is equally wide and tall, we can split the image
 into a grid. Each grid cell will contain a single ASCII character.
 
 The image with the circle is pixels. For the ASCII grid, I’ll pick a row height
 of pixels and a column width of pixels. That splits the canvas into rows and
 columns — an grid:
 
 Monospace characters are typically taller than they are wide, so I made each
 grid cell a bit taller than it is wide.
 
 Our task is now to pick which character to place in each cell. The simplest
 approach is to calculate a lightness value for each cell and pick a character
 based on that.
 
 We can get a lightness value for each cell by sampling the lightness of the
 pixel at the cell’s center:
 
 We want each pixel’s lightness as a numeric value between and , but our image
 data consists of pixels with [9]RGB color values.
 
 We can use the following formula to convert an RGB color (with component values
 between and ) to a lightness value:
 
 See [10]relative luminance.
 
 Mapping lightness values to ASCII characters
 
 Now that we have a lightness value for each cell, we want to use those values
 to pick ASCII characters. As mentioned before, ASCII has 95 printable
 characters, but let’s start simple with just these characters:
 
 : - # = + @ * % .
 
 We can sort them in approximate density order like so, with lower-density
 characters to the left, and high-density characters to the right:
 
 . : - = + * # % @
 
 We’ll put these characters in a CHARS array:
 
 const CHARS = [" ", ".", ":", "-", "=", "+", "*", "#", "%", "@"]
 
 I added space as the first (least dense) character.
 
 We can then map lightness values between and to one of those characters like
 so:
 
 function getCharacterFromLightness(lightness: number) {
   const index = Math.floor(lightness * (CHARS.length - 1));
   return CHARS[index];
 }
 
 This maps low lightness values to low-density characters and high lightness
 values to high-density characters.
 
 Rendering the circle from above with this method gives us:
 
 That works... but the result is pretty ugly. We seem to always get @ for cells
 that fall within the circle and a space for cells that fall outside.
 
 That is happening because we’ve pretty much just implemented nearest-neighbor
 downsampling. Let’s see what that means.
 
 Nearest neighbor downsampling
 
 Downsampling, in the context of image processing, is taking a larger image (in
 our case, the image with the circle) and using that image’s data to construct a
 lower resolution image (in our case, the ASCII grid). The pixel values of the
 lower resolution image are calculated by sampling values from the higher
 resolution image.
 
 The simplest and fastest method of sampling is [15]nearest-neighbor
 interpolation, where, for each cell (pixel), we only take a single sample from
 the higher resolution image.
 
 Consider the circle example again. Using nearest-neighbor interpolation, every
 sample either falls inside or outside of the shape, resulting in either or
 lightness:
 
 If, instead of picking an ASCII character for each grid cell, we color each
 grid cell (pixel) according to the sampled value, we get the following
 pixelated rendering:
 
 This pixelated rendering is pretty much equivalent to the ASCII rendering from
 before. The only difference is that instead of @s we have white pixels, and
 instead of spaces we have black pixels.
 
 These square, jagged looking edges are aliasing artifacts, commonly called [16]
 jaggies. They’re a common result of using nearest-neighbor interpolation.
 
 Supersampling
 
 To get rid of jaggies, we can collect more samples for each cell. Consider this
 line:
 
 The line’s slope on the axis is . When we pixelate it with nearest-neighbor
 interpolation, we get the following:
 
 Let’s try to get rid of the jagginess by taking multiple samples within each
 cell and using the average sampled lightness value as the cell’s lightness. The
 example below lets you vary the number of samples using the slider:
 
 With multiple samples, cells that lie on the edge of a shape will have some of
 their samples fall within the shape, and some outside of it. Averaging those,
 we get gray in-between colors that smooth the downsampled image. Below is the
 same example, but with an overlay showing where the samples are taken:
 
 This method of collecting multiple samples from the larger image is called [17]
 supersampling. It’s a common method of [18]spatial anti-aliasing (avoiding
 jaggies at edges). Here’s what the rotating square looks like with
 supersampling (using samples for each cell):
 
 Let’s look at what supersampling does for the circle example from earlier. Try
 dragging the sample quality slider:
 
 The circle becomes less jagged, but the edges feel blurry. Why’s that?
 
 Well, they feel blurry because we’re pretty much just rendering a
 low-resolution, pixelated image of a circle. Take a look at the pixelated view:
 
 The ASCII and pixelated views are mirror images of each other. Both are just
 low-resolution versions of the original high-resolution image, scaled up to the
 original’s size — it’s no wonder they both look blurry.
 
 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 
 Increasing the number of samples is insufficient. No matter how many samples we
 take per cell, the samples will be averaged into a single lightness value, used
 to render a single pixel.
 
 And that’s the core problem: treating each grid cell as a pixel in an image.
 It’s an obvious and simple method, but it disregards that ASCII characters have
 shape.
 
 We can make our ASCII renderings far more crisp by picking characters based on
 their shape. Here’s the circle rendered that way:
 
 The characters follow the contour of the circle very well. By picking
 characters based on shape, we get a far higher effective resolution. The result
 is also more visually interesting.
 
 Let’s see how we can implement this.
 
 Shape
 
 So what do I mean by shape? Well, consider the characters T, L, and O placed
 within grid cells:
 
 The character T is top-heavy. Its visual density in the upper half of the grid
 cell is higher than in the lower half. The opposite can be said for L — it’s
 bottom-heavy. O is pretty much equally dense in the upper and lower halves of
 the cell.
 
 We might also compare characters like L and J. The character L is heavier
 within the left half of the cell, while J is heavier in the right half:
 
 We also have more “extreme” characters, such as _ and ^, that only occupy the
 lower or upper portion of the cell, respectively:
 
 This is, roughly, what I mean by “shape” in the context of ASCII rendering.
 Shape refers to which regions of a cell a given character visually occupies.
 
 Quantifying shape
 
 To pick characters based on their shape, we’ll somehow need to quantify (put
 numbers to) the shape of each character.
 
 Let’s start by only considering how much characters occupy the upper and lower
 regions of our cell. To do that, we’ll define two “sampling circles” for each
 grid cell — one placed in the upper half and one in the lower half:
 
 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.
 
 A character placed within a cell will overlap each of the cell’s sampling
 circles to some extent.
 
 One can compute that overlap by taking a bunch of samples within the circle
 (for example, at every pixel). The fraction of samples that land inside the
 character gives us the overlap as a numeric value between and :
 
 For T, we get an overlap of approximately for the upper circle and for the
 lower. Those overlap values form a -dimensional vector:
 
 We can generate such a -dimensional vector for each character within the ASCII
 alphabet. These vectors quantify the shape of each ASCII character along these
 dimensions (upper and lower). I’ll call these vectors shape vectors.
 
 Below are some ASCII characters and their shape vectors. I’m coloring the
 sampling circles using the component values of the shape vectors:
 
 We can use the shape vectors as 2D coordinates — here’s every ASCII character
 on a 2D plot:
 
 000.050.050.10.10.150.150.20.20.250.250.30.30.350.350.40.4UpperLower^@qTMuX$g=C
 
 Shape-based lookup
 
 Let’s say that we have our ASCII characters and their associated shape vectors
 in a CHARACTERS array:
 
 const CHARACTERS: Array<{
   character: string,
   shapeVector: number[],
 }> = [...];
 
 We can then perform a nearest neighbor search like so:
 
 function findBestCharacter(inputVector: number[]) {
   let bestCharacter = "";
   let bestDistance = Infinity;
   
   for (const { character, shapeVector } of CHARACTERS) {
     const dist = getDistance(shapeVector, inputVector);
     if (dist < bestDistance) {
       bestDistance = dist;
       bestCharacter = character;
     }
   }
   
   return bestCharacter;
 }
 
 The findBestCharacter function gives us the ASCII character whose shape best
 matches the input lookup vector.
 
 Note: this brute force search is not very performant. This becomes a bottleneck
 when we start rendering thousands of ASCII characters at FPS. I’ll talk more
 about this later.
 
 To make use of this in our ASCII renderer, we’ll calculate a lookup vector for
 each cell in the ASCII grid and pass it to findBestCharacter to determine the
 character to display.
 
 Let’s try it out. Consider the following zoomed-in circle as an example. It is
 split into three grid cells:
 
 Overlaying our sampling circles, we see varying degrees of overlap:
 
 When calculating the shape vector of each ASCII character, we took a huge
 number of samples. We could afford to do that because we only need to calculate
 those shape vectors once up front. After they’re calculated, we can use them
 again and again.
 
 However, if we’re converting an animated image (e.g. canvas or video) to ASCII,
 we need to be mindful of performance when calculating the lookup vectors. An
 ASCII rendering might have hundreds or thousands of cells. Multiplying that by
 tens or hundreds of samples would be incredibly costly in terms of performance.
 
 With that being said, let’s pick a sampling quality of with the samples placed
 like so:
 
 For the top sampling circle of the leftmost cell, we get one white sample and
 two black, giving us an average lightness of . Doing the same calculation for
 all of the sampling circles, we get the following 2D vectors:
 
 From now on, instead of using the term “lookup vectors”, I’ll call these
 vectors, sampled from the image that we’re rendering as ASCII, sampling vectors
 . One sampling vector is calculated for each cell in the grid.
 
 Anyway, we can use these sampling vectors to find the best-matching ASCII
 character. Let’s see what that looks like on our 2D plot — I’ll label the
 sampling vectors (from left to right) C0, C1, and C2:
 
 000.10.10.20.20.30.30.40.40.50.50.60.60.70.70.80.80.90.911UpperLowerC0C1C2P$
 
 Hmm... this is not what we want. Since none of the ASCII shape vector
 components exceed , they’re all clustered towards the bottom-left region of our
 plot. This makes our sampling vectors map to a few characters on the edge of
 the cluster.
 
 We can fix this by normalizing the shape vectors. We’ll do that by taking the
 maximum value of each component across all shape vectors, and dividing the
 components of each shape vector by the maximum. Expressed in code, that looks
 like so:
 
 const max = [0, 0]
 
 for (const vector of characterVectors) {
   for (const [i, value] of Object.entries(vector)) {
     if (value > max[i]) {
       max[i] = value;
     }
   }
 }
 
 const normalizedCharacterVectors = characterVectors.map(
   vector => vector.map((value, i) => value / max[i])
 )
 
 Here’s what the plot looks like with the shape vectors normalized:
 
 000.10.10.20.20.30.30.40.40.50.50.60.60.70.70.80.80.90.911UpperLower^@qTMuX$g=C
 
 If we now map the sampling vectors to their nearest neighbors, we get a much
 more sensible result:
 
 000.10.10.20.20.30.30.40.40.50.50.60.60.70.70.80.80.90.911UpperLowerC0C1C2M$'
 
 We get ', M and $. Let’s see how well those characters match the circle:
 
 Nice! They match very well.
 
 Let’s try rendering the full circle from before with the same method:
 
 Much better than before! The picked characters follow the contour of the circle
 very well.
 
 Limits of a 2D shape vector
 
 Using two sampling circles — one upper and one lower — produces a much better
 result than the -dimensional (pixelated) approach. However, it still falls
 short when trying to capture other aspects of a character’s shape.
 
 For example, two circles don’t capture the shape of characters that fall in the
 middle of the cell. Consider -:
 
 For -, we get a shape vector of . That doesn’t represent the character very
 well at all.
 
 The two upper-lower sampling circles also don’t capture left-right differences,
 such as the difference between p and q:
 
 We could use such differences to get better character picks, but our two
 sampling circles don’t capture them. Let’s add more dimensions to our shape to
 fix that.
 
 Increasing to 6 dimensions
 
 Since cells are taller than they are wide (at least with the monospace font I’m
 using), we can use sampling circles to cover the area of each cell quite well:
 
 sampling circles capture left-right differences, such as between p and q, while
 also capturing differences across the top, bottom, and middle regions of the
 cell, differentiating ^, -, and _. They also capture the shape of “diagonal”
 characters like / to a reasonable degree.
 
 One problem with this grid-like configuration for the sampling circles is that
 there are gaps. For example, . falls between the sampling circles:
 
 To compensate for this, we can stagger the sampling circles vertically (e.g.
 lowering the left sampling circles and raising the right ones) and make them a
 bit larger. This causes the cell to be almost fully covered while not causing
 excessive overlap across the sampling circles:
 
 We can use the same procedure as before to generate character vectors using
 these sampling circles, this time yielding a -dimensional vector. Consider the
 character L:
 
 For L, we get the vector:
 
 I’m presenting -dimensional shape vectors in a matrix form because it’s easier
 to grok geometrically, but the actual vector is a flat list of numbers.
 
 The lightness values certainly look L-shaped! The 6D shape vector captures L’s
 shape very well.
 
 Nearest neighbor lookups in a 6D space
 
 Now we have a 6D shape vector for every ASCII character. Does that affect
 character lookups (how we find the best matching character)?
 
 Earlier, in the findBestCharacter function, I referenced a getDistance
 function. That function returns the [22]Euclidean distance between the input
 points. Given two 2D points and , the formula to calculate their Euclidean
 distance looks like so:
 
 This generalizes to higher dimensions:
 
 Put into code, this looks like so:
 
 function getDistance(a: number[], b: number[]): number {
   let sum = 0;
   for (let i = 0; i < a.length; i++) {
     sum += (a[i] - b[i]) ** 2;
   }
   return Math.sqrt(sum);
 }
 
 Note: since we’re just using this for the purposes of finding the closest
 point, we can skip the expensive Math.sqrt() call and just return the squared
 distance. It does not affect the result.
 
 So, no, the dimensionality of our shape vector does not change lookups at all.
 We can use the same getDistance function for both 2D and 6D.
 
 With that out of the way, let’s see what the 6D approach yields!
 
 Trying out the 6D approach
 
 Our new 6D approach works really well for flat shapes, like the circle example
 we’ve been using:
 
 Now let’s see how this approach works when we render a 3D scene with more
 shades of gray:
 
 Firstly, the outer contours look nice and sharp. I also like how well the
 gradients across the sphere and cone look.
 
 However, internally, the objects all kind of blend together. The edges between
 surfaces with different lightnesses aren’t sharp enough. For example, the
 lighter faces of the cubes all kind of blend into one solid color. When there
 is a change in color — like when two faces of a cube meet — I’d like to see
 more sharpness in the ASCII rendering.
 
 To demonstrate what I mean, consider the following split:
 
 It’s currently rendered like so:
 
 The different shades result in is on the left and Bs on the right, but the
 boundary is not very sharp.
 
 By applying some effects to the sampling vector, we can enhance the contrast at
 the boundary so that it appears sharper:
 
 The added contrast makes a big difference in readability for the 3D scene.
 Let’s look at how we can implement this contrast enhancement effect.
 
 Contrast enhancement
 
 Consider cells overlapping a color boundary like so:
 
 For the cells on the boundary, we get a 6D sampling vector that looks like so:
 
 To make future examples easier to visualize, I’ll start drawing the sampling
 vector using circles like so:
 
 0.65
 0.65
 0.31
 0.31
 0.22
 0.22
 
 Currently, this sampling vector resolves to the character T:
 
 0.65
 0.65
 0.31
 0.31
 0.22
 0.22
 →
 T
 Picked character: T
 
 That’s a sensible choice. The character T is visually dense in the top half and
 less so in the bottom half, so it matches the image fairly well.
 
 Still, I want the picked character to emphasize the shape of the boundary
 better. We can achieve that by enhancing the contrast of the sampling vector.
 
 To increase the contrast of our sampling vector, we might raise each component
 of the vector to the power of some exponent.
 
 Consider how an exponent affects values between and . Numbers close to
 experience a strong pull towards while larger numbers experience less pull. For
 example, , a 90% reduction, while , only a reduction of 10%.
 
 The level of pull depends on the exponent. Here’s a chart of for values of
 between and :
 
 [x-pow-2-chart]
 
 This effect becomes more pronounced with higher exponents:
 
 [x-pow-n-chart]
 
 A higher exponent translates to a stronger pull towards zero.
 
 Applying an exponent should make dark values darker more quickly than light
 ones. The example below allows you to vary the exponent applied to the sampling
 vector:
 
 0.65
 0.65
 0.31
 0.31
 0.22
 0.22
 Exponent
 [24][1                   ]121
 
 As the exponent is increased to , the darker components of the sampling vector
 quickly become much darker, just like we wanted. However, the lighter
 components also get pulled towards zero by a significant amount.
 
 I don’t want that. I want to increase the contrast between the lighter and
 darker components of the sampling vector, not the vector in its entirety.
 
 To achieve that, we can normalize the sampling vector to the range prior to
 applying the exponent, and then “denormalize” the vector back to the original
 range afterwards.
 
 The normalization to can be done by dividing each component by the maximum
 component value. After applying the exponent, mapping back to the original
 range is done by multiplying each component by the same max value:
 
 const maxValue = Math.max(...samplingVector)
 
 samplingVector = samplingVector.map((value) => {
   value = value / maxValue; // Normalize
   value = Math.pow(value, exponent);
   value = value * maxValue; // Denormalize
   return value;
 })
 
 Here’s the same example, but with this normalization applied:
 
 0.65
 0.65
 0.31
 0.31
 0.22
 0.22
 Exponent
 [26][1                   ]121
 
 Very nice! The lightest component values are retained, and the contrast between
 the lighter and darker components is increased by “crunching” the lower values.
 
 This affects which character is picked. The following example shows how the
 selected character changes as the contrast is increased:
 
 0.65
 0.65
 0.31
 0.31
 0.22
 0.22
 →
 T
 Picked character: T
 Exponent
 [27][1                   ]121
 
 Awesome! The pick of " over T emphasizes the separation between the lighter
 region above and the darker region below!
 
 By enhancing the contrast of the sampling vector, we exaggerate its shape. This
 gives us a character that less faithfully represents the underlying image, but
 improves readability as a whole by enhancing the separation between different
 colored regions.
 
 Let’s look at another example. Observe how the L-shape of the sampling vector
 below becomes more pronounced as the exponent increases, and how that affects
 the picked character:
 
 0.68
 0.31
 0.76
 0.31
 0.77
 0.78
 →
 &
 Picked character: &
 Exponent
 [28][1                   ]121
 
 Works really nicely! I love the transition from & -> b -> L as the L-shape of
 the vector becomes clearer.
 
 What’s nice about applying exponents to normalized sampling vectors is that it
 barely affects vectors that are uniform in value. If all component values are
 similar, applying an exponent has a minimal effect:
 
 0.64
 0.52
 0.62
 0.51
 0.60
 0.50
 →
 &
 Picked character: &
 Exponent
 [29][1                   ]121
 
 Because the vector is fairly uniform, the exponent only has a slight effect and
 doesn’t change the picked character.
 
 This is a good thing! If we have a smooth gradient in our image, we want to
 retain it. We very much do not want to introduce unnecessary choppiness.
 
 Compare the 3D scene ASCII rendering with and without this contrast
 enhancement:
 
 We do see more contrast at boundaries, but this is not quite there yet. Some
 edges are still not sharp enough, and we also observe a “staircasing” effect
 happening at some boundaries.
 
 Let’s look at the staircasing effect first. We can reproduce it with a boundary
 like so:
 
 Below is the ASCII rendering of that boundary. Notice how the lower edge (the !
 s) becomes “staircase-y” as you increase the exponent:
 
 We see a staircase pattern like so:
 
                !!!!!
           !!!!!!!!!!
      !!!!!!!!!!!!!!!
 !!!!!!!!!!!!!!!!!!!!
 
 To understand why that’s happening, let’s consider the row in the middle of the
 canvas, progressing from left to right. As we start off, every sample is
 equally light, giving us Us:
 
 UUUUUUUU ->
 
 As we reach the boundary, the lower right samples become a bit darker. Those
 darker components are crunched by contrast enhancement, giving us some Ys:
 
 0.60
 0.60
 0.60
 0.60
 0.40
 0.30
 →
 A
 Picked character: A
 Exponent
 [32][1                   ]121
 
 So we get:
 
 UUUUUUUUYY ->
 
 As we progress further right, the middle and lower samples get darker, so we
 get some fs:
 
 0.60
 0.60
 0.55
 0.46
 0.32
 0.26
 →
 f
 Picked character: f
 
 This trend continues towards ", ', and finally, `:
 
 0.54
 0.45
 0.34
 0.25
 0.20
 0.20
 →
 !
 Picked character: !
 Exponent
 [34][1                   ]121
 
 Giving us a sequence like so:
 
 UUUUUUUUYYf""''` ->
 
 That looks good, but at some point we get no light samples. Once we get no
 light samples, our contrast enhancement has no effect because every component
 is equally light. This causes us to always get !s:
 
 0.20
 0.20
 0.20
 0.20
 0.20
 0.20
 →
 !
 Picked character: !
 Exponent
 [36][1                   ]121
 
 Making our sequence look like so:
 
 UUUUUUUUYYf""''`!!!!!!!!!! ->
 
 This sudden stop in contrast enhancement having an effect is what causes the
 staircasing effect:
 
                !!!!!
           !!!!!!!!!!
      !!!!!!!!!!!!!!!
 !!!!!!!!!!!!!!!!!!!!
 
 Let’s see how we can counteract this staircasing effect with another layer of
 contrast enhancement, this time looking outside of the boundary of each cell.
 
 Directional contrast enhancement
 
 We currently have sampling circles arranged like so:
 
 For each of those sampling circles, we’ll specify an “external sampling
 circle”, placed outside of the cell’s boundary, like so:
 
 Each of those external sampling circles is “reaching” into the region of a
 neighboring cell. Together, the samples that are collected by the external
 sampling circles constitute an “external sampling vector”.
 
 Let’s simplify the visualization and consider a single example. Imagine that we
 collected a sampling vector and an external sampling vector that look like so:
 
 0.51
 0.51
 0.52
 0.52
 0.53
 0.53
 0.80
 0.51
 0.57
 0.52
 0.53
 0.53
 →
 U
 Picked character: U
 
 The circles colored red are the external sampling vector components. Currently,
 they have no effect.
 
 The “internal” sampling vector itself is fairly uniform, with values ranging
 from to . The external vector’s values are similar, except in the upper left
 region where the values are significantly lighter ( and ). This indicates a
 color boundary above and to the left of the cell.
 
 To enhance this apparent boundary, we’ll darken the top-left and middle-left
 components of the sampling vector. We can do that by applying component-wise
 contrast enhancement using the values from the external vector.
 
 In the previous contrast enhancement, we calculated the maximum component value
 across the sampling vector and normalized the vector using that value:
 
 const maxValue = Math.max(...samplingVector)
 
 samplingVector = samplingVector.map((value) => {
   value = value / maxValue; // Normalize
   value = Math.pow(value, exponent);
   value = value * maxValue; // Denormalize
   return value;
 })
 
 But the new component-wise contrast enhancement will take the maximum value
 between each component of the sampling vector and the corresponding component
 in the external sampling vector:
 
 samplingVector = samplingVector.map((value, i) => {
   const maxValue = Math.max(value, externalSamplingVector[i])
   // ...
 });
 
 Aside from that, the contrast enhancement is performed in the same way:
 
 samplingVector = samplingVector.map((value, i) => {
   const maxValue = Math.max(value, externalSamplingVector[i]);
   value = value / maxValue;
   value = Math.pow(value, exponent);
   value = value * maxValue;
   return value;
 });
 
 The example below shows how light values in the external sampling vector push
 values in the sampling vector down:
 
 0.51
 0.51
 0.52
 0.52
 0.53
 0.53
 0.80
 0.51
 0.57
 0.52
 0.53
 0.53
 →
 U
 Picked character: U
 Exponent
 [42][1                   ]141
 
 I call this “directional contrast enhancement”, since each of the external
 sampling circles reaches outside of the cell in the direction of the sampling
 vector component that it is enhancing the contrast of. I describe the other
 effect as “global contrast enhancement” since it acts on all of the sampling
 vector’s components together.
 
 Let’s see what this directional contrast enhancement does to get rid of the
 staircasing effect:
 
 Hmm, that’s not doing what I wanted. I wanted to see a sequence like so:
 
             ..::!!
       ..::!!!!!!!!
 ..::!!!!!!!!!!!!!!
 
 But we just see ! changing to :
 
 0.20
 0.20
 0.20
 0.20
 0.20
 0.20
 0.40
 0.35
 0.20
 0.20
 0.20
 0.20
 →
 !
 Picked character: !
 Exponent
 [44][1                   ]141
 
 This happens because the directional contrast enhancement doesn’t reach far
 enough into our sampling vector. The light upper values in the external vector
 do push the upper values of the sampling vector down, but because the lightness
 of the four bottom components is retained, we don’t get to ., just :.
 
 Widening the directional contrast enhancement
 
 I’d like to “widen” the directional contrast enhancement so that, for example,
 light external values at the top spread to the middle components of the
 sampling vector.
 
 To do that, I’ll introduce a few more external sampling circles, arranged like
 so:
 
 These are a total of external sampling circles. Each of the external sampling
 circles will affect one or more of the internal sampling circles. Here’s an
 illustration showing which internal circles each external circle affects:
 
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 0.30
 
 For each component of the internal sampling vector, we’ll calculate the maximum
 value across the external sampling vector components that affect it, and use
 that maximum to perform the contrast enhancement.
 
 Let’s implement that. I’ll order the internal and external sampling circles
 like so:
 
 0
 1
 2
 3
 4
 5
 0
 1
 2
 3
 4
 5
 6
 7
 8
 9
 
 We can then define a mapping from the internal circles to the external sampling
 circles that affect them:
 
 const AFFECTING_EXTERNAL_INDICES = [
   [0, 1, 2, 4],
   [0, 1, 3, 5],
   [2, 4, 6],
   [3, 5, 7],
   [4, 6, 8, 9],
   [5, 7, 8, 9],
 ];
 
 With this, we can change the calculation of maxValue to take the maximum
 affecting external value:
 
 // Before
 const maxValue = Math.max(value, externalSamplingVector[i]);
 
 // After
 let maxValue = value;
 for (const externalIndex of AFFECTING_EXTERNAL_INDICES[i]) {
   maxValue = Math.max(maxValue, externalSamplingVector[externalIndex]);
 }
 
 Now look what happens if the top four external sampling circles are light: it
 causes the contrast enhancement to reach into the middle of the sampling
 vector, giving us the desired effect:
 
 0.20
 0.20
 0.20
 0.20
 0.20
 0.20
 0.58
 0.52
 0.31
 0.26
 0.20
 0.20
 0.20
 0.20
 0.20
 0.20
 →
 !
 Picked character: !
 Exponent
 [47][1                   ]141
 
 We now smoothly transition from ! -> : -> . — beautiful stuff!
 
 Let’s see if this change resolves the staircasing effect:
 
 Oh yeah, looks awesome! We get the desired effect. The boundary is nice and
 sharp while not being too jagged.
 
 Here’s the 3D scene again. The contrast slider now applies both types of
 contrast enhancement at the same time — try it out:
 
 This really enhances the contrast at boundaries, making the image far more
 readable!
 
 Together, the 6D shape vector approach and contrast enhancement techniques have
 given us a really nice final ASCII rendering.
 
 Final words
 
 This post was really fun to build and write! I hope you enjoyed reading it.
 
 ASCII rendering is perhaps not the most useful topic to write about, but I
 think the idea of using a high-dimensional vector to capture shape is
 interesting and could easily be applied to many other problems. There are
 parallels to be drawn to [48]word embeddings.
 
 I started writing this ASCII renderer to see if the idea of using a vector to
 capture the shape of characters would work at all. That approach turned out to
 work very well, but the initial prototype was terribly slow — I only got
 single-digit FPS on my iPhone. To get the ASCII renderer running at a smooth
 FPS on mobile required a lot of optimization work. I describe some of that
 optimization work in the appendices on [49]character lookup performance and 
 [50]GPU acceleration below.
 
 My colleagues, after reading a draft of this post, suggested many alternatives
 to the approaches I described in this post. For example, why not make the
 sampling vector ? That would capture the shape of T far better — just look how
 T’s stem falls between the two sampling circles in each row:
 
 And yeah, he’s right! A layout would certainly capture it better. They also
 suggested many alternative approaches to the contrast enhancement methods I
 described, but I won’t explore those in this post.
 
 It’s really fun how large the solution space to the problem of ASCII rendering
 is. There are so, so many approaches and trade-offs to explore. I imagine you
 probably thought of a few yourself while reading this post!
 
 One dimension I intentionally did not explore was using different colors or
 lightnesses for the ASCII characters themselves. This is for many reasons, but
 the two primary ones are that 1) it would have expanded the scope of this post
 too much, and 2) it’s just a different effect, and I personally don’t like the
 look.
 
 At the time of writing these final words, around months have elapsed since I
 started working on this post. This has been my longest writing process to date.
 Much of that can be explained by the birth of my now -month-old daughter. I’ve
 needed to be a lot more intentional about finding time to write — and
 disciplined when spending it. I intend to write some smaller posts next. Let’s
 see if I manage to stick to that promise.
 
 Thanks for reading! And huge thanks to [51]Gunnlaugur Þór Briem and [52]Eiríkur
 Fannar Torfason for reading and providing feedback on a draft of this post.
 
 — Alex Harri
 
 Mailing list
 
 To be notified of new posts, subscribe to my mailing list.
 
 [53][                    ]Subscribe
 Appendix I: Character lookup performance
 
 Earlier in this post, I showed how to find the best character by finding the
 character with the shortest Euclidean distance to our sampling vector.
 
 function findBestCharacter(inputVector: number[]) {
   let bestCharacter = "";
   let bestDistance = Infinity;
   
   for (const { character, shapeVector } of CHARACTERS) {
     const dist = getDistance(shapeVector, inputVector);
     if (dist < bestDistance) {
       bestDistance = dist;
       bestCharacter = character;
     }
   }
   
   return bestCharacter;
 }
 
 I tried benchmarking this for input sampling vectors on my MacBook — K
 invocations of this function consistently take about ms. If we want to be able
 to use this for an animated canvas at FPS, we only have ms to render each
 frame. We can use this to get a rough budget for how many lookups we can
 perform each frame:
 
 If we allow ourselves of the performance budget for just lookups, this gives us
 a budget of about K characters. Not terrible, but far from great, especially
 considering that we’re using numbers from a powerful laptop. A mobile device
 might have a times lower budget. Let’s see how we can improve this.
 
 k-d trees
 
 -d trees are a data structure that enables nearest-neighbor lookups in
 multi-dimensional (-dimensional) space. Their performance [56]degrades in
 higher dimensions (e.g. ), but they perform well in dimensions — perfect for
 our purpose.
 
 Internally, -d trees are a binary tree where each node is a -dimensional point.
 Each node can be thought to split the -dimensional space in half with a
 hyperplane, with the left subtree on one side of the hyperplane and the right
 subtree on the other.
 
 I won’t go into much detail on -d trees here. You’ll have to look at other
 resources if you’re interested in learning more.
 
 One could also look at the [57]hierarchical navigable small worlds (HNSW)
 algorithm, which [58]Eiríkur pointed me to. It is used for approximate nearest
 neighbor lookups in vector databases, so definitely relevant.
 
 Let’s see how it performs! We’ll construct a -d tree with our characters and
 their associated vectors:
 
 const kdTree = new KdTree(
   CHARACTERS.map(({ character, shapeVector }) => ({
     point: shapeVector,
     data: character,
   }))
 );
 
 We can now perform nearest-neighbor lookups on the -d tree:
 
 const result = kdTree.findNearest(samplingVector);
 
 Running K such lookups takes about ms on my MacBook. That’s about x faster than
 the brute-force approach. We can use this to calculate, roughly, the number of
 lookups we can perform per frame:
 
 That’s a lot of lookups per frame, but again, we’re benchmarking on a powerful
 machine. This is still not good enough.
 
 Let’s see how we can eke out even more performance.
 
 Caching
 
 An obvious avenue for speeding up lookups is to cache the result:
 
 function searchCached(samplingVector: number[]) {
   const key = generateCacheKey(samplingVector)
   
   if (cache.has(key)) {
     return cache.get(key)!;
   }
   
   const result = search(samplingVector);
   cache.set(key, result);
   return result;
 }
 
 But how does one generate a cache key for a -dimensional vector?
 
 Well, one way is to quantize each vector component so that it fits into a set
 number of bits and packing those bits into a single number. JavaScript numbers
 give us bits to work with, so each vector component gets bits.
 
 We can quantize a numeric value between and to the range to (the most that bits
 can store) like so:
 
 const BITS = 5;
 const RANGE = 2 ** BITS;
 
 function quantizeTo5Bits(value: number) {
   return Math.min(RANGE - 1, Math.floor(value * RANGE));
 }
 
 Applying a max of RANGE - 1 is done so that a value of exactly is mapped to
 instead of .
 
 We can quantize each of the sampling vector components in this manner and use
 bit shifting to pack all of the quantized values into a single number like so:
 
 const BITS = 5;
 const RANGE = 2 ** BITS;
 
 function generateCacheKey(vector: number[]): number {
   let key = 0;
   for (let i = 0; i < vector.length; i++) {
     const quantized = Math.min(RANGE - 1, Math.floor(vector[i] * RANGE));
     key = (key << BITS) | quantized;
   }
   return key;
 }
 
 The RANGE is current set to 2 ** 5, but consider how large that makes our key
 space. Each vector component is one of possible values. With vector components,
 that makes the total number of possible keys , which equals . If the cache were
 to be fully saturated, just storing the keys would take GB of memory! I’d also
 expect the cache hit rate to be incredibly low if we were to lazily fill the
 cache.
 
 Alright, is too high, but what value should we pick? We can pick any number
 under for our range. To help, here’s a table showing the number of possible
 keys (and the memory needed to store them) for range values between and :
 
 Range Number of keys Memory needed to store keys
 6     46,656         364 KB
 7     117,649        919 KB
 8     262,144        2.00 MB
 9     531,441        4.05 MB
 10    1,000,000      7.63 MB
 11    1,771,561      13.52 MB
 12    2,985,984      22.78 MB
 
 There are trade-offs to consider here. As the range gets smaller, the quality
 of the results drops. If we pick a range of , for example, the only possible
 lightness values are , , , , and . That noticeably affects the quality of
 character picks.
 
 At the same time, if we increase the possible number of keys, we need more
 memory to store them. Additionally, the cache hit rate might be very low,
 especially when the cache is relatively empty.
 
 I ended up picking a range of . It’s a large enough range that quality doesn’t
 suffer too much while keeping the cache size reasonably low.
 
 Cached lookups are incredibly fast — fast enough that lookup performance just
 isn’t a concern anymore (K lookups take a few ms on my MacBook). And if we
 prepopulate the cache, we can expect consistently fast performance, though I
 encountered no problems just lazily populating the cache.
 
 Appendix II: GPU acceleration
 
 Lookups were not the only performance concern. Just collecting the sampling
 vectors (internal and external) turned out to be terribly expensive.
 
 Just consider the sheer amount of samples that need to be collected. The 3D
 scene I’ve been using as an example uses a grid, which equals cells. For each
 of those cells, we compute a -dimensional sampling vector and a -dimensional
 external sampling vector. That is more than K vector components to compute on
 every frame!
 
 And that’s if we use a sampling quality of . If we increase the sampling
 quality, this number just gets bigger.
 
 Collecting these samples absolutely crushed performance on my iPhone, so I
 needed to either collect fewer samples or speed up the collection of samples.
 Collecting fewer samples would have meant rendering fewer ASCII characters or
 removing the directional contrast enhancement, neither of which was an
 appealing solution.
 
 My initial implementation ran on the CPU, which could only collect one sample
 at a time. To speed this up, I moved the work of sampling collection and
 applying the contrast enhancement to the GPU. The pipeline for that looks like
 so (each of the steps listed is a single shader pass):
 
  1. Collect the raw internal sampling vectors into a texture, using the canvas
     (image) as the input texture.
  2. Do the same for the external sampling vectors.
  3. Calculate the maximum external value affecting each internal vector
     component into a texture.
  4. Apply directional contrast enhancement to each sampling vector component,
     using the maximum external values texture.
  5. Calculate the maximum value for each internal sampling vector into a
     texture.
  6. Apply global contrast enhancement to each sampling vector component, using
     the maximum internal values texture.
 
 I’m glossing over the details because I could spend a whole other post covering
 them, but moving work to the GPU made the renderer many times more performant
 than it was when everything ran on the CPU.
 
 Mailing list
 
 To be notified of new posts, subscribe to my mailing list.
 
 [64][                    ]Subscribe
 [66]Alex Harri
 
 © 2026 Alex Harri Jónsson
 
 Links
 
 [67]GitHub
 
 [68]LinkedIn
 
 [69]RSS
 
 Pages
 
 [70]Home
 
 [71]Blog
 
 [72]About
 
 [73]Snippets
 
 The monospace font on this website is [74]MonoLisa, courtesy of [75]FaceType.
 
 
 References:
 
 [1] https://alexharri.com/
 [2] https://alexharri.com/about
 [3] https://alexharri.com/blog
 [4] https://chatgpt.com/share/69524279-7564-800f-ae22-a2f433794abe
 [5] https://en.wikipedia.org/wiki/Cel_shading
 [6] https://cognition.ai/
 [7] https://www.ascii-code.com/characters/printable-characters
 [8] https://en.wikipedia.org/wiki/Monospaced_font
 [9] https://en.wikipedia.org/wiki/RGB_color_model
 [10] https://en.wikipedia.org/wiki/Relative_luminance#Relative_luminance_and_%22gamma_encoded%22_colorspaces
 [15] https://en.wikipedia.org/wiki/Nearest-neighbor_interpolation
 [16] https://en.wikipedia.org/wiki/Jaggies
 [17] https://en.wikipedia.org/wiki/Supersampling
 [18] https://en.wikipedia.org/wiki/Spatial_anti-aliasing
 [22] https://en.wikipedia.org/wiki/Euclidean_distance
 [48] https://en.wikipedia.org/wiki/Word_embedding
 [49] https://alexharri.com/blog/ascii-rendering#character-lookup-performance
 [50] https://alexharri.com/blog/ascii-rendering#appendix-gpu-acceleration
 [51] https://www.linkedin.com/in/gunnlaugur-briem/
 [52] https://eirikur.dev/
 [56] https://graphics.stanford.edu/~tpurcell/pubs/search.pdf
 [57] https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world
 [58] https://eirikur.dev/
 [66] https://alexharri.com/
 [67] https://github.com/alexharri
 [68] https://www.linkedin.com/in/alex-harri-j%C3%B3nsson-b1273613b/
 [69] https://alexharri.com/rss.xml
 [70] https://alexharri.com/
 [71] https://alexharri.com/blog
 [72] https://alexharri.com/about
 [73] https://alexharri.com/snippets
 [74] https://www.monolisa.dev/
 [75] https://www.facetype.org/