Comment by crazygringo
20 days ago
> 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
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
3 replies →
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.
Yes I have not not seen this technique used for image to ascii art. Maybe for hand crafted stuff it isn't.