[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