[Tilecache] Where in TC code is metatile cutting?

[Simon Mercier]

Roger

I share your point.  I tried many times to build a nice and compress 8 bits
png and still no result.  So I add a post-processing in the TileCache v2.0
for each ouput cache tile with ImageMagick binary process.  To active it, I
add option in tilecache.cfg Compress=true.  It work fine but it take much
more time to seed my cache.  I still believe it's pach and hope a PIL option
to compress image output...

best regard
Simon Mercier

2010/1/16 Roger André <randre at gmail.com>

> 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
>>>
>>
>>
>
> _______________________________________________
> 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/20100117/31f20924/attachment.html