BUG in ippiDemosaicAHD_8u_C1C3R?

[Stefan_B_3]

Hi,

I have a question regarding the ippiDemosaicAHD_8u_C1C3R function and maybe the 16 bit version as well:

The documentation states the function needs at least a 5 by 5 pixel input image. This can be deduced from the section describing the possible return values:

"Indicates an error condition if the srcSize has a field that is less than 5, or if the roiSize has a field with negative or zero value."

However using the latest (2018.3) version of the IPP I noticed that when the height of the image is exactly 5 the function writes results directly BEFORE the address passed as the 'pDst' parameter resulting in a heap corruption very hard to track down.

Furthermore I am unsure if the documentation shouldn't specify the type of alloc function to use for the pTmp function. To me it seems like you have to use ippiMalloc_8u_C3 so the type of the resulting image as otherwise (when using e.g. ippiMalloc_8u_C1) I get heap corruptions, too however the documentation is not clear about that?!

Last but not least there are 2 typos in the header:

- "filter array image to RGB image wih AHD algorithm"

- "Type of baeyers grid"

Regards,

Stefan

P.S.: Apart from that: This is the first time I ever had any problems with the IPP, which I am using extensively since a lot of years now! Great stuff!!!

P.P.S.: In case that is important: I am getting this crash on a Windows 10 64-bit machine with an i7-7700@3.6 GHz but also saw this happen on Windows 7 with a different Intel processor. So far this has not been observed on a Linux machine.

[Andrey_B_Intel]

Hi Stefan.

Thanks for your feedback.

According with API temporal image pTmp is

 (srcRoi.width +6) * 30 * sizeof(Ipp8u) , tmpStep = 30*sizeof(Ipp8u) for Ipp8u or 

 (srcRoi.width +6) * 30 * sizeof(Ipp16u) , tmpStep=30*sizeof(Ipp16u)  for Ipp16u.

So minimal size of buffer is W*H = (5+6) cols * 30 rows.   Also could you please provide just small C code reproducer of your issue? 

Thanks.

[Stefan_B_3]

Hi Andrey,

I attached a small example explaining what the problem is. You may need to fiddle around with the include path but apart from that it should run with no problems and now it also seems pretty clear what is going on.

Looking forward to hear from you!

Regards,

Stefan

[Gennady_F_Intel]

Stefan, compiling your example with the latest IPP 2018 u3 ( statically, 64 bits on AVX2 bases system, window ) and executing , I see no problem:

..\780762\_. test.exe

ippiDemosaicAHD_8u_C1C3R returned 0

ippiDemosaicAHD_8u_C1C3R returned 0

[Stefan_B_3]

Dear Gennady,

thanks for the feedback! I guess this is partly my mistake! The function call return no error (and I missed to add an output message at the place where the error occurs. However the exit code of the application will be 42 in case of an error. I will attach an updated source file plotting an error message when the problem occurs!

Regards,

Stefan

[Andrey_B_Intel]

Hi Stefan.

I confirm your issue for images Wx5. I'll put fix to the nearest IPP release. As workaround allocate please 1 additional line for Wx5 images. For big enough images all is ok.

Also just for information we have 2 additional Debayer functions: linear - ippiCFAToRGB_8u_C1C3R and variable number of gradients ippiCFAToBGRA_VNG_8u_C1C4R_L 

Thanks for your feedback.

[Stefan_B_3]

Hooray, thanks!

Regards,

Stefan

[Gennady_F_Intel · Accepted solution]

Stefan, could you please try IPP version 2019 which we release at the last week. The fix of the problem has been added to this initial version. 

[Stefan_B_3]

Hi Gennady,

I can confirm this bug has been fixed! Thanks! However an old friend is back: https://software.intel.com/en-us/forums/intel-integrated-performance-primitives/topic/701943

To be quite honest I do not remember what did help me back then. However since I updated to IPP 2019 on my Ubuntu 8.04 (32-bit) the process simply hangs again. I guess the other thread might be more useful for this.