Show HN: An interactive guide to compression basics

I find it funny that GIFs are still being referred as GIFs [1] while most places serve them as h264 yuv420p MP4s [2].<p>[1] <a href="https:&#x2F;&#x2F;i.giphy.com&#x2F;l0Iy1ZcHArR9aAQta.gif" rel="nofollow">https:&#x2F;&#x2F;i.giphy.com&#x2F;l0Iy1ZcHArR9aAQta.gif</a> (2.7MB)<p>[2] <a href="https:&#x2F;&#x2F;i.giphy.com&#x2F;media&#x2F;l0Iy1ZcHArR9aAQta&#x2F;giphy.mp4" rel="nofollow">https:&#x2F;&#x2F;i.giphy.com&#x2F;media&#x2F;l0Iy1ZcHArR9aAQta&#x2F;giphy.mp4</a> (307KB)<p>[3] <a href="https:&#x2F;&#x2F;media.giphy.com&#x2F;media&#x2F;l1J3OGcUiw8NeXuM0&#x2F;source.mp4" rel="nofollow">https:&#x2F;&#x2F;media.giphy.com&#x2F;media&#x2F;l1J3OGcUiw8NeXuM0&#x2F;source.mp4</a> (146KB) &lt;-- optimized with ffmpeg

I caved and added a &quot;toggle pointless gifs&quot; button, history will judge me well

I found this quite hard to read despite the interesting content, mainly due to the animated gifs inserted throughout the article. It&#x27;s very hard to focus on a line of text when there&#x27;s an image darting around on the page. I wonder why the author decided to include them?

Gary Bernhardt has a great live screencast where he writes a compressor - for anyone that found this hard to follow: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3Eu9ZVZEZ3I" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=3Eu9ZVZEZ3I</a>

Lose the gifs, and you have a very good article. I think they distract, rather than enhance.

OP here - I&#x27;m seeing 50&#x2F;50 support for the gifs. I&#x27;m keepin my gifs. I like the idea of adding, and will probably implement, a toggle for all extraneous gifs. I love that most of the commentary about this article is about the gifs. Gifs.

The pixel art doesn&#x27;t show up for me in Firefox or Edge. (Looks like they&#x27;re there, just with a height of 0px?) Also, my motion-sensitive lizard brain thanks you for the gif toggle button.

Unless I mis-read or mis-understood you seem to invert the meaning of compression ratio half way through ?<p>&gt; (100 &#x2F; 200) = 0.5. Protip: compression ratios less than 1 are frowned upon.<p>&gt; Unfortunately, it&#x27;s not that simple. Say we had an algorithm (let&#x27;s call it A) that, given any input whatsoever, was capable of achieving a compression ratio of strictly less than 1.

Once you understand RLE, LZ is only one step away --- instead of repetitions of individual characters&#x2F;bytes&#x2F;etc., you encode repetitions of longer strings.<p>But starting with RLE is IMHO definitely a good choice --- far better than Huffman, as a lot of introductory material seems to do. A minimal LZ12&#x2F;4 (4KB window, 18B max length; an old favourite of the demoscene intro packers) compressor&#x2F;decompressor pair is literally a few hour&#x27;s worth of work, and yields surprisingly good compression for its simplicity, much better than simple order-0 Huffman.

This is nice! One minor error - 本 does not mean a tree, but a book or a root. 木 would be appropriate for the word &#x27;tree&#x27;.

Contrary to the rest of the comments here, I enjoyed the gifs.

I&#x27;m probably getting old because I can&#x27;t stand this new trend of putting useless gifs (or mp4&#x27;s actually) every two paragraphs in every article on the web. Oh, and of course all of them have autoplay enabled because sole purpose of my laptop&#x27;s fan is to happily spin at full speed. &lt;&#x2F;random rant&gt;

Awesome! Thanks!<p>Any chance you want to do one on compression of a integer time series? How about variable length integers? Such an article would be very appreciated in IoT circles since data (timed voltage values) transfer and storage can get quite expensive for dollars and latency.<p>Cheers!

The first example (tree represented in Japanese) seemed a bit misleading, because the &quot;alphabet&quot; has not been kept as a constant. Since the Japanese alphabet is much larger, it may be argued that the number of bits actually occupied in storage by &quot;本&quot; and &quot;tree&quot; are about the same. Could someone clarify if this is correct reasoning?

I really like the article. One point if like to see: you stepped over the fact that your using palettes without mentioning even though that gets you down from using 3 (or 4) bytes a pixel to 1&#x2F;4. It&#x27;s a compression ratio of 8 that your completely ignoring!

&gt; This might eek out a little more compression<p>It&#x27;s &quot;eke&quot;: <a href="http:&#x2F;&#x2F;www.dictionary.com&#x2F;browse&#x2F;eke" rel="nofollow">http:&#x2F;&#x2F;www.dictionary.com&#x2F;browse&#x2F;eke</a>

This is a fantastic explanation. Thanks! (Also, I love the gifs)

Add a way to toggle the gifs off at the beginning for people that don&#x27;t like memes distracting them from the content and you&#x27;ve got yourself a winner.

Great article, would be interested in more in depth articles on say, JPEG compression in the future.<p>Really liked the better&#x2F;worse thing too, added some nice comparison

Fantastic article. I really enjoyed the inclusion of a live, clickable demo with example output. Absolutely well done (after I disabled the GIFs).

Great article, exquisite gifs. :^)<p>Including the size of each Obama JPEG could be pretty interesting too.

I toggled the gifs off since I read the comments before the article. I must say, the article is excellent and you could even share it with a non-technical manager or spouse*<p>*goes ands talks to wife about compression basics :)

write a follow-up. it&#x27;s interesting

&gt; TODO - proper formatting for maths-y notation<p>Hmm