Our windows application uses libpng to decode PNG files, libpng in turn uses zlib library for decoding. Currently we are evaluating the IPP library to test if there will be any speed improvements. So I have downloaded your 5.3 IPP_ZLIB sample and replaced our original zlib with the optimized one and it seems to be failing on decoding. libpng retuns "Not enough image data" error. Further brief investigation showed that there is an issue with the inflate() function in zlib. Project was compiled on VS 2005 without openmp flag.
Unfortunately I haven't done any deep investigation, maybe somebody have expirienced the same issue and have a solution?
Thank you for your response. Basically, I use an example provided with the libpng library, with one exception:
[cpp]png_transforms = PNG_TRANSFORM_BGR | PNG_TRANSFORM_STRIP_16 | PNG_TRANSFORM_EXPAND; png_read_png(png_ptr, info_ptr, png_transforms, png_voidp_NULL);[/cpp]
There is another thing, I use custom reader, which basically reads the image from memory and it works with non-optimized zlib, so it's not the issue.
I also attached an image which failed the decoding.
I was using IPP 5.3 update 4 (to be exact "w_ipp_ia32_p_5.3.4.087.exe"). Anyway I will try out the new IPP 6.0 version and check if it solves my problem.
The newly released IPP Zlib (188.8.131.52) is much better than the previous one (184.108.40.206), but still has serious bugs. For example, the Lines from 769 to 771:
s->in_tmpbuff_next = pSrc;
s->in_tmpbuff_rem = ((ippflush != IppLZ77FinishFlush)? s->in_tmpbuff_avail : 0) + srcLen;
s->in_tmpbuff_avail = chslen;
should be replaced by:
zmemcpy_ipp(s->in_tmpbuff_ptr, pSrc, srcLen);
s->in_tmpbuff_next = s->in_tmpbuff_ptr + srcLen;
s->in_tmpbuff_rem = srcLen;
s->in_tmpbuff_avail = s->in_tmpbuff_size - srcLen;
Please let me know if I am wrong.
Hi! If you have sample data where the code fails, please provide us with this.
Regarding this particular piece, I would doubt.
First, we don't need to copy user's buffer to temporary storage, because it has been already done in lines 728-738. Then, temporary buffer pointers are increased by number of chars really processed by ippsEncodeLZ77_8u function (line 748). Only these chars will be flushed out if ippsEncodeLZ77SelectHuffMode function will choose "stored block" as the best compression method.
Anyway, many thanks for your observations, it helps us stay slim.
Note, that in future releases of IPP ZLIB sample this code will be removed, since the ZLIB functions of IPP Data Compression will be changed and therefore ZLIB sample will be changed too. Thus, ZLIB will stay original with only few lines changed. It is planned for IPP 6.1 Beta release.
In order to pin down the problem, please, try "deflate.c" from IPP 5.3 (attached). If you problem will have gone, the origin is definitely in "estimate" functionalityof IPP sample. We'll be thinking of what can be done. Though, cannot promise the solution, since IPP zlib sampleis totally redesigned (i.e. is returned back to its roots) in upcoming IPP 6.1 release. It's not worth spending resources on the solution.
You don't need to call "Init" after "Reset". After resetting LZ77 structure is usable with no additional efforts. As long as you aren't planning to change important things as compression level or checksum computing method. For that you need either another structure or re-initialize the old.
Regarding "I am in the process to re-write IPP Zlib by myself...". IPP ZLIB functions are redesigned so, that almost no changes will require to be done over original ZLIB code. So, if you are going to use IPP ZLIB functions, you'd better implement your application to work with original ZLIB. Then "couple lines out/couple lines in" and your application works with IPP ZLIB.