[OSM-dev] PNG type for Mapnik map

[Artem Pavlenko]

On 20 Dec 2007, at 18:07, Jochen Topf wrote:

> On Wed, Dec 19, 2007 at 10:36:06PM +0000, Jon Burgess wrote:
>> On Wed, 2007-12-19 at 12:49 +0000, Tom Hughes wrote:
>>>> Jochen Topf wrote:
>>>>
>>>>> http://svn.openstreetmap.org/applications/rendering/mapnik/ 
>>>>> generate_tiles.py
>>>>> uses a call to the external 'convert' program to reduce the  
>>>>> number of colors
>>>>> for tiles rendered by Mapnik to 255. Since version r571 Mapnik  
>>>>> supports
>>>>> writing to 8 bit palette PNGs. Palette PNGs are generally  
>>>>> smaller than
>>>>> normal PNGs.
>>>>>
>>>>> Is there any reason NOT to change the code to use Mapniks  
>>>>> function to
>>>>> write out the image directly as 8bit paletted PNG, make the images
>>>>> smaller and save the call to 'convert'? (If nobody comes up with a
>>>>> reason, I'll change the code.)
>>>>
>>>> AFAIK, the main reason the feature was added to mapnik was that / 
>>>> we/
>>>> needed it because the external convert was really slow (about  
>>>> the same
>>>> amount of time as the whole rest of the render).
>>>
>>> The generate_tiles.py script is only an example - whilst changing it
>>> is probably a good idea I don't think it will have an affect on
>>> anything very much.
>>
>> Artem mentioned that the colour reduction technique is still fairly
>> experimental. It would be great for people to try it in order to iron
>> out any kinks before we adopt it on the main site.
>
> I tried it out and the png256 stuff in Mapnik doesn't do the right
> thing. You'll end up with tiles not fitting together because the  
> colors
> as slightly off. The change is large enough to see in some places.
>

Yes, I had the same experience. Not very often, but there'll be some  
tiles that don't match (background colour usually)

> Imagemagick convert seems to better with this. The algorithm it  
> uses is
> described on http://www.imagemagick.org/script/quantize.php . But I
> could imagine that there are pathological cases where it also breaks.
>

Yes, as with any quantization. AFAIK ImageMagick is using some kind  
of octree algorithms and so is Mapnik.
Thanks for the link and I'll check it out.

> I haven't looked into the algorithm that Mapnik uses, but maybe it can
> be improved by making sure that all colors mentioned in the Map file,
> i.e. all colors that we explicitly asked for, are retained. That way
> only the "artificial" colors created by the antialiasing will be  
> changed.
> This should make sure that tiles will always fit together because all
> the larger colored areas will use the same colors.

The above is pretty much what I'm thinking of trying. We can collect  
colours distribution from *.xml file.
It would easy for solid strokes and fills and not so easy for image  
based symbols, which might have thousands of colours.
I guess we can quickly quantize them as well. Also, we can just have  
a predefined set of colours, might work even better. There is  
probably some kind of cartographic rule - good map should have no  
more then 24 different prime colours or something.

Another thing I'd like to investigate is using different colour  
spaces. I had more correct (visually on macbook) palette while  
quantizing in YCbBr.

Anyways, could you send me those tiles, where colours don't much,  
please ? With original RGBA versions if possible.

Cheers
Artem

>
> Jochen
> -- 
> Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/   
> +49-721-388298
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev