[mapserver-dev] png optimization on output

[Lime, Steve D (DNR)]

I believe so. Thomas was already using libpng directly under certain circumstances. I suppose we could make the decision to write directly through those libs and use GD for GIF only.

Steve

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: Wednesday, February 17, 2010 9:54 AM
To: thomas bonfort
Cc: mapserver-dev
Subject: Re: [mapserver-dev] png optimization on output

I've been looking at the image writing code, and to an extent it seems
well-hidden behind libgd. Do we have the option of writing directly
through libpng/libjpeg?

On Wed, Feb 17, 2010 at 1:23 AM, thomas bonfort
<thomas.bonfort at gmail.com> wrote:
> +1 for this functionality
> libpng supports different levels of compression, so it might be nice
> to expose those to the formatoption values instead of just TRUE/FALSE
>
> --
> thomas
>
> On Tue, Feb 9, 2010 at 22:43, Stephen Woodbridge
> <woodbri at swoodbridge.com> wrote:
>> Thomas, Steve L, Assefa,
>>
>> Do we have an option to optimize png images for size on output?
>> I'm using an output format like:
>>
>>  OUTPUTFORMAT
>>    NAME "agg_qn"
>>    DRIVER "AGG/PNG"
>>    EXTENSION "png"
>>    MIMETYPE "image/png"
>>    IMAGEMODE RGB
>>    FORMATOPTION "INTERLACE=false"
>>    FORMATOPTION "QUANTIZE_NEW=ON"
>>    FORMATOPTION "QUANTIZE_DITHER=OFF"
>>    FORMATOPTION "QUANTIZE_COLORS=256"
>>  END
>>
>> If Iuse pngcrush -reduce on the resulting file I get about 25%  reduction in
>> size. it seems like it might be worthwhile to add code that does the same
>> sort of thing maybe triggered by something like:
>>
>>    FORMATOPTION "REDUCE=true"
>>
>> I realize that this is costs additional time, but when using mapserver with
>> something like Assefa's tilecache patch where you are actually drawing
>> metatiles and chopping them into a cache, the trade off between time and
>> size can be justified.
>>
>> I can write up a bug if people think this would be a good option.
>>
>> Thanks,
>>  -Steve W
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-dev