Hi,

We are currently still using Intel Image Processing Library version 2.5.9.89 using the following dll:
ipl.dll
iplw7.dll
iplpx.dll
iplp6.dll
iplm6.dll
ipla6.dll

Currently we are supporting windows 7 and we are planning to migrate to windows 10 soon.

May I know if IPL library support win 10?

I understand that the IPL library is replaced with IPP instead. But unfortunately, we are currently not able to migrate the code to use IPP. So we'd like to know if it is still possible to use IPL in win 10.

Regards,

Klarinda

Hi,

During the upgrade from IPP 8.2 to IPP 9.3, we noticed that "ippiFilterBoxBorderGetBufferSize" function gives different results.

The input parameters to this function were:

ROI: {X = 0 Y = 0 Width = 2056 Height = 2056}

Mask Size: {Width = 15 Height = 15}

Data Type: ipp32f

Number Of Channels: 1

And the buffer size coming out of this function was:

IPP 8.2: 17843472

IPP 9.3: 827240

Please advise with further information about the root cause to this difference.

I'd appreciate your help in advance

Hey 

I far as I understood, latest Intel technology works with cache line of 64 byte, 

That's why as a programmer I shall care about 64 byte alignment

I thought of using 64 byte alignment by allocating using: ippsMalloc_32f, however the header documentation said that ippsMalloc_32f  allocate a 32 byte alignment 

(I thought that ipps would malloc  a 64 byte alignment) 

What am I missing here? 

IPP version: 8.2  (2015)

I'm presently updating some code that was written against version 5.1 of the IPP library to work against 9.0.3 (the update was triggered because we need to port the application to a 64 bit platform).

So far I've had no trouble - the IIR and FFT function name changes have been straightforward (the InitAlloc functions went away). 

But the FIR functions are giving me more trouble - specifically, I believe that the ippsFIR functions should be replaced by ippsFIRSR functions, but there is no SetDlyLine for the ippsFIRSR functions. So clearly I've mis-understood something.

What is the appropriate substitution for the old ippsFIRSetDlyLine_64f function in the new IPP libraries?

Hello,

Is there any plan to add the 32f_C1PV datatype for the ipprFilter function? In particular, I apply large (9x9x9) Gaussian filters to volume data extensively, and currently do it by a two-step call to ippiFilterGaussianBorder_32f_C1R, once for XY-planes, and once for Z-planes. This incurs a lot of data transfer overhead, especially for filtering in Z. A single call to a ipprFilter_32f_C1PV, or a  ipprFilterGaussianBorder_32f_C1PV would be a huge help.

Thanks!

Hello all.

My company recently switched to Ipp 9.0 Update 3 (was Ipp 7.1), and I changed our internal libraries to reflect the changes the warping functions.

After getting really strange behavior changes in our high-level code, I tracked the differences to a change in images that we used to warp with ippiWarpPerspectiveQuad_8u_[mod] (Ipp 7.1) but now warp using ippiWarpQuadCubicInit and ippiWarpPerspectiveCubic_8u_[mod] (Ipp 9.0U3):

In a few cases, the left, right, top or bottom borders (or any combination thereof) of the warped images remain completely black. I assume this is connected to the IppiBorderType behavior. Currently, I have it set to ippBorderTransp (which is documented to ignore the border pixels), changing it to ippBorderInMem however randomly(!) produces crashes somewhere in ippiWarpPerspectiveCubic.

Cubic interpolation also changed, changing the interior of the images, but let's ignore that for the moment.

Can someone please tell me the combination of settings I have to use to most closely reproduce the behavior of the deprecated ippiWarpPerspectiveQuad_8u?

Thanks and best regards,

Daniel

I am having a problem with ref. Below is my implementation. The forward transform works fine, I can see the 4 output images look good. The problem is with the inverse, its output (to be the same image dimensions as the input image, image is square (orgWidth==orgHeight)) has aliasing and it looks like every second row and every second column content is blank. I can't find a way to embed an output image here. Please let me know how I can get that to you in case you want to take a look.

Can you please check and see what the problem may be?

Thank you!!

IppStatus ippStatus = ippStsNoErr;

 IppiWTFwdSpec_32f_C1R* pSpecFwd;
 IppiWTInvSpec_32f_C1R* pSpecInv;
 int specSizeFwd, specSizeInv;
 Ipp32f pTapsLow[3] = { 0.25, 0.5, 0.25 };
 int lenLow = 3;
 int anchorLow = 1;
 Ipp32f pTapsHigh[3] = { 0.75, -0.25, -0.125 };
 int lenHigh = 3;
 int anchorHigh = 1;

 int sourceBWidth = orgWidth + 1;
 int sourceBArraySize = sourceBWidth * sourceBWidth;

 Ipp32f *pSrcB = new Ipp32f[sourceBArraySize];
 int srcStepB = sourceBWidth * sizeof(Ipp32f);
 IppiSize roiSizeB = { sourceBWidth, sourceBWidth };
 int srcStep = orgWidth * sizeof(Ipp32f);
 IppiSize roiSize = { orgWidth, orgWidth };

 int subWidth = orgWidth / 2;

 Ipp32f *pDetailXDst = new Ipp32f[subWidth * subWidth];
 Ipp32f *pDetailYDst = new Ipp32f[subWidth * subWidth];
 Ipp32f *pDetailXYDst = new Ipp32f[subWidth * subWidth];
 Ipp32f *pApproxDst = new Ipp32f[subWidth * subWidth];

 IppiSize dstRoiSize = { subWidth, subWidth };
 int bufSizeFwd, bufSizeInv;
 Ipp8u* pBufferFwd;
 Ipp8u* pBufferInv;
 IppiSize roiInvSize = { subWidth, subWidth };
 int stepDstInv = orgWidth * sizeof(Ipp32f);

 int subWidthPlusOne = subWidth + 1;
 Ipp32f *pAppB = new Ipp32f[subWidthPlusOne * subWidthPlusOne];
 Ipp32f *pXB = new Ipp32f[subWidthPlusOne * subWidthPlusOne];
 Ipp32f *pYB = new Ipp32f[subWidthPlusOne * subWidthPlusOne];
 Ipp32f *pXYB = new Ipp32f[subWidthPlusOne * subWidthPlusOne];
 int StepB = subWidthPlusOne * sizeof(Ipp32f);

 IppiSize roiInvSizeB = { (subWidth + 1), (subWidth + 1) };
 int approxStep, detailXStep, detailYStep, detailXYStep;
 approxStep = detailXStep = detailYStep = detailXYStep = subWidth * sizeof(Ipp32f);
 //adds border to the source image
 ippStatus = ippiCopyWrapBorder_32s_C1R((Ipp32s*)pSrc, srcStep, roiSize, (Ipp32s*)pSrcB, srcStepB, roiSizeB, 1, 1);
 //performs forward  wavelet transform
 ippStatus = ippiWTFwdGetSize_32f(1, lenLow, anchorLow, lenHigh, anchorHigh, &specSizeFwd, &bufSizeFwd);
 pSpecFwd = (IppiWTFwdSpec_32f_C1R*)ippMalloc(specSizeFwd);
 pBufferFwd = (Ipp8u*)ippMalloc(bufSizeFwd);
 ippStatus = ippiWTFwdInit_32f_C1R(pSpecFwd, pTapsLow, lenLow, anchorLow, pTapsHigh, lenHigh, anchorHigh);
 ippStatus = ippiWTFwd_32f_C1R(pSrcB + roiSizeB.width + 1, srcStepB, pApproxDst, approxStep,
  pDetailXDst, detailXStep, pDetailYDst, detailYStep, pDetailXYDst, detailXYStep, dstRoiSize, pSpecFwd, pBufferFwd);



/* ippStatus = ippiCopy_32f_C1R(pApproxDst, approxStep, pDst, srcStep, dstRoiSize);
 ippStatus = ippiCopy_32f_C1R(pDetailXDst, approxStep, pDst + subWidth, srcStep, dstRoiSize);
 ippStatus = ippiCopy_32f_C1R(pDetailYDst, approxStep, pDst + (subWidth * m_nVolLoadedX), srcStep, dstRoiSize);
 ippStatus = ippiCopy_32f_C1R(pDetailXYDst, approxStep, pDst + subWidth + (subWidth * m_nVolLoadedX), srcStep, dstRoiSize);
*/

 ippStatus = ippiWTInvGetSize_32f(1, lenLow, anchorLow, lenHigh, anchorHigh, &specSizeInv, &bufSizeInv);
 pSpecInv = (IppiWTInvSpec_32f_C1R*)ippMalloc(specSizeInv);
 pBufferInv = (Ipp8u*)ippMalloc(bufSizeInv);
 ippStatus = ippiWTInvInit_32f_C1R(pSpecInv, pTapsLow, lenLow, anchorLow, pTapsHigh, lenHigh, anchorHigh);
 //adds border to four images obtained after ippiWTFwd
 ippStatus = ippiCopyWrapBorder_32s_C1R((Ipp32s*)pApproxDst, approxStep, dstRoiSize, (Ipp32s*)pAppB, StepB, roiInvSizeB, 0, 0);
 ippStatus = ippiCopyWrapBorder_32s_C1R((Ipp32s*)pDetailXDst, detailXStep, dstRoiSize, (Ipp32s*)pXB, StepB, roiInvSizeB, 0, 0);
 ippStatus = ippiCopyWrapBorder_32s_C1R((Ipp32s*)pDetailYDst, detailYStep, dstRoiSize, (Ipp32s*)pYB, StepB, roiInvSizeB, 0, 0);
 ippStatus = ippiCopyWrapBorder_32s_C1R((Ipp32s*)pDetailXYDst, detailXYStep, dstRoiSize, (Ipp32s*)pXYB, StepB, roiInvSizeB, 0, 0);
 //performs inverse  wavelet transform  
 ippStatus = ippiWTInv_32f_C1R(pAppB, StepB, pXB, StepB, pYB, StepB, pXYB, StepB, roiInvSize, pDst, stepDstInv, pSpecInv, pBufferInv);

// printf_32f_2D("After WTFinv ->\n pDstInv", pDst, roiSize, stepDstInv, ippStsNoErr);

 ippFree(pSpecFwd);
 ippFree(pSpecInv);
 ippFree(pBufferFwd);
 ippFree(pBufferInv);

Hi,

I've decided to try out the IPP version of zlib, but its <ipp directory>/interfaces/data-compression/ipp_zlib folder (according to the documentation seems to be missing in IPP 9.0 Update 3 (both Linux and Windows).  I'd be very grateful for any advice.

Thanks!

Hi, 

I'm working on windows platform.

I have one application (process) that generate data to a second application (different process). The second app is doing some heavy signal processing computation using the ipp functions. I would like to pre-allocate the shared memory with ippMalloc. Can anyone please help my understand how i do such thing ? 

Thanks. 

Hello,

I am seeing an issue with the ippiFilterGetBufSize_64f_C1R function, which returns a buffer size of 0 for a edge case - scalar kernels. This is seen only on SSE4 machines with IPP 9.1. This was not seen in IPP8.1.

This issue can be reproduced with the following function call, with a Kernel size of (1,1) and a ROI width of 2.

 ippiFilterGetBufSize_64f_C1R(kernelSize, dstRoiSize.width, &pBufferSize);

Is this a bug in IPP9.1?

Thanks

-Anchit

Dear all,

I am trying to use ippiHistogram. The problem is - the last (256) byte of histogram result buffer is not filled by ippiHistogram_8u_C1R. 
I have tried to use ippiHistogramInit instead of ippiHistogramUniformInit - the result is the same.
Previously I used iplComputeHisto function - it had worked correctly. 
For example iplComputeHisto returns pHistVec[255] = 1226, but ippiHistogram_8u_C1R returns pHistVec[255] = 1393896807 

I use IPPI version 9 Update 1.

Please, explain, how can I get last histogram value? Thank you!

Here is the code:

IppiSize roi = {image->width, image->height};
int nChannels = image->nChannels;
const int histLen = 255;
int nLevels[] = { histLen+1 };
Ipp32f lowerLevel[] = {0};
Ipp32f upperLevel[] = {255};
Ipp32f pLevels[histLen+1], *ppLevels[1];
int sizeHistObj = 0;
int sizeBuffer = 0;
IppiHistogramSpec* pHistObj = NULL;
Ipp8u* pBuffer = NULL;
Ipp32u pHistVec[histLen + 1];

bool errorInCycle = false;

IppStatus sts = ippiHistogramGetBufferSize(ipp8u, roi, nLevels, nChannels, 0, &sizeHistObj, &sizeBuffer);
if(sts != ippStsNoErr)
{
	return;
}

pHistObj = (IppiHistogramSpec*)ippsMalloc_8u(sizeHistObj);
if(pHistObj == NULL)
{
	return;
}

pBuffer = (Ipp8u*)ippsMalloc_8u(sizeBuffer);
if(pHistObj == NULL)
{
	ippsFree( pHistObj );
	return;
}

sts = ippiHistogramUniformInit(ipp8u, lowerLevel, upperLevel, nLevels, nChannels, pHistObj);
if(sts != ippStsNoErr)
{
	ippsFree( pHistObj );
	ippsFree( pBuffer );
	return;
}

sts = ippiHistogram_8u_C1R((const Ipp8u *) image->imageData, image->widthStep, roi, pHistVec, pHistObj, pBuffer);
if(sts != ippStsNoErr)
{
	ippsFree( pHistObj );
	ippsFree( pBuffer );
	return;
}

std::stringstream ssTemp;
ssTemp << "Hist: ";
for(int i=0; i < 256; i++)
{
	ssTemp << i << " = "<< pHistVec[i] << ",";
}
OutputDebugString((char *)ssTemp.str().c_str());

Kind regards
Dmitry

I've looked through the documentation and it's not clear if IPP can process a FIR using partitioned FFT convolution for use in real time applications. All the example seem to be for offline use. The streaming FIR example seems to be very slow for a FIR with 32K taps compared to partitioned FFT convolution when the sample buffer is around 128 on each call.

Hello,

We have been using IPP’s java language interface  that is provided with ComposerXE samples. Current version we have (XE 2011 and later) don't provide it. Old version of the sample was for 32-bit environment and we like to  convert our application to 64-bit. It seems that later versions of ComposerXE no longer provide java language-interface IPP-sample. Do you happen to know what is the latest ComposerXE/IPP version where the java language-interface is provided and yet is that possible to compile for 64-bit environment?

    Br, Hans

Hello,

I am observing slightly different results when calling ippsSum_64f with the same numbers but in a differently aligned array; is it a bug or a documented behaviour ?

Thanks !

PS: Here is a simple C program that shows this phenomenon:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>

#include "ipp.h"

#define SIZE 1000
#define NB_TESTS 10

int main (void) {
  int alignment,test,k;
  double input1[SIZE], input2[SIZE+1];

  for (alignment = 0; alignment < 8; alignment ++) {
    int failed = 0;

    for (test = 0; test < NB_TESTS; test ++) {
      double r1, r2;
      double *p = (double *) (alignment + (char *)input2);

      for (k = 0; k < SIZE; k ++) {
        input1[k] =  (double)rand() / (double)RAND_MAX;
        p[k] = input1[k];
      }

      ippsSum_64f(input1, SIZE, &r1);
      ippsSum_64f(p, SIZE, &r2);

      if (r1 != r2) {
        printf("[%d %% 8] diff = %e\n", alignment, r2 - r1);
        failed ++;
      }
    }
    printf("[%d %% 8] %d / %d tests failed\n", alignment, failed, NB_TESTS);
  }

  return 0;
}

When the alignment is "0 % 8", ippsSum returns the same result on both inputs but when it's non-zero the test some times succeeds, some times fails (with an error around 1e-13).

Hi,

I'm working on an older software product that leverages the IPP library for MP4V encoding. We are current using version v6.1.1.035 of the IPP library and linking to mpeg4_enc.lib. I downloaded v9.0.3.207 of the IPP library, and I do not see mpeg4_enc.lib. Was the MP4V capability dropped from IPP?

Thanks,
Nate

C++ test program attached, which gives the following output:

ippCore 9.0.3 (r51269)
 ippsSqrt_64f_A53:
 x =               2.225074e-308 5.000000e-01 2.000000e+00 1.797693e+308
 Sqrt_64f_A53(x) = 1.491668e-154 7.071068e-01 1.414214e+00 3.300384e+154
 sqrt(x) =         1.491668e-154 7.071068e-01 1.414214e+00 1.340781e+154

For the input value DBL_MAX the result is wrong. Is this a know issue?

Hi Intel compiler engineers

Is there any known risk when using AVX2 based dynamic library with IPP 7.0 ?

Here's my problem.

A dynamic library built with command /QaxCORE-AVX2 and /O2 works fine with its unit test program. In this dll, some intrinsics were used, such as _mm256_mul_ps, _mm256_add_ps, _mm256_exp_ps, etc. However, when integrating this AVX2 based dynamic library into a project, which had already used some functions from IPP 7.0, the intrinsics' results were getting wrong. I printed the results from _mm256_add_ps and found that the high 128 bits numbers were all ZERO.

Is this phenomenon expected? If so, how can I make it right?

Please suggest me, I am new to this.

Zhongqi Zhang

Hi,

we first noticed the following issue under Linux 32 bit (on a VM pretending to be an Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz, and on a real Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz.  However, in trying to narrow this down to a minimal testcase will could also reproduce essentially the same error (not quite as reliably, and for different input) under Windows 32 Bit on an Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz.

However, due to the more reliable reproducibility under Linux I'll concentrate on this for now.

The code below filters an image (at several resolutions, as the exact size for which this happens varies with CPU) with a 1D vertical Kernel (in my test 7 is the smallest kernel size for which this fails).

It SHOULD produce an image where, except for the first and last 3 lines, everything is filled with '7.0'.

Instead, for some image sizes you will see a swath of zeros going diagonally through the image and the last line either filled with '3.0' (which should never be calculated) on Linux or random memory content on Windows.

Maybe we are using the function wrong (but not sure how)?  Anyway, here's the code, any pointers appreciated:

#include <vector>
#include "ipp.h"
#include "ippi.h"

int main()
{
	int nBorder = 3;
	int nKernelSize = 7;
	IppiSize kernelSize = { 1, nKernelSize };
	IppiPoint anchor = { 0, nKernelSize/2 };
	std::vector<double> aSrc, aDst;
	std::vector<double> aKernel(nKernelSize, 1.);


	for (int nWidth = 4; nWidth < 25; ++nWidth)
	{
		int nPitch = 2 * nBorder + nWidth;

		aSrc.resize(nPitch*nPitch);
		aSrc.assign(nPitch*nPitch, 0.);

		//for (size_t y = 0; y < 2 * nBorder + nWidth; ++y)
		for (size_t y = nBorder; y < nBorder + nWidth; ++y)
		{
			for (size_t x = nBorder; x < nBorder + nWidth; ++x)
			{
				aSrc[y*nPitch + x] = 1.;
			}
		}

		IppiSize dstRoiSize = { nWidth, nWidth };
		int nBufferSize = 0;
		IppStatus status = ippiFilterGetBufSize_64f_C1R(kernelSize, nWidth, &nBufferSize);
		std::vector<Ipp8u> aBuffer(nBufferSize);

		aDst.resize(nWidth*nWidth);
		aDst.assign(nWidth*nWidth, 0.);

		status = ippiFilter_64f_C1R(&(aSrc[nPitch*nBorder+nBorder]), (int)(nPitch * sizeof(aSrc[0])),
									  aDst.data(), (int)(nWidth * sizeof(aDst[0])), dstRoiSize,
									  aKernel.data(), kernelSize, anchor, aBuffer.data());
		(void)status;

		// we expect an image full of nKernelSize, except for the first and last nKernelSize/2 lines
		bool bFail = false;
		for (int y = nKernelSize/2; y < nWidth-nKernelSize/2; ++y)
		{
			for (int x = 0; x < nWidth; ++x)
			{
				if (nKernelSize != aDst[y*nWidth + x])
				{
					bFail = true;
				}
			}
		}

		if (bFail)
		{
			printf("Failure for nWidth = %d\n", nWidth);
			for (int y = 0; y < nWidth; ++y)
			{
				for (int x = 0; x < nWidth; ++x)
				{
					printf("%3.1f ", aDst[nWidth * y + x]);
				}
				printf("\n");
			}
		}
	}
       return 0;
}

In my tests this fails for

• nWidth \in {18, 20, 22} on the E5-2640
• nWidth \in {16, 24} on the i7-5820K
• nWidth \in {16, 18, 20} on the E5-1620 under Windows, but not quite as reproducible.

Any help very much appreciated!

Sven

Hello,

Is there any plan to add the 32f_C1PV datatype for the ipprFilter function? In particular, I apply large (9x9x9) Gaussian filters to volume data extensively, and currently do it by a two-step call to ippiFilterGaussianBorder_32f_C1R, once for XY-planes, and once for Z-planes. This incurs a lot of data transfer overhead, especially for filtering in Z. A single call to a ipprFilter_32f_C1PV, or a  ipprFilterGaussianBorder_32f_C1PV would be a huge help.

Thanks!

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:

  • This release provides 64-bit data length support in the memory allocation, data sorting, image resizing, and image arithmetic functions.
  • Intel® IPP Platform-Aware APIs support external tiling and threading by processing tiled images, which enables you to create effective parallel pipelines at the application level.

• Introduced new Integration Wrappers APIs for some image processing and computer vision functions as a technical preview. The wrappers provide the easy-to-use C and C++ APIs for Intel® IPP functions, and they are available as a separate download in the form of source and pre-built binaries.

• Performance and Optimization:

  • Extended optimization for Intel® Advanced Vector Extensions 512 (Intel® AVX-512) instruction set on Intel® Many Integrated Core Architectures (Intel® MIC Architectures). Please see the Intel® IPP Functions Optimized for Intel® AVX-512 article for more information.
  • Extended optimization for Intel® AVX-512 instruction set on Intel® Xeon® processors.
  • Extended optimization for Intel® Advanced Vector Extensions 2 (Intel® AVX2) instruction set on the 6th Generation Intel® Core™ processors. Please see the Intel® IPP Functions Optimized for Intel® AVX2 article for more information.
  • Extended optimization for Intel® Streaming SIMD Extensions 4.2 (Intel® SSE4.2) instruction set on Intel® Atom™ processors.

• Data Compression:

  • Added the patch files for the zlib source to provide drop-in optimization with Intel® IPP functions. The patches now supports zlib version 1.2.5.3, 1.2.6.1, 1.2.7.3 and 1.2.8.
  • Significantly improved performance of zlib compression functions on the standard compression modes.
  • Introduced a new fastest zlib data compression mode, which can significantly improve compression performance with only a small sacrifice in compression ratio.

• Signal Processing:

  • Added the ippsIIRIIR functions that perform zero-phase digital IIR filtering.
  • Added 64-bit data length support to the ippsSortRadixAscend and ippsSortRadixDescend functions.
  • Added unsigned integer data support to the ippsSortRadixAscend, ippsSortRadixDescend, ippsSortRadixIndexAscend and ippsSortRadixIndexDescend functions.

• Image Processing:

  • Added the ippiScaleC functions to support image data scaling and shifting for different data types by using 64-bit floating multiplier and offset.
  • Added the ippiMulC64f functions to support image data multiplication by a 64-bit floating point value.

Check the Intel® IPP release notes to find more information.

Intel® IPP packages are as part of Intel® Parallel Studio XE, Intel® System Studio, and a free community licenses version:

• Intel fully supported suites: Intel IPP is part of a suite of Intel Software Development Products which are available worldwide for purchase.  These products are backed by Intel, include Intel® Premier Support (which includes private direct support from Intel and support for past versions). Learn more at Intel® Parallel Studio XE, or Intel® System Studio  
• Community Licenses for Intel Performance Libraries: Community licensing for Intel performance libraries comes with no access to Intel Premier Support, but (like the regular products) has no royalties, and no restrictions based on company or project size. Learn how to register for Community Licenses at software.intel.com/nest