Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

alexharri.com

Post reply on HN
Print view View original

131–140 of 158 posts

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

#131

Post by leptons »

echelon wrote: post #128
leptons wrote: post #111

Earlier quoted context omitted.

Some countries are banning social media for teenagers, but they really should be banning "AI" all teenagers. Most adults can't even be trusted with asking an "AI" about anything, so children are going to have a very warped world view the more they interact with "AI". The tech really is not ready for prime time.

I see plenty of people getting real work done with it. Why on earth would we ban it?

I see plenty of people taking "hallucinations" as the truth, and teenagers above all do not have the mental capacity to tell truth from nonsense, so they are learning things that are completely false from "AI". Teenagers are not "people getting real work done with AI". I'm not sure how you could so completely misunderstand my comment.

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

#133

Post by iknowstuff »

frognumber wrote: post #125

This was painful to read. It become better and simpler with a basic signals & systems background: - His breaking up images into grids was a poor-man's convolution. Render each letter. Render the image. Dot product. - His "contrast" setting didn't really work. It was meant to emulate a sharpen filter. Convolve with a kernel appropriate for letter size. He operated over the wrong dimensions (intensity, rather than X-Y)…

Jeez nobody’s going to respect you more for writing like a jackass

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

#134

Post by araes »

Instantnoodl wrote: post #121
crazygringo wrote: post #40

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

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.

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

#135

Post by kennethallen »

echoangle wrote: post #37

Very cool effect! > 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. I still don’t really understand why the inner part of the rectangle can’t just be split in a 2x3 grid. Did I miss the explanation?

There are many different supersampling patterns you can use: https://en.wikipedia.org/wiki/Supersampling#Supersampling_pa...

A grid can have unwanted aliasing effects. It all depends on the kinds of images you're working with.

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

#136

Post by eru »

Keyframe wrote: post #127
eru wrote: post #122

Earlier quoted context omitted.

I was seriously looking into the GameBoy Advance, but the real hardware has gotten quite expensive these days. I wonder how the latest and greatest Wonderswan is doing in terms of price.

One uses emulator while developing anyways. Try with C64 and VICE and join us at https://csdb.dk/

> One uses emulator while developing anyways.

Yes, but part of the joy is the anticipation of playing on a real device at the end.

> Try with C64 and VICE and join us at https://csdb.dk/

Thanks for the invitation! I used a C64 as my only computer in the late 1990s long past its prime, because my mother got a really good deal on a whole set with printer and disk drives and plenty of disks with software (mostly games, from magazines). However, I was still a bit annoyed by the limitations of the system. I guess, if I had had a forth disk, I might have felt different.

In any case, for personal reasons I don't want to explore the C64 more.

But I never had a GameBoy Advance nor a Wonderswan.

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

#138

Post by Aaron2222 »

alexharri wrote: post #94
AgentMatt wrote: post #32

Great article! I think there's a small problem with intermediate values in this code snippet: const maxValue = Math.max(...samplingVector) samplingVector = samplingVector.map((value) => { value = x / maxValue; // Normalize value = Math.pow(x, exponent); value = x * maxValue; // Denormalize return value; }) Replace x by value.

Just pushed a fix, should be live in a minute or two, thanks again!

This loop is similarly suspect:

  let maxValue = value;
  for (const externalIndex of AFFECTING_EXTERNAL_INDICES[i]) {
    maxValue = Math.max(value, externalSamplingVector[externalIndex]);
  }

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

#139

Post by catlifeonmars »

stephantul wrote: post #53

Amazing 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 could also consider skipping the sqrt.

This is a trick I reach for all the time: it’s cheaper to compare squared distances than completing the Euclidean calculation. For example, to determine whether to stop calculating lerp: x*x+y*y <= epsilon.

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

#140

Post by unnah »

frognumber wrote: post #125

This was painful to read. It become better and simpler with a basic signals & systems background: - His breaking up images into grids was a poor-man's convolution. Render each letter. Render the image. Dot product. - His "contrast" setting didn't really work. It was meant to emulate a sharpen filter. Convolve with a kernel appropriate for letter size. He operated over the wrong dimensions (intensity, rather than X-Y)…

It's probably much more exciting to implement stuff like this when you can experiment with your own ideas to figure out the solution from scratch, compared to someone who sees it as a trivial exercise in signal processing, which they can't be bothered to implement.
Post reply on HN