Re: [Geowebcache-devel] Storage Filter

[Kevin S. <ks...@bo...>]

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>