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 [EMAIL PROTECTED] http://www.remote.org/jochen/ > +49-721-388298 > > > _______________________________________________ > dev mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
