Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Ricky_Wang
Beginner
76 Views

Problem of Huffman algorithm in IPP6.1

Jump to solution
Hi,
We are using IPP6.1 in our product, when I was evaluating the algorithms in IPP6.1, I ran into a problem.
See the below code, whereEncodeHuffman andDecodeHuffman are from IPP6.1 samples(ipp-samples\\data-compression\\ipp_compress):http://registrationcenter.intel.com/irc_nas/1910/w_ipp-samples_p_6.1.6.065.zip

I have narrowed down the problem down to the below simple code, and I carefully debugged the code to prevent misusage and silly mistakens.
would you please take a look?
Thanks a lot.
Ricky
code segament below.
_______________________________________________________________________
//the following code encodes 11-byte long buffer using Huffman,
//then decode the encoded-buffer,
//but the result is 12-byte long
//I am using Visual Studio 2008 with SP1
int stateSize;
ippsHuffGetSize_8u(&stateSize);
IppHuffState_8u* pHuffState = (IppHuffState_8u*)ippsMalloc_8u(stateSize);
// the 11-byte long source buffer
BYTE src[] = {0xff, 0x00, 0x00, 0xfc, 0x01, 0x00, 0x00, 0xff, 0x00, 0x00, 0xfb};
BYTE dst[256];
BYTE decode[256];
int dstlen = sizeof(dst);
int dstlen2;
int ret = EncodeHuffman( src, sizeof(src), dst, &dstlen, pHuffState ) ;
dstlen2 = sizeof(decode);
ret = DecodeHuffman( dst, dstlen, decode, &dstlen2, pHuffState ) ;
if( dstlen2 != sizeof(src) || memcmp(decode, src, sizeof(src)))
{// the result decoded-buffer is 12-byte long:
//{0xff, 0x00, 0x00, 0xfc, 0x01, 0x00, 0x00, 0xff, 0x00, 0x00, 0xfb, 0xFF}, one extra 0xFF added.
printf("failed\\n");
}
//Clean up code below
0 Kudos
1 Solution
Chao_Y_Intel
Employee
76 Views

Hi Ricky,

The EncodeHuffman() function actually doesnt write any stop symbol in the end of encoded stream and, as the result, this stream contains a garbage in the end. The decode function couldnt detect the end of input stream and decodes this garbage. Actually, such could be used with another approach an user should store the encoded elements number and set such number as destination size. You can see it at ipp_compress sample where such approach is used.

Also our function owner had a bit change on huffman.c file(from ipp_compress sample) for your approach, and you can find full functional example in the attached file.

Thanks,
Chao

View solution in original post

4 Replies
Chao_Y_Intel
Employee
76 Views

Ricky,

Have you checked the latest 7.04 release? Several issues were fixed for data compression functions in 7.0 release. The new package also can be downloaded in registraction center: http://registrationcenter.intel.com

Thanks,
Chao
Ricky_Wang
Beginner
76 Views
Hi Chao,
Thanks for your response.
I didn't test this problem with IPP7 yet.
We knew from Intel that IPP7 does NOT support some legacy CPU models, so we'd like to use IPP6.1 in our product to make customers happy.
Would you please to investigate further? If it's a bug of IPP6.1, it will be a good reason for our management team to make the decision to adopt IPP7.
Regards,
Ricky
Chao_Y_Intel
Employee
77 Views

Hi Ricky,

The EncodeHuffman() function actually doesnt write any stop symbol in the end of encoded stream and, as the result, this stream contains a garbage in the end. The decode function couldnt detect the end of input stream and decodes this garbage. Actually, such could be used with another approach an user should store the encoded elements number and set such number as destination size. You can see it at ipp_compress sample where such approach is used.

Also our function owner had a bit change on huffman.c file(from ipp_compress sample) for your approach, and you can find full functional example in the attached file.

Thanks,
Chao

View solution in original post

Ricky_Wang
Beginner
76 Views
This workaround works. The samples need upgrade.
Thanks,
Reply