On stock rPi5 running this takes > 3 seconds. Three seconds to render 370 x 370, 8-bit/color RGBA image to ASCII on a 2.4GHz CPU. And this is my lead-in to rant about neofetch, which takes about 0.2 seconds to run on the same Pi (see below), which would also be the time it would slow down opening a shell should I put neofetch into my .profile. Lastly, it takes cat to cat output of neofetch to /dev/null about ~0.01 seconds, which also is the time that neofetch should probably take to run (and really, this tool too).
$ time ascii-silhouettify -i neofetch-1.png > /dev/null
real 0m1.817s
user 0m3.541s
sys 0m0.273s
$ time neofetch > out.txt
real 0m0.192s
user 0m0.118s
sys 0m0.079s
$ time cat out.txt > time
real 0m0.001s
user 0m0.001s
sys 0m0.000s
Surely the use case for this tool is to precompile your image into ASCII and then just output that on every shell start up, right? There’s no reason to convert the image every time.
I would assume that performance wasn't the prime concern, but rather the accuracy/appearance of the generated image. Most people aren't putting this in their shell startup, just as most people aren't putting an ffmpeg encode command in their shell startup.
And I would assume neofetch is relatively slow because getting some of the system information is relatively slow. e.g. to get the GPU name it does "lspci -mm":
% time lspci -mm >/dev/null
lspci -mm > /dev/null 0.03s user 0.03s system 2% cpu 2.993 total
% time lspci -mm >/dev/null
lspci -mm > /dev/null 0.03s user 0.01s system 76% cpu 0.053 total
Guess it's faster that second time due to kernel cache or whatnot, but 50ms is still fairly slow. And that's only the GPU.
The algorithm involved is actually very hefty: for each cell of a 9px by 15px grid over the image, compare each pixel of the cell to its equivalent pixel in each of the 95 ascii characters. To solve for optimal grid alignment, it repeats this for each of the 9x15 possible positionings of the image under the grid.
