[mapserver-dev] Optimized JPEG output

[Even Rouault]

Le vendredi 26 décembre 2014 17:17:00, Lime, Steve D (MNIT) a écrit :
> Hi Even: Gotta love presents! ~10% is pretty significant space/bandwidth
> savings so IMHO I think your pull request should be merged "as is" with
> the optimization on by default. So a +1 from me...
> 
> Thanks for the clear and thorough explanation of the change!

I've just merged the change. I'd encourage folks that use mapserver in 
performance intensive environments to keep an eye open on if/how it impacts 
performance.

> 
> Steve
> 
> -----Original Message-----
> From: mapserver-dev-bounces at lists.osgeo.org
> [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Even Rouault
> Sent: Thursday, December 25, 2014 10:14 AM
> To: mapserver-dev at lists.osgeo.org
> Subject: [mapserver-dev] Optimized JPEG output
> 
> Hi,
> 
> Father Christmas/Santa Clauss brought enhancements in JPEG output.
> 
> Digging around that topic recently in GDAL, I've looked in MapServer too
> and saw that JPEG output uses standard Huffman tables instead of optimized
> Huffman coding. Optimized Huffman coding actually looks at the symbols to
> be emitted to build the most efficient Huffman coding to generate the
> smallest possible output. For exactly the same quality (Huffman is the
> lossless compression stage of JPEG compression), output can be a few
> percent smaller with optimized Huffman coding (I've got 11% improvement on
> a BMNG tile with JPEG-compressed TIFF) . Enabling it is just a matter of
> adding "cinfo.optimize_coding = TRUE;". The output is just a standard
> baseline JPEG, so that doesn't affect compatibility. At the time libjpeg6b
> was developed, this feature wasn't enabled by default because it requires
> a full pass on the output to generate statistics of the frequency of each
> symbol, which has some cost. This was 15 years ago. Computers have changed
> a lot since then and optimized coding should be pretty much inexpensive
> nowadays (I haven't benchmarked extensively, but for typical 256x256
> tiles, I can't really notice any time difference.) Hence
> https://github.com/mapserver/mapserver/pull/5056 that proposes to enable
> it by default :
> 
> """
> Add OPTIMIZED=YES/NO/ARITHMETIC (default YES) format option to turn on
> optimized Huffman coding. If set to NO, use standard Huffman tables (a
> little bit faster in theory, but less efficient for output size). If set
> to ARITHMETIC, will use Arithmetic entropy coding instead of Huffman, for
> smaller size. Note that Arithmetic coding/decoding is available in
> libjpeg-turbo implementation, but not in IJG libjpeg-6b or later. So must
> only be used in combinations with clients that are known to be able to
> decode Arithmetic encoded JPEG. """
> 
> Any thoughts about merging that into master ?
> 
> Even
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com
> _______________________________________________ mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com