[mapserver-dev] Optimized JPEG output

[Lime, Steve D (MNIT)]

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!

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