[OSM-dev] speeding up tile rendering using a custom "convert -color 255" program.

Jon Burgess jburgess at uklinux.net
Thu Nov 23 20:49:36 GMT 2006


On Thu, 2006-11-23 at 11:08 +0000, SteveC wrote:
> * @ 23/11/06 02:22:55 AM jburgess at uklinux.net wrote:
> > While experimenting with the new tile renderer I noticed that the
> > "convert -color 255" step of the tile generation was taking more CPU
> > than anything else. To attempt to optimise this I hacked together a
> > quick C program which uses the same ImageMagick library but with
> > hardcoded options. For me this is several times faster than the stock
> > convert command. 
> > 
> > I don't know the complete story behind why this custom version is so
> > much faster. Perhaps it is because I've not provided any colour space
> > correction or dithering parameters. Maybe i've lost some quality in the
> > output, but the tiles I've generated with it so far look OK to me.
> 
> The important thing is the size, reducing the colour space reduces the
> size of the tile. Are your things quicker _and_ smaller/same to the old
> ones?
> 

The code still performs the reduction in the number of colours in the
image. Colour spaces describe the how the colours in the image should be
displayed. The difference is fairly subtle and is because devices all
display images slightly differently.

eg. the colours in an image shown on an LCD will appear differently to
the same image printed on photo inkjet paper.

This is important for producing high quality output of photo-like images
but seems a bit unnecessary for a map (it matters that a forest area
renders in a green colour, but it doesn't matter precisely what shade of
green is used). 

http://en.wikipedia.org/wiki/Color_space 


Anyway back to the performance of the two tools. I rendered all the
tiles in a certain area at zoom levels 10 & 11 and compared the results.

Tool     Time/s   'du -shc tiles'
convert  242      694kB
color255 114      727kB    


The overall the speed of the tile generation process can be doubled for
a 5% loss in compressed image size. I can look into why the tiles are
marginally larger. The doubling in speed seems a reasonable trade off to
me (especially until we get tiles for the whole of planet.osm).

Note this doubles the speed of the whole generate_tiles process, not
just the time to convert the images, which is much faster than double
the speed.

	Jon






More information about the dev mailing list