Intel IPP Jpeg library support

[pramsey]

The IPP performance library includes a libjpeg JPEG implementation. However, it has one behavioral difference to the IJG implementation (that we found) and that is, it only partially empties/fills in the input/output buffers while encoding/decoding. That means that libraries with their own implementations of the fill_buffer/empty_buffer function will produce corrupt data.

[pramsey]

Patch to remove corruption when compiling against Intel IPP

[Even Rouault]

Paul,

I see your patch includes a patch to libtiff itself and a patch to GDAL. You should submit that part to libtiff's bugzilla (updated against the cvs head) : ​http://bugzilla.maptools.org, as GDAL has the policy of only "refreshing" its internal libtiff from upstream libtiff.

And for that GDAL part, ideally it would be good to update your patch against trunk version instead of 1.5.X.

Otherwise both patches look easy to integrate thanks to the #ifdef protection. I've got the feeling that at least the libtiff patch wouldn't require that #ifdef protection and could be generic. But maybe my feeling is wrong... Is it really necessary ? Did you test it against the IJG implementation ?

[warmerdam]

I'll take care of integrating into libtiff based on this ticket, and I think the patch is adequate for my needs.

[warmerdam]

Reviewing the vsiodataio.cpp changes for the jpeg driver I had hoped that we could just always use the IPP case. However, I've determined that it requires the state->bytes_in_buffer field to be accurate when the fill function is called. But the normal libjpeg's jdhuff.c / jpeg_fill_bit_buffer() function does *not* set this properly.

I'm going to review what is involved in making the generic libjpeg properly managed the buffers...

[warmerdam]

I have determined that libjpeg can be made safe with the ipp patches by applied the changes shown in r15507 (trunk). Really though they need to be applied to freestanding libjpeg 6b builds that are intended to be replacable with the IPP libjpeg.

tif_jpeg.c file as ​http://bugzilla.maptools.org/show_bug.cgi?id=1951 and applied in libtiff head.

General discussion of the IPP issue added to GDAL trac wiki as:

http://trac.osgeo.org/gdal/wiki/JpegIPP

[warmerdam]

libtiff changes applied in gdal trunk (r15509). JPEG driver changes applied in trunk (r15508).

Note, IPPJ_HUFF must be defined manually (for instance in GDALmake.opt.in) to enable IPP libjpeg compatability.

[warmerdam]

Patches applied, tested in OSGeo4W. I don't believe there is any further change required in GDAL (except possible to provide a more organized way of enabling the IPPJ_HUFF macro).

[warmerdam]

An additional problem was found in libjpeg, simmilar to that requiring r15508, and the problem was corrected in trunk (r16363). See #2845 for specific details.

[Even Rouault]

Everything needed to use JpegIPP is mentionned in the trac page. Closing