[Tilecache] Where in TC code is metatile cutting?

[Roger André]

Ok, well after replicating the results Ivan got earlier, I'm not feeling as
confident as I once was.  As Ivan found, the problem is that the palette
information is being treated differently by PIL, than how MapServer
generated it.  Below are 2 short snippets that show this:

MapServer palette output:
-----------------
    0: 0,0,0,0
    1: 251,0,0,64
    2: 250,0,0,54
    3: 253,0,0,114

PIL output:
-----------
    0: 0,0,0,0
    1: 251,0,0,255
    2: 250,0,0,255
    3: 253,0,0,255

The PIL image was created using these commnds:
>>> import Image
>>> image = Image.open('quant_on_mapserv.png')
>>> assert image.mode == 'P'
>>> transparency = image.info['transparency']
>>> image.save('pil_test.png', transparency=transparency)

While the PIL-generated image looked just fine, all of the file size
benefits of using the "QUANTIZE=on" MapServer option were lost.  Athough a
single-band, paletted image was produced, it was just as big as a 4-band
RGBA image created directly in MapServer.

I still really don't like the idea of using a post-processing step to reduce
the size of cached images, so I think there are 2 possible ways to approach
the problem.  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.)  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.

Any thoughts on either of these options?

Roger
--



On Fri, Jan 15, 2010 at 10:59 AM, Roger André <randre at gmail.com> wrote:

> Ok, will let you know what I come up with. Am still testing the TC code to
> see what it actually does with PIL.  I'm not fully convinced that PIL cannot
> be made to correctly read the palette info of the incoming metatile.  It
> appears this has been explored already, but I need to convince myself
> first.  ;)
>  --
>
>
> On Thu, Jan 14, 2010 at 12:10 AM, Guillaume Sueur <
> no-reply at neogeo-online.net> wrote:
>
>> I've also pointed out previously that PIL is generated default jpeg
>> images, i.e. with 75 % compression. If the wms server itself sends 75%
>> compressed images, that can give pretty ugly images, and make people
>> wonder why the quality is different when using metatile or not. As this
>> should be avoided I've suggested to use a 95 % compression (100 %
>> doesn't even quantize, and produces fat images). Here is the diff on
>> Layer.py :
>>
>> 406a407,408
>>  >                 elif self.extension == 'jpeg':
>>  >                     subimage.save(
>>                        buffer,
>>                        self.extension,
>>                        quality=95,
>>                        optimize=True
>>                        )
>>
>> Regards,
>>
>> Guillaume
>>
>>
>> Le jeudi 14 janvier 2010 à 08:09 +0100, Ivan Mincik a écrit :
>> > On Thursday 14 January 2010, Roger André wrote:
>> > > Hi All,
>> > >
>> > > I'd like to take a stab at fixing the problem TileCache has with
>> cutting up
>> > > 8-bit quantized metatiles.  I'm trying to find where in the code PIL
>> is
>> > > invoked to do this, but can't seem to put my finger on it.  Can
>> someone
>> > > save me a bit of time and tell me where I can find this?
>> >
>> > Hi Roger,
>> > I am very happy that someone is trying to solve this (if we mean the
>> same problem). I have spend lot of time trying to
>> > fix this. By my opinion, it is PIL issue which can not be done without
>> hacking PIL code.  You can find my post in PIL
>> > mailinglist - with no help, but I am not very skilled programmer, more
>> GIS person, so maybe You can make it easily.
>> >
>> > Here You can find my ticket with all info, code sample and test file.
>> >
>> http://hg.effbot.org/pil-2009-raclette/issue/8/corrupting-images-in-palette-mode
>> >
>> > Good luck and give us know about Your progress, even if not successfull.
>> > _______________________________________________
>> > Tilecache mailing list
>> > Tilecache at openlayers.org
>> > http://openlayers.org/mailman/listinfo/tilecache
>>
>>
>> _______________________________________________
>> Tilecache mailing list
>> Tilecache at openlayers.org
>> http://openlayers.org/mailman/listinfo/tilecache
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/tilecache/attachments/20100116/e4e7e86e/attachment.html