The Tiniest GIF Ever | Hacker News Reader

The Tiniest GIF Ever

probablyprogramming.com

204 pointsdonohoe49 comments

Great write up and +1 kudos to author for diving into the details.

For the mere mortals out there looking to make their GIF, JPEG, and PNG images smaller (and websites faster), I highly recommend ImageOptim (http://imageoptim.com/). This Mac-only tool combines all of the libraries below to compress your images down to the (nearly if not the) smallest, cross-system compatible size.

If you're Mac based, try this:

* ImageOptim http://imageoptim.com/

If you're Linux based, try these:

* PNGOut - http://www.advsys.net/ken/util/pngout.htm

* advpng - http://advancemame.sourceforge.net/doc-advpng.html

* pngcrush - http://pmt.sourceforge.net/pngcrush/

* optipng - http://optipng.sourceforge.net/

* jpegoptim - http://www.kokkonen.net/tjko/projects.html

* gifsicle - http://www.lcdf.org/gifsicle/

Just to add... for PNG optimisations on Windows.

* PNGGauntlet - http://pnggauntlet.com/ - Combines PNGOUT, OptiPNG, and DeflOpt.

If you're desperate to save space (or creating thumbnails), Windows/C# devs can lossily cut down PNGs to 256 color/8-bit using nQuant http://nquant.codeplex.com/

Matt Wrock documented the creation of the tool, including details on the approaches taken by tools like OptiPNG: http://www.mattwrock.com/post/2011/09/05/Convert-32-bit-PNGs...

Worth mentioning as well is TinyPNG - http://tinypng.org/, a free web service that uses lossy compression to shrink PNG images.

If you want it locally: http://pngnq.sourceforge.net/

I think the service simply uses that program behind the scenes.

No, they use their own tech. It uses some pre-existing algorithms but it's currently not available for offline use.

TinyPNG uses http://pngquant.org and optipng.

It's a bit more than that, I know advpng is also used somewhere in the process.

http://news.ycombinator.com/item?id=4167964 (by molf, apparently someone involved in creating TinyPNG)

   > Mostly pngquant (the new version), optipng and 
   > advpng. We are still tuning parameters and 
   > swapping in and out tools based on our benchmarks 
   > and testing suite.

from their debut on HN back in June, where they caught a lot of flack for being a web service:

http://news.ycombinator.com/item?id=4167964

Interesting read, thanks.

In my tests, it's lossy, but it's just barely lossy. Keep your original and deploy this version on your site.

I just wish they had an API/offline utility.

While I didn't see any public mention of it, you can use

  curl --data-binary @your-file.png http://tinypng.org/api/shrink

That's fantastic, thanks. I wonder if they'd mind me creating a batch tool for personal use...

The coolest aspect of this article IMO was that Gimp's output (with the right options selected) was already the minimum size for a transparent 1x1 gif.

He succeeded in trimming only 6 bytes off of that before he abandoned transparency and that was at the cost of getting errors in some programs with the result (no thanks).

For PNGs, I have yet to come across a tool that would beat PNGOUT.

ImageOptim is essentially a wrapper for, among other tools, PNGOUT.

Pngcrush is a great alternative.. and so is smushit - http://www.smushit.com/ysmush.it/

For Linux, Trimage does the same thing as ImageOptim, plus it works on the command line:

http://trimage.org/

I did a few tests some time ago and to obtain tiniest possible images on majority of files I have to do following sequences

PNG: advpng -z4, optipng -o7, advdef -z4

JPG: jpegtran -copy none, jpegrescan (that also uses jpegtran)

GIF: gifsicle -O3

They are quite time consuming (especially in case of PNG), but if you know any better sequences, please let me know!

http://davidcrowell.com/jstrip

jscl.exe -d -j -n -r -s ¤.jp¤

Instantly gets rid of more jpg junk.

Edit: replace asterixes with ¤

I love these 'protocol-teardown' posts. They really bring back the obsession over the details which has been disregarded more and more as technology progresses. They're refreshing. :)

I was thinking I'd write the same thing: "I love these 'smallest X' posts". I was thinking of the Muppetlabs "smallest ELF file" article, in particular, and Russ Cox's Zip file that decodes to a zip file (turtles all the way down).

But won't there always exist a few people who just happen to have a talent or obssesion for the details? What name do we give those people? The word "hacker" is taken, and has a more impish, generalist connotation. "Engineer" has way too formal baggage associated. We need another word that means about the same thing as "docent", I reckon.

explorer, investigator, researcher.

Don't forget the Obfuscated C Contest (IOCCC.org).

tinkerer

At the risk of confusing spellcheckers everywhere, Optimetrist?

I agree. I'm always amazed when a compression protocol omits a "do nothing" option, or doesn't use that as its base reference, progressively moving away from it as it makes sacrifices to save space (computing overhead for lossless, quality for lossy). Is it even possible to encode a lossless MP3 of John Cage's 4′33″?

John Cage's famous piece is not simply silence, it's the performance of silence.

A particular performance of it, probably not. The space of possible lossless MP3s is quite tiny and I suspect consists of pure or close to pure tones, not the more complex spectra you get for the coughs and page turning you usually hear is 4'33".

If anyone is interested, I did the same with TIFF: http://news.ycombinator.com/item?id=3773355

The peculiarity in this example is, that the image's content is the whole tiff itself.

This can actually be useful if you want to make sure your interface works with images turned off.

Some people, especially mobile users concerned with bandwidth, might have images turned off but CSS turned on. I had icons for some buttons, sprited and set as CSS backgrounds. Inside the same element I put an img tag with a minimal gif and an alt text with a fallback (a text label, or a single unicode character). The invisible image would be shown for users images, and the alt text for users without images.

Reminded me of the tiniest "Hello, world" ELF binary:

http://timelessname.com/elfbin

I love posts like this.

"Opening this image in Firefox at various different times, it has show up as shades of blue, green and brown"... That seems like odd behavior - does anyone know why this would be the case? Is it different stack values at the time?

Possibly Firefox doesn't clear the memory used to draw the image, assuming all will be filled. So different stack or heap values.

It could also be re-using a drawing surface of some sort.

Seems like it could lead to information disclosure

I don't think that's it -- I'm not sure where I saw this, but I believe it's because if there's no global color table in the image, the spec says the displaying software should supply one... but there's no standard color table, so Firefox substitutes the color table from the last image it displayed. With asynch loading that can vary.

If that's not right, maybe it's supplying a color table randomly-generated on the fly, but I doubt it's just random memory -- can any random bytes really make up a valid color table? If it were random memory I'd expect crashes or errors, not varying colors.

All a color table is is a series of integers. Any random byte, or two, or four, is a valid integer.

Have you ever done any C programming? malloc() returns a pointer to an allocated block, but it isn't zeroed for you, so if you don't clear it yourself you may end up with random data. Same with uninitialised variables in C.

I have; but I was talking about whether the Mozilla devs, given no color table in a GIF, assume they actually found one and stored it to a memory location, or handled the case as correctly as they could (by initializing the memory with a replacement color table).

It's a programming error if they assume the earlier code found an (optional) color table; that's it.

I didn't know the color table was formatted -- kinda obviously, it's just a 3-byte chunk per color, though (i.e., 00ffaa) so any bytes in there will be valid colors... so my original idea that random memory would crash things (by providing an invalid color table) was wrong.

You may assume too much here. The code may simply assume a colour table has been populated along the way. There might not even be a check for there being no global colour table or frame colour table.

That's exactly what I'm saying -- that may well be the case (and that would be a coding error), or maybe they coded some handling; we can't tell from the results (varyingly-colored pixels in the displayed result).

Pretty small SVG image:

    <svg xmlns="http://www.w3.org/2000/svg"/>

Related: every programmer should take a look at LZW, the GIF compression algorithm, it is one of this "damn cool algorithms" out there, really simple, beautiful, and powerful.

This would be/is useful for tracking purposes if/when a real gif is necessary

i just wonder that nobody mentioned http://www.smushit.com/ysmush.it/ yet.

Why not just use HTTP 204 No Content?

And it most likely makes no difference at all, because everything is wrapped into packets of a fixed size, much larger than 43 bytes.

Hacking and practicality seldom meet.

You can use data URI and embed it directly in your CSS file. Then size matters.

Reply on news.ycombinator.com