Intel® Integrated Performance Primitives

Your Feedback Matters

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.

Announcing Intel IPP 2017 release

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


referring to 

      David F.Rogers

      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


Intel® IPP 2017 Bug Fixes

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, or submit an issue to Intel® Premier Support,

Intel® IPP 2017  (6 Sep 2016)

  • Intel® Integrated Performance Primitives
  • The results of ippsCopyLE_1u and ippsCopyBE_1u are same

    As the doc says(,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



    Significant regression when moving from ippiErode_8u_C1R (8.1) to ippiErodeBorder_8u_C1R (9.0.1) - about 14x for 640x480 unit8

    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.

    Bug report: bug ippiInpaint_8u_C3R with IPP_INPAINT_TELEA

    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:

    Some confusion about converting IPL 1bit funciton to IPP

    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:

    Example of ippsInflate_8u usage?



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

    Subscribe to Intel® Integrated Performance Primitives