[OSM-dev] Optimising PNGs / Colour reduction

[Robert (Jamie) Munro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Burgess wrote:
> Approximately half the time spent to rendering a single tile in the
> Mapnik layer is spent in the colour conversion (color255) so the speed
> of this code is very important to the overall tile processing rate.

Rather than using imagemagik to calculate a pallette each time, can
Mapnik draw to a 4bits per channel (12 bit) image instead of a 8bits per
channel (24 bit) image? We could then use a lookup table of 4096 bytes
to decide which  indexed colour to use where, based on a pre-optimised
palette worked out for the styles in the map as a whole. This would take
almost no time to process - we're talking just a few CPU cycles per
pixel, and should give results that are nearly as good in most cases. If
12 bits isn't enough, we could use 15, which requires a 32kb lookup
table, or even 18 bits and a 256kb lookup table.

Once we have an 8 bit indexed image, we count the colours that are
actually used, and reduce the palette to just those. Blank sea tiles
will only use 1 colour, therefore be 1 bit images, many other tiles are
likely to use less than 128, 64, 32 or even 16 colours. All tiles will
use the exact same pallette, so colours will match between tiles, it's
just that they would only use a subset.

We can improve results by encouraging our cartographers to stick to a
limited range of colours, leaving us more colours to reserve for the
most common anti-aliasing shades. We could also pick things like rivers
to be a shade of blue that is useful for anti-aliasing coastlines or
motorways etc.


Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHQtBsz+aYVHdncI0RApuqAJ9UIVAFch+takdFGVoXQ3guUdfdSQCff4Dv
/Sy/pRS+LKbgnjpgNnKAJa4=
=7Ng/
-----END PGP SIGNATURE-----