[Tilecache] Fwd: Where in TC code is metatile cutting?

[Ivan Mincik]

Hi Roger, it is bad news that You confirmed my investigation.

> I still really don't like the idea of using a post-processing step to reduce
> the size of cached images

So do I.

> One is to not care at all about what format is being sent into
> TileCache, but to implement quantizing in PIL itself, maybe as a
> tilecache.cfg option.  (Note that I wasn't able to get quantizing to reduce
> image size in PIL, so maybe this isn't even possible.)

I spend lot of time playing with PIL, compiling latest versions and
testing. I think, it can not be done using current versions of PIL and
some hacking of PIL code is needed.
To implement this feature in PIL is far the best way to go. Please, if
somebody feels capable to do it, my company can make sponsorship of
this (contact me directly by email, or just post in this mailinglist)

>  The other option is
> to have the binary string of image data read and processed by something
> other than PIL, something that can correctly replicate the image format
> MapServer produces.  Initially I was thinking that GDAL could possibly do
> this.

You can use ImageMagick which has also python bindings, but as far as
I know, there are some problems with code maintenance of
ImageMagick-python. Having two different software packages for image
processing can be nasty, working hack, but not a good way to go.

Experimentally, I was trying to send RGBA images from Mapserver to
TileCache and implement 'pngnq' processing as the last step before
saving to disk. The resulting images where quite good in terms of size
and quality, but  'pngnq' processing is huge performace hit.

> Any thoughts on either of these options?

Can we look for somebody capable to hack PIL code little bit ?

Ivan