Opened 13 years ago

Closed 10 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
Cc:

Description

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 13 years ago.
Patch to remove corruption when compiling against Intel IPP

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by pramsey

Attachment: gdal-ipp.patch added

Patch to remove corruption when compiling against Intel IPP

comment:1 Changed 13 years ago by 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 ?

comment:2 Changed 13 years ago by warmerdam

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 Changed 13 years ago by 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...

comment:4 Changed 13 years ago by 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

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by 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).

comment:7 Changed 13 years ago by 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.

comment:8 Changed 10 years ago by Even Rouault

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.