I want to perform dilation operation on an image using IppiDilateBorder_8u_C1R function. But I am not sure of how to define the parameters like IppiMorphState *pSpec and Ipp8u *pBuffer. required by the function? I am not able to find a proper document on these. It will be good if you can tell me what the parameters mean and how to define them? I am using Intel IPP 2019 with Microsoft Visual Studio 2019.
Hi!
I want to encrypt (or decrypt) large file.
It is unreasonable/impossible to load the whole file into memory and process it by single AESEncryptCBC call.
The more affordable way is to process that file using consecutive smaller chunks.
So, as far as I understand, the term "initialization vector" is need only for a first Encrypt call.
And subsequent Encrypt calls require knowledge of some state from previous call.
Is it possible with IPP primitives to process large amounts through several AESEncryptCBC calls?
And one more question regarding AESEncryptCBC/AESDecryptCBC.
Can pSrc and pDst pointers be the same?
How can i Download intel IPP version 7 Library? i am unable to find older versions
Can anyone help me on this?
Thank you in advance
we have upated our product to IPP 2020.0.0 Gold and we got some feedback in our Helpdesk system from customers who have problems on some older processors
i.e.
xeon e3 1225 v3
and
i5-34??
it seems, that the initialization of IPP fails on these systems, unfortunal we don't have access to these sytstems and we can't debug.
Are there any known issues on older processors with IPP 2020?
IPP2019 works on the old processors fine.
Ralf
We are having trouble finding some features we used (in composer_xe_2013.2.146) in this new software distribution:
Specifically, we are finding that compilers_and_libraries_2020.0.166/linux/ipp/include/ipps.h
does not contain these symbols
ippsCrossCorr_64fc ippsCrossCorr_32f
ippsFFTFree_C_32fc ippsFFTFree_C_64fc
ippsFFTInitAlloc_C_32fc ippsFFTInitAlloc_C_64fc
ippsFIR_Direct_64f ippsFIR_Direct_64fc
ippsRandGauss_Direct_32f ippsTone_Direct_64f
though they are all present in the 2013 distribution of the Composer XE product.
Hopefully I'm just missing a migration document that can help us?
We're running Parallel Studio XE cluster edition for Linux on RH7.5
I have two suggestions related to the parameters of GradientVectorPrewitt, GradientVectorScharr and GradientVectorSobel.
1. The functions are quite useful, for example in implementing non-linear diffusion functions that are not in IPP (Perona-Malik, Weickert and Charbonnier https://en.wikipedia.org/wiki/Anisotropic_diffusion). But the ippiGradientVector functions require that space is allocated for all return images: Gx, Gy, magnitude and angle. That is a waste of space and computing-time for return parameters that are not relevant for further calculations. For example, typically one may need magnitude only. So, I suggest that these functions permit return image parameters to be NULL.
2. Further calculations may need the square-magnitude rather than the magnitude. So, to save a square-root followed by a square, I suggest ippNormSquareL2.
Of course, I understand that these functions can be emulated with other IPP calls.
Regards,
Adriaan van Os
I get nice results wit large numbers of iterations of ippiDeconvLR. However, because of the large number of iterations, it takes a long time and triggers the following questions:
1. User-friendly software implies that the user can stop (and is informed about) lengthy operations. So, how do I interrupt ippiDeconvLR ? Run it in a separate thread and then kill the thread ? Seems rather crude (and an invitation to memory leaks).
2. Is ippiDeconvLR threaded internally ? Threading it externally simply by tiling, is not possible, see https://lmb.informatik.uni-freiburg.de/Publications/2010/Tem10a/LucyRichardsonDeconvolution.pdf
Sincerely,
Adriaan van Os
When I need a sequence of ippi functions for a composite operation I could, of course, call those ippi functions in sequence. However, for large images that would be a rather bad usage of the CPU Ln caches.
Another solution is to create a composite "ippi" function that calls for each row the equivalent series of ipps functions. An added advantage is that this can be threaded easily, by giving each thread its own set of rows.
If the RowBytes (StepSize) of the image(s) equal(s) the PixelSize multiplied by the ImageWidth, we can work per chunk rather than per row. Let's assume that sysctlbyname with "hw.l1dcachesize" returns the L1 cache per core. The chunk size can be chosen to be that size for in-place operations or half that size for operations from a source to a target.
Is that optimal ? Or what does Intel recommend ?
Regards,
Adriaan van Os
Greetings,
I have problems with running IPP 2019 FFT with OpenMP internal parallelisation, I have already tried approach: https://software.intel.com/en-us/ipp-dev-guide-using-intel-integrated-pe..., but I can't find configuration of libraries to link to make this work.
Using ippsFFTFwd_CToC_64fc and trying to set ippSetNumThreads to 2. (I noticed on forums for internal paralelisation u cannot use more than 2 is this true ?)
For compiling i'm using gcc or icc linking includes with _tl suffix and lib /lib/intel64/tl/openmp/ with _tl suffix.
I noticed you have to mix in some non _tl files still but cannot make it work, could you please provide list of files from include and lib to use to get fft working with openmp ?
My env:
Ubuntu 16.04 LTS
Gcc 6+
Icc from Parallel Studio XE 2020
Also adding small sample code (c++11) I use, I check parallelism with vtune-gui.
Thank you for response,
Adam Simek
| Attachment | Size |
|---|---|
Download fft_ipp.cpp | 3.19 KB |
I already know that there is no support, but I need the libraries to compile an old program to re-engineer the application. I can't change to a newer version because the libraries are mainly used by another library ( I have no source code).
The IPP Developer Reference documents that the border parameter of the functions ippiGrayErodeBorder_8u_C1R and ippiGrayErodeBorder_32f_C1R accepts ippBorderRepl as the only type of border.
However, for application threading (which is what Intel wants us to do, for mysterious reasons) ippBorderRepl must be combined with a mask of ippBorderInMemTop, ippBorderInMemBottom, ippBorderInMemLeft and ippBorderInMemRight, depending on the location of the tile to be processed. But when ippBorderRepl is combined with ippBorderInMemTop, ippBorderInMemBottom, ippBorderInMemLeft or ippBorderInMemRight, ippiGrayErodeBorder_8u_C1R and ippiGrayErodeBorder_32f_C1R return errror ippStsBadArgErr (=-5).
Consequently, ippiGrayErodeBorder can not be application-threaded.
Now that we are at it, I wonder why there is no ippiGrayErodeBorder_16u_C1R variant.
Regards,
Adriaan van Os
Hi,
I have an image given in 12 bit packed format (16 bit gray values but only 12 bits in use). Now I need to unpack it to 16 bit (padded with 4 zero bits). Is there any ipp function that does this job?
Best regards
Steffen
I looked at ippiWTFwd and ippiWTInvInit for wavelet transforms. However, the IPP implementation has a number of disadvantages:
1. ippiWTFwd and ippiWTInvInit are not internally threaded (I assume)
2. the border type can not be specified, they are ROI-type everything-must-be-in memory functions
3. there are 32f_C1R en 32f_C3R variants only.
That made the decision easy to write these functions myself, internally threaded for speed. Result attached for a Haar wavelet applied to an 8-bit one-channel standard test-image.
While writing the Discrete Wavelet Transform (forward and inverse) I missed ippi functions to:
1. up-sample an image (insert zero values at odd-indexed pixels of rows or columns)
2. down-sample an image (keep the even-indexed pixels of rows or columns)
Up- and downsampling are much-used base-functions when working with pyramid-like structures.
Regards,
Adriaan van Os
I noticed a bug in ippiFilterBorder where ippiFilterBorder_16u_C4R and ippiFilterBorder_16u_C1R (and rarely also ippiFilterBorder_32f_C4R and ippiFilterBorder_32f_C1R, but never ippiFilterBorder_8u_C4R or ippiFilterBorder_8u_C1R) write random pixels in parts of the last row of the target image when the convolution kernel has a width of 1 and a height > 1. The result seems to depend on the border type, but does happen with all border types.
The workaround is to apply a horizontal kernel (with height 1 and width > 1) to a transposed image and then to transpose the result back.
This happens with IPP version 9.0, but I can't reproduce it with version 2018-2 or 2019-0. However, I don't see an entry for this in the IPP bug fix logs. Can you confirm that this is something that has been fixed between version 9.0 and 2018-2 ?
Regards,
Adriaan van Os
I noticed that ippiQualityIndex may return a NaN for parameter pQualityIndex, even with comparing images that don't contain a NaN themselves. The result code is ippStsNoErr. I guess the cause is division by zero.
I suggest to return 0.0 rather than NaN in concerning cases.
Regards,
Adriaan van Os
In his original publication [1] Scharr lists (on page 120 ) the filter, named after him, as:
[1] Dipl. Phys. Hanno Scharr, Optimale Operatoren in der Digitalen Bildverarbeitung, INAUGURAL-DISSERTATION zur Erlangung der Doktorwürde der Naturwissenschaftlich-Mathematischen Gesamtfakultät der Ruprecht-Karls-Universität Heidelberg, 10. Mai 2000.
Fx is what ippiFilterScharrHorizMaskBorder actually does (apart from the 1/32 normalization factor). So far, so good.
Now comes the confusion:
1. It does make a difference, visually, if the first column of Fx (and the first row of Fy) is positive or negative. A histogram of the 32f result of the Scharr (and other derivative) filters shows why: the result values are mirrored around 0.0. That difference disappears, of course, if we take the square or absolute value of the result (as is often the case, but not always).
2. It does make a difference if the kernel values are stored (and displayed) in an array or 3x3 matrix. What the programming-matrix does, depends on the programming language being row major or not (where e.g. Fortran, Pascal and C are different). To avoid that confusion, I suggest to always list kernel values as array.
2. The IPP Developer Reference states that ippiFilterScharrHorizMaskBorder is filtered by a 3x3 matrix as follows (and I don't think that is correct)
3. The headers list the same matrix as "ScharrHoriz" (also incorrect I think)
4. The IPP Developer references lists Gx of ippiGradientVectorScharr as
The sign is wrong. Admittedly that doesn't matter when the result is squared or made positive. Still, this adds to the confusion.
I suggest that the docs are clarified, also for the other built-in filters.
Regards,
Adriaan van Os
HI,
I'm using IPP dynamic linked with clang 11.0.0.
Hardware:
I might be missing something but should this be slower than with simple std:: functions?
If yes, how can I make it faster?
struct Vect3DArray
{
Ipp64f* x_;
Ipp64f* y_;
Ipp64f* z_;
Vect3DArray(int size)
{
x_ = ippsMalloc_64f(size * sizeof(Ipp64f));
y_ = ippsMalloc_64f(size * sizeof(Ipp64f));
z_ = ippsMalloc_64f(size * sizeof(Ipp64f));
}
~Vect3DArray() { ippFree(x_); ippFree(y_); ippFree(z_); }
};
int main() {
Vect3DArray vectArray(kAmount);
Vect3DArray dstVectArray(kAmount);
Ipp64f* sums = ippsMalloc_64f(kAmount * sizeof(Ipp64f));
for (std::size_t i = 1; i < kAmount; ++i) {
vectArray.x_[i] = i * 2.5;
vectArray.y_[i] = i * 3.3;
vectArray.z_[i] = i * 4.7;
}
auto start = std::chrono::high_resolution_clock::now();
ippsMul_64f(vectArray.x_, vectArray.x_, dstVectArray.x_, static_cast<int>(kAmount));
ippsMul_64f(vectArray.y_, vectArray.y_, dstVectArray.y_, static_cast<int>(kAmount));
ippsMul_64f(vectArray.z_, vectArray.z_, dstVectArray.z_, static_cast<int>(kAmount));
ippsAdd_64f(dstVectArray.x_, dstVectArray.y_, sums, kAmount);
ippsAdd_64f(sums, vectArray.z_, sums, kAmount);
ippsSqr_64f_I(sums, kAmount);
ippsDiv_64f_I(sums, vectArray.x_, kAmount);
ippsDiv_64f_I(sums, vectArray.y_, kAmount);
ippsDiv_64f_I(sums, vectArray.z_, kAmount);
auto end = std::chrono::high_resolution_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::microseconds>(end - start).count();
std::cout << "#"<< duration << std::endl;
}
My environment:
I'm testing ipprCopyConstBorder_16u_C1V.
It looks like it is designed to place a small image VOI into a large image.
The following code should return a ippStsSizeErr ( since dstRoiVolume.width = 7 < srcRoiVolume.width = 5 + leftBorderWidth 3 ), but it returns ippStsOk.
Please confirm:
void TestCopy()
{
using namespace std;
const IpprVolume srcSize = { 5,5,5 };
const IpprVolume dstSize = { 7,7,7 };
const int numSrc = srcSize.width * srcSize.height * srcSize.depth;
const int numDst = dstSize.width * dstSize.height * dstSize.depth;
const int srcStep = srcSize.width * sizeof(unsigned short);
const int srcPlaneStep = srcSize.width * srcSize.height * sizeof(unsigned short);
const int dstStep = dstSize.width * sizeof(unsigned short);
const int dstPlaneStep = dstSize.width * dstSize.height * sizeof(unsigned short);
vector<unsigned short> srcVol(numSrc), dstVol(numDst);
memset(dstVol.data(), 0, numDst * sizeof(unsigned short));
//Set src image.
int i = 0;
for (int z = 0; z < srcSize.depth; z++) {
for (int y = 0; y < srcSize.height; y++) {
for (int x = 0; x < srcSize.width; x++) {
cout << ""<< i;
srcVol[i++] = i;
}
cout << endl;
}
cout << endl << endl;
}
cout << "End outputting src volume"<< endl << endl;
cout << "Begin outputting dst volume"<< endl << endl;
//Using xBorder = 3 should result in a ippStsSizeErr per the documentation!
int xBorder = 3, yBorder = 2, zBorder = 2;
unsigned short val = numeric_limits<unsigned short>::max();
IppStatus sts = ipprCopyConstBorder_16u_C1V(srcVol.data(), srcPlaneStep, srcStep, srcSize, dstVol.data(), dstPlaneStep, dstStep, dstSize, xBorder, yBorder, zBorder, &val);
assert(sts == ippStsSizeErr);
i = 0;
for (int z = 0; z < dstSize.depth; z++) {
for (int y = 0; y < dstSize.height; y++) {
for (int x = 0; x < dstSize.width; x++) {
unsigned val = dstVol[i++];
cout << ""<< val;
}
cout << endl;
}
cout << endl << endl;
}
}
Hi Guys,
i'm trying to use ipp to convert rgb image to grayscale one.
following code:
gray_frame = Mat(color_frame.size().width, color_frame.size().height, CV_8UC1);
IppiSize roi;
roi.width = color_frame.size().width;
roi.height = color_frame.size().height;
Ipp8u* ippRGBPtr = (Ipp8u*)&color_frame.data[0]; // Get pointer to the data
int ipprgbStep = color_frame.step; // get step value in bytes
Ipp8u* ippGrayPtr = (Ipp8u*)&gray_frame.data[0]; // Get pointer to the data
int ippGrayStep = gray_frame.step; // get step value in bytes
ippiRGBToGray_8u_C3C1R(ippRGBPtr, ipprgbStep, ippGrayPtr, ippGrayStep, roi); // do the color conversion
the problem i'm facing is that the image i now fully procced,
when i cv::imshow(gray_frame) i see half of the image.
what can be the problem?
thank you!
IPP18.1
Microsoft Visual Studio 2015
Does any body understand how the maxPixDiff paramter works in the markSpeckles function?
Using the test image below I expected that for the image
- threshholded at 8194
- maxSpecklesSize of 300
That a maxPixDiff value of >25 would include the 'blue' (middle ring value 8240) portion of the image however
- setting the value to 24 finds the centre portion as expected
- setting 26 finds NOTHING (not even centre portion)
- setting 80 finds NOTHING (not even centre portion)
Note this behaviour is evident on other images (actual data) not just this test pattern
Any help understanding this would be appreciated
