Opened 16 years ago

Closed 13 years ago

#2606 closed enhancement (fixed)

Intel IPP Jpeg library support

Reported by: pramsey Owned by: warmerdam
Priority: high Milestone:
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: jpeg libtiff


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.

Attachments (1)

gdal-ipp.patch (4.6 KB ) - added by pramsey 16 years ago.
Patch to remove corruption when compiling against Intel IPP

Download all attachments as: .zip

Change History (9)

by pramsey, 16 years ago

Attachment: gdal-ipp.patch added

Patch to remove corruption when compiling against Intel IPP

comment:1 by Even Rouault, 16 years ago


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) :, 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 ?

comment:2 by warmerdam, 16 years ago

Component: defaultGDAL_Raster
Keywords: jpeg libtiff added
Priority: normalhigh
Status: newassigned

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

comment:3 by warmerdam, 16 years ago

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...

comment:4 by warmerdam, 16 years ago

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 and applied in libtiff head.

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

comment:5 by warmerdam, 16 years ago

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

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

comment:6 by warmerdam, 16 years ago

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).

comment:7 by warmerdam, 15 years ago

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.

comment:8 by Even Rouault, 13 years ago

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.