When Iwas using ippiInpaint_8u_C3Rfor inpainting on a group of ~100 images (800 x 600 mostly), I ran into memory access violation a couple of times. As I dived deeper into the problem, it appeared to me thatthere might be a problemwith how ippiInpaint_8u_C3R handles inpainting on the image boundary (bottomscanline in my cases). For instance, for an 800 x 600 RGB image, when I am not using memory alignment, there are 2400 bytes per line. The access violation typically happens at address (src ptr) + 0x1600xx (decimal 144xxxx), with xxxx depending on the image. if we devide 144xxxx by 2400 bytes per line, this address would translate to 600.xxx line,andone thing the images causing troubleshaving in common is that they all have pixelsto beinpainted at the bottom scanline.
OS: windows XP
IDE: Microsoft Visual Studio 2005 professional edition (usingVC++ default compiler and linker)
IPP version: 5.2 and 5.3
Other library used in the project : Intel MKL 9.1, OpenCV 1.0, Boost 1.35, Qt 4.4
On the same set of images, I did the following tests trying to pinpoint theproblem
1. This problem goes away completely whenI remove these bottom pixels from the mask so that they don't get inpainted.
2. This problem goes away completely if Imark every pixel on the bottom line as to be inpainted. This may look strange at first, but I think it has something to do with how neighboring pixels are accessed to inpaint one pixel. (Since all neighboring pixels are marked in this case ... )
3. At some point, I thought this error might be caused by the non-defaultno memory block alignment used in my code, so I switched all my code to work on 32-byte IPP default alignment. The problem did not go away.
4. I tried compiling and running the same code on linux Fedora using g++ (I forgot the detailed setting) and the problem went away.
I've attached my code below. I haven't found any solutionexcept fornot inpainting the last line. I would really appreciateif anyone canhelp me with this. Thanksin advance.
// ============================================================================================// Distance transform using fast marching.int pBufferSize;
distanceTransform(_size, 1, Ipp32f(0));
IppStatus status = ippiFastMarchingGetBufferSize_8u32f_C1R(_size, &pBufferSize);
Ipp8u *pBuffer =new Ipp8u[pBufferSize];
status = ippiFastMarching_8u32f_C1R(_mask8u.data(), _mask8u.stepBy tes(), distanceTransform.data(), distanceTransform.stepBytes(), _size, 1.f, pBuffer);delete  pBuffer;
// -----------------------------------------------------------------------------------------------// flags Specifies algorithm for image inpainting; following values are possible:// IPP_INPAINT_TELEA Telea algorithm;// IPP_INPAINT_NS Navier-Stokes equation.
IppiInpaintState_8u_C3R * pStateInpainting = NULL;
// fill in the missing pixels with inpainting
status = ippiInpaintInitAlloc_8u_C3R(&pStateInpainting, distanceTransform.data(), distanceTransform.stepBytes(), _mask8u.data(), _mask8u.stepBytes(), _size, 1.f, IppiInpaintFlag(flag));
status = ippiInpaint_8u_C3R(_imageOriginal.data(), _imageOriginal.stepBytes(), _image8u.data(), _image8u.stepBytes(), _size, pStateInpainting);
status = ippiInpaintFree_8u_C3R(pStateInpainting);
could you please take a look at IPP image-codecs/uic sample. It contains picnic application where you can call InPainting functionality on the loaded image. We did not met any issues with that, so you might be interested to see how to call IPP inpainting functions.
I have exactly the same problem. With some input the ippiInpaint_8u_C3R accesses memory one line after the destination image.
This problems seems to only be present in CPU version with prefix "e9_" My image size is 1920x1080. Calling ippiInpaint_8u_C3R with height minus one workarounds the problem.
I am using IPP 7.1.1.