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:<br>
<br>MapServer palette output:<br>-----------------<br> 0: 0,0,0,0<br> 1: 251,0,0,64<br> 2: 250,0,0,54<br> 3: 253,0,0,114<br><br>PIL output:<br>-----------<br> 0: 0,0,0,0<br> 1: 251,0,0,255<br> 2: 250,0,0,255<br>
3: 253,0,0,255<br><br>The PIL image was created using these commnds:<br>>>> import Image<br>>>> image = Image.open('quant_on_mapserv.png')<br>>>> assert image.mode == 'P'<br>
>>> transparency = <a href="http://image.info">image.info</a>['transparency']<br>>>> image.save('pil_test.png', transparency=transparency)<br><br>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.<br>
<br>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.<br>
<br>Any thoughts on either of these options?<br><br>Roger<br>--<br>
<br><br><br><div class="gmail_quote">On Fri, Jan 15, 2010 at 10:59 AM, Roger André <span dir="ltr"><<a href="mailto:randre@gmail.com" target="_blank">randre@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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. ;)<br>
<font color="#888888">
--</font><div><div></div><div><br><br><div class="gmail_quote">On Thu, Jan 14, 2010 at 12:10 AM, Guillaume Sueur <span dir="ltr"><<a href="mailto:no-reply@neogeo-online.net" target="_blank">no-reply@neogeo-online.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've also pointed out previously that PIL is generated default jpeg<br>
images, i.e. with 75 % compression. If the wms server itself sends 75%<br>
compressed images, that can give pretty ugly images, and make people<br>
wonder why the quality is different when using metatile or not. As this<br>
should be avoided I've suggested to use a 95 % compression (100 %<br>
doesn't even quantize, and produces fat images). Here is the diff on<br>
Layer.py :<br>
<br>
406a407,408<br>
> elif self.extension == 'jpeg':<br>
> subimage.save(<br>
buffer,<br>
self.extension,<br>
quality=95,<br>
optimize=True<br>
)<br>
<br>
Regards,<br>
<br>
Guillaume<br>
<br>
<br>
Le jeudi 14 janvier 2010 à 08:09 +0100, Ivan Mincik a écrit :<br>
<div><div></div><div>> On Thursday 14 January 2010, Roger André wrote:<br>
> > Hi All,<br>
> ><br>
> > I'd like to take a stab at fixing the problem TileCache has with cutting up<br>
> > 8-bit quantized metatiles. I'm trying to find where in the code PIL is<br>
> > invoked to do this, but can't seem to put my finger on it. Can someone<br>
> > save me a bit of time and tell me where I can find this?<br>
><br>
> Hi Roger,<br>
> 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<br>
> 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<br>
> mailinglist - with no help, but I am not very skilled programmer, more GIS person, so maybe You can make it easily.<br>
><br>
> Here You can find my ticket with all info, code sample and test file.<br>
> <a href="http://hg.effbot.org/pil-2009-raclette/issue/8/corrupting-images-in-palette-mode" target="_blank">http://hg.effbot.org/pil-2009-raclette/issue/8/corrupting-images-in-palette-mode</a><br>
><br>
> Good luck and give us know about Your progress, even if not successfull.<br>
</div></div><div><div></div><div>> _______________________________________________<br>
> Tilecache mailing list<br>
> <a href="mailto:Tilecache@openlayers.org" target="_blank">Tilecache@openlayers.org</a><br>
> <a href="http://openlayers.org/mailman/listinfo/tilecache" target="_blank">http://openlayers.org/mailman/listinfo/tilecache</a><br>
<br>
<br>
_______________________________________________<br>
Tilecache mailing list<br>
<a href="mailto:Tilecache@openlayers.org" target="_blank">Tilecache@openlayers.org</a><br>
<a href="http://openlayers.org/mailman/listinfo/tilecache" target="_blank">http://openlayers.org/mailman/listinfo/tilecache</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>