Thank you for using Intel® software development tools. We are committed to making the best possible software and platforms to meet your development needs. Your personal experience with our products is extremely valuable to us and we want to know how we can do better.
Intel® IPP 2017 is now available. This release added new Platform-Aware APIs to support 64-bit parameters for image dimensions and vector length, significantly improved performance of zlib compression functions, and extended optimization for different platforms.
What's New in Intel® IPP 2017:
Added Intel® IPP Platform-Aware APIs to support 64-bit parameters for image dimensions and vector length on 64-bit platforms and 64-bit operating systems:
In the headers and documentation for ippiRGBToHLS (both for ipp v9 and v2017) the following pseudo-code is given
if R = M2 then H = Cb - Cg
if G = M2 then H = 2 + Cr - Cb
if B = M2 then H = 4 + Cg - Cr
Procedural Elements for Computer Graphics
However, in that book (2nd ed. 1998) on page 629 I read
if R = M1 then H = Cb - Cg
if G = M1 then H = 2 + Cr - Cb
if B = M1 then H = 4 + Cg - Cr
NOTE: Defects and feature requests described below represent specific issues with specific test cases. It is difficult to succinctly describe an issue and how it impacted the specific test case. Some of the issues listed may impact multiple architectures, operating systems, and/or languages. If you have any questions about the issues discussed in this report, please post on the user forums, http://software.intel.com/en-us/forums or submit an issue to Intel® Premier Support, https://premier.intel.com.
Intel® IPP 2017 (6 Sep 2016)
As the doc says(https://software.intel.com/en-us/node/502043),ippsCopyLE_1u and ippsCopyBE is diffierent.
do a small test used IPP2017
Ipp8u a = 1;// 00000001 high bit->low bit
Ipp8u aBE = 0, aLE = 0;
ippsCopyBE_1u(&a, 0, &aBE, 0, 8);
ippsCopyLE_1u(&a, 0, &aLE, 0, 8);
The result is aBE=1,aLE=1
Should aLE be 128? // 10000000 high bit->low bit
As part of our IPP 9 upgrade, we are transitioning from ippiErode_8u_C1R to ippiErodeBorder_8u_C1R. I see significant performance regression (glnxa64, avx2) with this transition.
I have attached some whittled down standalone repro steps for 8.1 and 9.0.1 on glnxa64 platform. 8.1 takes 0.33ms (fastest from multiple runs) and 9.0.1 takes 4.66 ms (fastest time from multiple runs). While this is for 640x480 images, I notice this pattern for a full range of images from 10x10 to 2kx2k and higher.
Hi I used ippiInpaint_8u_C3R with IPP_INPAINT_TELEA flag and the result has a bug:
Input image contains Scalar=(77,88,99) and the 3X3 "dirt" has the scalar (33,17,2).
After using ippiInpaint_8u_C3R with IPP_INPAINT_TELEA flag,
the "clean" result has the scalar (77,77,77) instead of (77,88,99).
When using it with IPP_INPAINT_NS it works fine.
See the code below:
My company still used old IPL (IPL_DEPTH_1U functions) , and let me change IPL 1bit function to IPP for build x64 software.
After used ippiBinToGray_1u8u_C1R------>ipp functions------>ippiGrayToBin_8u1u_C1R, I find the result are different with IPL.
So, I do a test and find some difference. I find old IPL 1 bit functions,gray to bin, convert 8 byte to 1 byte with the older"high bit to low bit",
as opposed to IPP's ippiGrayToBin_8u1u.
The test code is:
I was just wondering if there are any simple examples on how to use the ippsInflate_8u() function? There are some examples mentioned when googling this, supposed to be in the <ipp>/interfaces folder—but I have no ‘interfaces’ folder at that location in my installation (which was an evaluation version before I got my "real" serial number, maybe that is why)…
In short, I want to benchmark the IPP decompression of a FlateDecode:ed buffer against the method we are using today (an old “standard” version of zlib).
Imagine I have a pipline:
Image in Row Major - Process block 1 - Convert image to col major (transpose) - Process block 2
Now, I can use IPP functions in either stage (1 or 2) by specifying the appropriate step size (1 or width of image) for source and destination images.