Hacker News Reader

Comment by EMRZ | Hacker News Reader

The last week i found this [1] thread by Notch. He is working in an entry to js13k [2] (a game jam about html5 games restricted to 13 KBs).

He bundled the whole source code and binary data used in the game/tech demo to use the in browser image decompression, avoiding to write a custom (de)compression code, saving KBs this way.

Then he just eval() the needed parts for each thing.

I found this extremely clever, game jam limitations, specially size ones, evolve into clever programming tricks that are interesting both to code and to look at.

[1] https://twitter.com/notch/status/1035811278520872960

[2] http://js13kgames.com/

View on HN

Just so other readers don't mistake this for what it is: this is a pretty common technique in JS sizecoding and it's by no means Notch's invention (and he doesn't claim that it is).

When i read that i found it amazing and very clever, i honestly never thought if it was or not Notch's invention.

I am not really into javascript/frontend development, but following js13k on twitter showed me a lot of things you can do to gain KBs on the client side.

However, is this that common?

Thanks for the info btw.

In 1k sizecoding it's rather uncommon because usually the decompression code (i.e. load the png, read the pixels) is bigger than the savings. I never dove into 13k sizecoding but I bet the payoff is much better there. I wouldn't be surprised if all decent 13k sizecoding entries would do something like this. some compression for sure, and why not PNG then?

While definitely cool, I wonder how effective this is. Code/random binary data should have different characteristics than image data.

It's very effective, because it means you get a really good compression algorithm for free (because it's already there in the browser).

You definitely won't save enough bytes with better input heuristics than the amount of code needed to decompress them if you're only working with 13Kb of data.

You really save bytes even though you need to include it as a base64 url?

It is not a base64 url, is base64 image data.

DEFLATE, which is used by PNG, is a general purpose LZ77-like compression algorithm suitable for all kinds of repetitive data.

PNG filters each horizontal line of the image data before running it through Deflate, with a pre-processing step.

Each of the possible filters is very simple, but the difference between a great PNG exporter, a mediocre one, and a trash fire is the use of a heuristic to decide which of the pre-processing filters should be applied to each line of output. libpng, the free implementation, includes a heuristic that does a fairly OK job, if you just don't implement a heuristic and use no filtering at all, the results are enormous PNG files as seen in turn of the century Adobe Photoshop. So, no, a general purpose compression algorithm isn't very good for image data on its own.

(Choose for yourself whether you think Adobe wanted to discourage use of a popular free image format in favour of licensed formats for which it held relevant IP, or their development team are just incompetent morons, or both).

> PNG filters each horizontal line of the image data before running it through Deflate, with a pre-processing step.

Yes, as a means of making the data fed into the compressor repetitive enough to benefit from the compression algorithm.

> So, no, a general purpose compression algorithm isn't very good for image data on its own.

That's not what I said.

Reply on news.ycombinator.com