
The Tiniest GIF Ever - donohoe
http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ever
======
kevinconroy
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/>

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

~~~
ars
If you want it locally: <http://pngnq.sourceforge.net/>

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

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

~~~
j_s
<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>

~~~
SquareWheel
Interesting read, thanks.

------
bowmessage
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. :)

~~~
bediger4000
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.

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

------
elsamuko
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.

------
jacobr
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.

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

<http://timelessname.com/elfbin>

I love posts like this.

------
mrspeaker
"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?

~~~
TazeTSchnitzel
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.

~~~
jtheory
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.

~~~
TazeTSchnitzel
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.

~~~
jtheory
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.

~~~
TazeTSchnitzel
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.

~~~
jtheory
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).

------
Zash
Pretty small SVG image:

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

------
antirez
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.

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

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

------
iso-8859-1
Why not just use HTTP 204 No Content?

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

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

