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

51–60 of 158 posts

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

#51

Post by lysace »

Seems like stellar work. Kudos.

I am however am struck with the from an outsider POV highly niche specific terminology used in the title.

"ASCII rendering".

Yes, I know what ASCII is. I understand text rendering in sometimes painful detail. This was something else.

Yes, it's a niche and niches have their own terminologies that may or may not make sense in a broader context.

HN guidelines says "Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize."

I'm not sure what is the best course of action here - perhaps nothing. I keep bumping into this issue all the time at HN, though. Basically the titles very often don't include the context/niche.

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

#52

Post by echoangle »

DexesTTP wrote: post #39
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?

It's because circles allow for a stagger and overlap as shown later on. It's not really possible to get the same effect from squares.

But it seems like you only need the stagger and overlap because you’re using circles in the first place. Would it look worse if you just divided the rectangle into 6 squares without any gaps or overlap?

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

#53

Post by stephantul »

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 ranking, but will be a little faster.

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

#54

Post by Lerc »

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 is lacking and it is fine tuned to give an answer. A simplistic calculation says that if an accurate answer gets you 100%, then an answer gets you 50% and being accurate gets you 50%. Hallucinations are trying to get partial credit for bullshit. Teaching a model that a wrong answer is worse than no answer is the obvious solution, turning that lesson into training methods is harder.

That's a bit of a digression but I think it helps explain the difference to why I think a model would find writing an article like this.

Models have difficulty in understanding what is important. The degree to which they do achieve this is amazing, but it is still trained on data that heavily biases their conclusions to the mainstream thinking. In that respect I'm not even sure if it is a fundamental lack in what they could do. It seems to be that they are implicitly made to think of problems as "it's one of those, I'll do what people do when faced with one of those"

There are even hints in fiction that this is what we were going to do. There is a fairly common sci-fi trope of an AI giving a thorough and reasoned analysis of a problem only to be cut off by a human wanting the simple and obvious answer. If not done carefully RLHF becomes the embodiment of this trope in action.

This gives a result that makes the most people immediately happy, without regard for what is best long term, or indeed what is actually needed. Asimov explored the notion of robots lying so as to not hurt feelings. Much of the point of the robot books was to express the notion that what we want AI to be is more complicated than it appears at first glance.

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

#55

Post by panki27 »

echoangle wrote: post #52
DexesTTP wrote: post #39

Earlier quoted context omitted.

It's because circles allow for a stagger and overlap as shown later on. It's not really possible to get the same effect from squares.

But it seems like you only need the stagger and overlap because you’re using circles in the first place. Would it look worse if you just divided the rectangle into 6 squares without any gaps or overlap?

I wondered the same thing, but characters usually don't reach the edges, so I guess circles fit the average character better?

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

#56

Post by zestyping »

echoangle wrote: post #52
DexesTTP wrote: post #39

Earlier quoted context omitted.

It's because circles allow for a stagger and overlap as shown later on. It's not really possible to get the same effect from squares.

But it seems like you only need the stagger and overlap because you’re using circles in the first place. Would it look worse if you just divided the rectangle into 6 squares without any gaps or overlap?

My thought exactly. The sampling circles only enable you to (awkwardly) solve a problem that was fabricated by using circles in the first place.

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

#57

Post by wonger_ »

smusamashah wrote: post #43
wonger_ wrote: post #18

Great breakdown and visuals. Most ASCII filters do not account for glyph shape. It reminds me of how chafa uses an 8x8 bitmap for each glyph: https://github.com/hpjansson/chafa/blob/master/chafa/interna... There's a lot of nitty gritty concerns I haven't dug into: how to make it fast, how to handle colorspaces, or like the author mentions, how to exaggerate contrast for certain scenes. But I think 99% of the time, it…

But the chafa gallery isn't showing off ascii text rendering. Are there examples that use ascii text?

Good point. I haven't found many ascii examples online.

Here's a copy-paste snippet where you can try chafa-ascii-fying images in your own terminal, if you have uvx:

  uvx --with chafa-py python -c '
  from chafa import * 
  from chafa.loader import Loader 
  import sys 
  img = Loader(sys.argv[1])
  config = CanvasConfig() 
  config.calc_canvas_geometry(img.width,img.height,0.5,True,False)
  symbol_map = SymbolMap()
  symbol_map.add_by_tags(SymbolTags.CHAFA_SYMBOL_TAG_ASCII)
  config.set_symbol_map(symbol_map)
  config.canvas_mode = CanvasMode.CHAFA_CANVAS_MODE_FGBG
  canvas = Canvas(config)
  canvas.draw_all_pixels(img.pixel_type,img.get_pixels(),img.width,img.height,img.rowstride)
  print(canvas.print().decode())
  ' \
  myimage.jpg
But results are not as good as the OP's work. https://wonger.dev/assets/chafa-ascii-examples.png So I'll revise my claim that chafa is great for unicodey colorful environments, but hand-tailored ascii-only work like the OP is worth the effort.

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

#59

Post by zellyn »

mwillis wrote: post #47

Fantastic technique and deep dive. I will say, I was hoping to see an improved implementation of the Cognition cube array as the payoff at the end. The whole thing reminded me of the blogger/designer who, years ago, showed YouTube how to render a better favicon by using subpixel color contrast, and then IIRC they implemented the improvement. Some detail here: https://web.archive.org/web/20110930003551/http://typophil…

+1 yo wanting to see the cognition logo with contrast. It was set up as the target, but no payoff!

Lovely article, and the dynamic examples are :chefs-kiss:

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

#60

Post by qingcharles »

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…

It's stuff like this I would have loved to know when I was doing game engine dev in the 90s.
Post reply on HN