Running pnqnq on the whole tileset doesn't make much sense. What pngnq do is find most commonly used colors and build palette of them. If you run pngnq on the whole tileset, then there will be more colors and selected colors will be less optimal. It would be much faster then to simply make some good palette and apply it every tile, no matter what colors the tile use.
Btw. If you are worried about I/O and have enough memory (3GB is more than enough when you use batik), then you can set [EMAIL PROTECTED] working directory to be on ramdisc. I have /tmp on ramdisc and it's considerably faster. On Tue, Sep 9, 2008 at 8:08 PM, Christian Ehrlicher <[EMAIL PROTECTED]> wrote: > Henrik Niehaus schrieb: >> Good point! Crunching before splitting should save a lot of I/O and >> process management overhead. The question is, if the speedup is worth >> the effort?!? >> > pngnq needs > 90% for calculating a (for me, I don't know anything about > the algorithm) strange value. The other 10% are needed to do the acutal > work. So we would gain much when this calculation is only needed once > instead for every splitted tile. > > Any hints where the splitting is done in the source code so maybe > someone with to much time can take a look? > > > > Christian > > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome > _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
