[mapserver-users] Quantize and 8bit/1bit PNG problem

[paalkr]

Hi Frank!

Thanks for the comment! The idea of using Bing Maps and Silverlight was not
mine, I argued quite heavily against it :) The bug is in fact in Sliverlight
and Microsoft has admitted it, but they don't wont to fix it, go figure! I
understand that a 1bit image is a total valid output and I personally don't
have any trouble with it. The request to the list was more like a
documentation thing from my side, so that the Microsoft fanboys can see for
them selves that the problem should be fixed in the broken software (Bing
Maps and Silverlight), not vice versa.

I guess that the best workaround is the suggested python mapscript wrapper,
and check if the output is 1bit or not, if true then change it with a 8bits
image instead. But I'm not totally sure that I really wont to fix this on
the service side anyway ;)



Frank Warmerdam wrote:
> 
> paalkr wrote:
>> Hi!
>> 
>> Could I please ask for a comment on this issue from one of the
>> developers?
> 
> Pål,
> 
> One bit PNGs are a perfectly valid response.   I would suggest
> two approaches.
> 
> 1) File a ticket with Microsoft on Bing Maps, and hopefully they will
> roll a fix into their operational build within a couple days.  (ha ha)
> 
> 2) Manually produce a nice empty tile that works with Bing Maps some
> other way, and write a script to replace the 1bit PNG file (which should
> presumably have a fixed size) with the bing-safe ones.
> 
> Perhaps not the sort of answer you were hoping for, but you did
> implore us for comment even when none of us thought we had anything
> particularly bright to say.
> 
> Best regards,
> 
>> paalkr wrote:
>>> Hi!
>>>
>>> I have the following output format defined in my mapfile (MapServer
>>> 5.4.2):
>>>
>>>    OUTPUTFORMAT
>>>       NAME "png8bit"
>>>       DRIVER "AGG/PNG"
>>>       MIMETYPE "image/png"
>>>       EXTENSION "png"
>>>       FORMATOPTION "QUANTIZE_FORCE=ON"
>>>       FORMATOPTION "QUANTIZE_COLORS=256"
>>>       FORMATOPTION "QUANTIZE_NEW=ON"
>>>       FORMATOPTION INTERLACE=OFF
>>>    END
>>>
>>> This works very well most of the time, even transparency. But in
>>> situations where the GetMap request don't contain any data at all
>>> (returned image should be total transparent) the resulting PNG is 1bit
>>> in
>>> stead of 8bits. If the produced image does contain some data the
>>> produced
>>> image i 8bits, with correctly rendered transparency where there are no
>>> data.
>>>
>>> This behavior are specially troublesome when building a tile cache
>>> because
>>> there are a lot of this request without any valid data. In almost all
>>> applications I guess that this issue wouldn't do any harm, but we uses
>>> Bing Maps for some projects and Bing Maps can't handle 1bit PNGs.
>>>
>>> What can be done to overcome this issue? 
> 
> 
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
> 
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
> 
> 


-----

Regards,
Pål Kristensen
-- 
View this message in context: http://n2.nabble.com/Quantize-and-8bit-1bit-PNG-problem-tp3641221p3935009.html
Sent from the Mapserver - User mailing list archive at Nabble.com.