|
From: Kevin S. <ks...@bo...> - 2014-01-02 21:14:20
|
Sorry about the delay in responding due to the holidays. I got this working via the external PNGCrush method before the holidays. For now it's an all or nothing thing the applies to all of the layers if it's used (although non-png images are ignored). It's turned on by specifying the path to the PNGCrush executable with a system property (or env var, or context param) and the command line options can be specified with another such variable. Responsibility for applying the filters lies with the TileLayer, which currently just grabs them from the context and applies them to the resource before handing it off to the StorageBroker. Making resource filters configurable on a per layer basis should therefore be reasonably easy to do in future and mostly a matter of making them play nicely with XStream. I've tested on Linux and Windows, in Jetty and Tomcat. On 21 December 2013 02:59, Andrea Aime <and...@ge...> wrote: > On Sat, Dec 21, 2013 at 1:57 AM, Gabriel Roldan <gr...@bo...>wrote: > >> Sometime at some place, not too long ago, I'm pretty sure I commented on >> this regard mentioning Andre Aime's png 8 encoder, though I don't seem able >> to find that comment anywhere now. >> > > There was something here: > > http://osgeo-org.1560.x6.nabble.com/Presenting-new-work-on-PNG8-quantization-with-alpha-channel-td3819239.html > > >> >> I _think_ if the only thing you're looking for is reduced bandwidth that >> could be a much easier to adopt solution, even if it doesn't provide all >> the pngcrush capabilities. >> >> Here's some context: < >> http://osgeo-org.1560.x6.nabble.com/semi-transparent-png8-images-td3820185.html >> > >> <https://github.com/GeoWebCache/geowebcache/issues/48> >> >> And the actual thing: < >> http://geo-solutions.blogspot.com.ar/2012/05/developers-corner-geoserver-stunning.html >> > >> > > I believe you can get close to pngcrush results by: > * using the GeoServer quantizer, which will give you a nice palette with > alpha (it's the one described above, see the png outputformat) > * make sure you're using the JDK PNG encoder, which is dead slow exactly > because it tries the hardest to generate a maximum > compression PNG > > The latter probably requires a bit of explanation, making a small PNG is > not all about using a palette, each row in the image can > use a few different filtering tecniques before going into the zlib > encoding, and they can differ row by row, > the JDK one tries all possible filterings and chooses the best one, > spending a ton of time doing so, > and then setting the zlib compression to maximum compression. > > You get an extra 10-20% compression rate for a similar extra amount of > effort (for indexed images the JDK encoder is not > that bad, it's a real disaster for RGB ones instead).... I believe that if > you use PNGJ and tilt the zlib compression to the > max you'll also get the extra compression, but I haven't tried. > > Cheers > Andrea > > -- > *== GeoSolutions will be closed for seasonal holidays from 23/12/2013 to > 06/01/2014 ==* > > Ing. Andrea Aime > @geowolf > Technical Lead > > GeoSolutions S.A.S. > Via Poggio alle Viti 1187 > 55054 Massarosa (LU) > Italy > phone: +39 0584 962313 > fax: +39 0584 1660272 > mob: +39 339 8844549 > > http://www.geo-solutions.it > http://twitter.com/geosolutions_it > > ------------------------------------------------------- > -- Kevin Smith Junior Software Engineer | Boundless ks...@bo... +1-778-785-7459 @boundlessgeo <https://twitter.com/boundlessgeo> |