[chriswarbo]

> Why would you ever need uncompressed bitmaps?

Because they're incredibly easy to generate programatically. For example, here's a bunch of experiments I did to test the code and image embedding process for my site:

http://chriswarbo.net/essays/procedural

The snippets of Haskell code on those pages are executed when the page's Markdown is rendered, and the images are the results. To make this work, each function maps x and y pixel coordinates to either a Bool (for b/w), an Int (for greyscale) or an (Int, Int, Int) tuple (for RGB). These are trivially converted into strings of PPM image data (via [1]), rendered to PNG (via [2]) and embedded into the page as a data URI (via [3]). The "view source" links show all the code, although it's a bit convoluted ;)

Whilst this example is just for experimentation, I could image someone generating raw bitmaps in a monitoring situation, for example.

[1] http://chriswarbo.net/git/chriswarbo-net/branches/master/sta... [2] http://chriswarbo.net/git/chriswarbo-net/branches/master/sta... [3] http://chriswarbo.net/git/chriswarbo-net/branches/master/sta...

[eru]

Off-topic: I produced some similar-ish visualisations (also with Haskell).

http://paquari.com/qsort2000.png

Quicksort of 2000 random elements, (x,y) is black iff the algorithm compares x and y. You can clearly see how the pivots get compared to all the other elements.

http://paquari.com/msortOrig2000.png

A similar picture for merge-sort, but here (x,y) is black iff the algorithm compares the elements at original position x and y.

http://paquari.com/msort2000.png

Mergesort, but colouring like in the Quicksort case.