Simone Giannecchini ha scritto: > been there than that :-) > > The algorithm we use is a (super) optimized version of the octtree > algorithm. Notice this sentence in the documents pointed out in the > blog post: > "The quantizer is fairly slow compared to median cut or octree methods". > NeuQuant gives good quality but if you want to use it in place like we > do (the guy is doing offline preprocessing) ou'd give up a lot in > terms of speed. > > I should still have around the speed tests I had made with the various > algorithms, I could put them somewhere (I have a blog as well! :-) ). > Anyway, there are others novel algorithms that we could try and > implement but I wonder if ATM it is worth the effort, I think there > are many other things that we could optimize with a similar effort. > Mmmmmmhhh, probably topic for an intern.
I agree that for the use case of online data serving having a slow encoder is not the best option. Yet, for a tile cached set, provided you have enough processing power to handle either the pre-seeding or the on line tile generation, it makes sense to offset lower performance for good quality, as the cost of producing the tiles becomes a one time only one. Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
