Open smithkm opened 10 years ago
Bandwith may be, but storage wise I doubt it'll be as much worth it. As much as pngcrush reduces the file size it'll still span to whole file system blocks (i.e. the actual on disk storage size will be a multiple of the disk block size, which is usually 4 or 16 KB). My concern is whether the benefits would justify the extra complexity, which I feel it wouldn't. Instead, I would check whether its easier to use optimized, translucent png8 images using @aaime 's png encoder http://osgeo-org.1560.x6.nabble.com/png8-alpha-support-landed-on-trunk-td4900685.html
For the S3 BlobStore PNG crush will make a difference because storage there is not block aligned and costs quickly add up. Every byte gained makes a difference.
The implementation I worked on but ended up having to abandon was based on making the particular operation used to filter the tiles extensible. It would require some modification to handle changes in the format (RGB PNG to Indexed PNG) since that's part of the definition of the layer.
I am happy to help out. I think with datasets getting larger storage and over wire download optimisation is necessary. Hope the code is languishing in a branch I can pick up from. On 25 Jun 2016 7:35 am, "Kevin Smith" notifications@github.com wrote:
The implementation I worked on but ended up having to abandon was based on making the particular operation used to filter the tiles extensible. It would require some modification to handle changes in the format (RGB PNG to Indexed PNG) since that's part of the definition of the layer.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/GeoWebCache/geowebcache/issues/212#issuecomment-228473630, or mute the thread https://github.com/notifications/unsubscribe/AAd_hN38gwJi3xSDXrDDeDG3C-v40BE3ks5qPFSUgaJpZM4BSMHz .
A mechanism to apply PNGCrush to cached tiles would help reduce storage and bandwidth usage.