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

111–120 of 158 posts

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

#111

Post by leptons »

taneq wrote: post #109
echelon wrote: post #93

Earlier quoted context omitted.

> > The image of Saturn was generated with ChatGPT. > Wait...wh...why?!? It has just begun. Wait until nobody bothers using Wikipedia, websites, or even one day forums. This is going to eat everything. And when it's immediate to say something like, "I need a high contrast image of Saturn of dimensions X by Y, focus on Saturn, oblique angle" -- that's going to be magic. We'll look at the internet and Google like we lo…

I’ve been having The Talk with my kids recently. They’ll say “I looked up this question and the answer was X.” And I’ll ask “was that answer on a credible website, or was it an AI summary?” And then explain, again, that LLMs are great at producing plausible sounding explanations for things, but that you have to ground-truth anything that they tell you if it’s important that it’s correct.

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.

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

#113

Post by fc417fc802 »

awesome_dude wrote: post #106
echelon wrote: post #105

Earlier quoted context omitted.

What statistical measures of "people" are you doing to measure this? How can you be sure nothing has changed? Anecdotally, I'm seeing a lot of "it looks like AI" comments on photos and videos now. That's the new "is it Photoshop?" I'd hold off on judgment until we get population studies on this.

What statistical measures i use to measure is of what importance to you? I haven't presented a measurement, just an expectation.

You said it hasn't happened yet and he's asking how you arrived at that conclusion.

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

#114

Post by dang »

monitron wrote: post #72

> The image of Saturn was generated with ChatGPT. Wait...wh...why?!? Of all the things, actual pictures of the planet Saturn are readily available in the public domain. Why poison the internet with fake images of it?

"Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead."

"Eschew flamebait. Avoid generic tangents."

https://news.ycombinator.com/newsguidelines.html

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

#115

Post by BobbyTables2 »

minimaxir wrote: post #102
minimaxir wrote: post #61

Earlier quoted context omitted.

I was investigating a fun webcam-to-ASCII project so now I am tempted to take an approach at porting the logic from the blog post into something reusable.

Update: I tested a port of the OP's methodology using Claude Code/Claude Opus 4.5 with some specific performance optimizations, and per the benchmarks, converting a 1024x1024 image to ASCII takes 16 microseconds . I suspect that will decrease after some more polish/iteration but that's enough for potentially real-time generation even on mobile hardware.

That doesn’t seem right.

Surely you mean 16 milliseconds ?

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

#117

Post by minimaxir »

BobbyTables2 wrote: post #115
minimaxir wrote: post #102

Earlier quoted context omitted.

Update: I tested a port of the OP's methodology using Claude Code/Claude Opus 4.5 with some specific performance optimizations, and per the benchmarks, converting a 1024x1024 image to ASCII takes 16 microseconds . I suspect that will decrease after some more polish/iteration but that's enough for potentially real-time generation even on mobile hardware.

That doesn’t seem right. Surely you mean 16 milliseconds ?

Benchmark says 15.654 µs. Rendering the text as a 1024x1024 image is 2.8737 ms.

However, the ASCII output quality is nondiverse despite using the same technique, so will need to do significantly more testing and this likely won't be released soon.

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

#118

Post by cryptonector »

Lerc wrote: post #54
jrmg wrote: post #28

This is amazing all round - in concept, writing, and coding (both the idea and the blog post about it). I feel confident stating that - unless fed something comprehensive like this post as input, and perhaps not even then - an LLM could not do something novel and complex like this, and will not be able to for some time, if ever. I’d love to read about someone proving me wrong on that.

To develop this approach you need to think through the reasoning of what you want to achieve. I don't think the reasoning in LLMs is nonexistent, but it is certainly somewhat limited. This is disguised by their vast knowledge. When they successfully achieve a result by relying on knowledge you get an impression of more reasoning than their is. Everyone seems now familiar with hallucinations. When a model's knowledge…

This. With good prompting you can get Opus 4.5 to do amazing things, but you have to know what you're doing -- it has to be the case that you could have implemented everything that Claude will do for you, and that what Claude is doing more than anything is a) go faster, b) be your well-read rubber ducky.

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

#120

Post by fsckboy »

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

in general, ascii rendering is when ascii character codes are converted to pixels. if you wish to render other pixels onto a screen using characters, they are not ascii characters, they are roman or latin character glyphs, no ascii involved. that is all.

Post reply on HN