Comments weren't kidding. Amazing post. Great job
ASCII characters are not pixels: a deep dive into ASCII rendering
141–150 of 158 posts
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#142> Application error: a client-side exception has occurred (see the browser console for more information).
Thanks for erasing all the content once the page loads, saved me the time I would have spent reading the article.
There really needs to be a name for error handling that is worse than the initial error.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#143> The image of Saturn was generated with ChatGPT.
Was there something wrong with using an actual image of saturn? NASA lets you use their images for stuff if you want https://www.nasa.gov/nasa-brand-center/images-and-media/, and if you're worried that might change down the line, you could just add a little attribution thing for NASA
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#144> The image of Saturn was generated with ChatGPT. Was there something wrong with using an actual image of saturn? NASA lets you use their images for stuff if you want https://www.nasa.gov/nasa-brand-center/images-and-media/ , and if you're worried that might change down the line, you could just add a little attribution thing for NASA
I'm not sure why it bothers you. But to guess why OP has done it - if you look at his request to ChatGPT - he wanted a square image with Saturn at 45 degree angle for this demonstration. I don't know if NASA has that image, and if it does, how long it would it take to dig it up (from a quick search - I couldn't find any), so it's pretty sensible to just use ChatGPT for this demonstration and credit it for the image.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#145> The image of Saturn was generated with ChatGPT. Was there something wrong with using an actual image of saturn? NASA lets you use their images for stuff if you want https://www.nasa.gov/nasa-brand-center/images-and-media/ , and if you're worried that might change down the line, you could just add a little attribution thing for NASA
I'm not sure why it bothers you. But to guess why OP has done it - if you look at his request to ChatGPT - he wanted a square image with Saturn at 45 degree angle for this demonstration. I don't know if NASA has that image, and if it does, how long it would it take to dig it up (from a quick search - I couldn't find any), so it's pretty sensible to just use ChatGPT for this demonstration and credit it for the image.
I searched "Saturn at 45 degree angle" and found https://commons.wikimedia.org/wiki/File:Saturn_during_Equino... in less than a minute of looking at google images. NASA has loads of images like that from their Cassini program.
Maybe it's just me, but I'd prefer a real image rather than something generated by the plagiarism machine that almost certainly took in that exact image as part of its training data
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#146Amazing 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 ranki…
>you will get the same results using a simple matmul, because euclidean distance over normalized vectors is a linear transform of the cosine distance.
Squared euclidean distance of normalized vectors is an affine transform of their cosine similarity (the cosine of the angle between them).
EuclideanDistance(x, y) = sqrt(dot(x - y, x - y)) = sqrt(dot(x, x) - 2dot(x, y) + dot(y, y)) = sqrt(2 - 2dot(x, y))Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#147Earlier quoted context omitted.
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
Surprised you didn't include the output result for the test image as a showcase of the library's results. Edit: nvm, confused by the libraries purpose. Thought it was primarily character based rendering focused based on the subject under discussion.
Sorry for the confusion. The use-case is a little difference because the goal is to display the image as close to the original as possible with the limitation of only being able to use a forground color, background color and character per cell. The character is selected based on it's shape just like in the article. So if you get rid of the colors in Chafa you end up with something similar to the article. That's what I wanted to say :D
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#148Amazing 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 ranki…
>you will get the same results using a simple matmul, because euclidean distance over normalized vectors is a linear transform of the cosine distance. Squared euclidean distance of normalized vectors is an affine transform of their cosine similarity (the cosine of the angle between them). EuclideanDistance(x, y) = sqrt(dot(x - y, x - y)) = sqrt(dot(x, x) - 2dot(x, y) + dot(y, y)) = sqrt(2 - 2dot(x, y))
yes, you are right. I realized my mistake afterwards but it was after the edit window.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#149It'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…
> This is a well known problem because early computers with monitors used to only be able to display characters.
It's not just monitors. My first exposure to ASCII art were posters that were printed on a Teletype, in the mid 1970's. The files had attributions to RTTY operators, which made me believe they were done by hand. Of course a Teletype had no concept of pixels.
Re: ASCII characters are not pixels: a deep dive into ASCII rendering
#150This is a great deep dive. Most ASCII renderers feel "muddy" because they treat intensity as the only variable. Treating characters as structural embeddings (the 6D vector approach) is much closer to how our eyes actually perceive edges. It reminds me of how font hinting works at low resolutions. Truly impressive work on the contrast enhancement pass too.