Building to use Intel IPP libjpeg

Objective

Intel produces a custom optimized version of libjpeg which takes advantage of various particular chip features of some intel chips for faster access.

The Dilemma

However, there are a few tricky aspects to using it as a drop in replacement for normal libjpeg "6b" builds. In particular in non-progressive mode the IPP libjpeg does not always fully fill or drain the io buffers while the generic libjpeg does. This causes problems for application level code (normally io redirection code) that assumes the libjpeg 6b behavior.

The solutions

The work around is to patch the libjpeg interfaces in places like the GDAL jpeg driver, and the GDAL GTiff driver (for jpeg compressed tiff).

Unfortunately, the patch turns out not to be compatible with libjpeg 6b, which does not properly set some state information before calling the flush/fill functions. This puts us in a situation where it is nearly impossible to have a version of GDAL that works with either the IPP or non IPP versions of libjpeg without recompiling. However, if we also fix libjpeg 6b to properly set the state information as shown in r15507 then the other patches are safe. Note that r15507 should not break any application using libjpeg. So it is safe to apply to libjpeg 6b regardless of who is using it.

How this plays out in OSGeo4W

We need to:

• Rebuild the libjpeg package (6b) with r15507.
• We need to rebuild GDAL with the IPP support in the GTiff and JPEG (r15508) drivers enabled.
• We need to create a libjpeg-ipp package for OSGeo4W that replaces the standard jpeg_osgeo.dll.
• We need to rebuild MapServer with an adjusted GD (is this right?)