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"
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 email@example.com 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.
Thanks for your feedback.
According with API temporal image pTmp is
( +6) * 30 * sizeof(Ipp8u) , tmpStep = 30*sizeof(Ipp8u) for Ipp8u or
( +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?
Stefan, compiling your example with the latest IPP 2018 u3 ( statically, 64 bits on AVX2 bases system, window ) and executing , I see no problem:
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!
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.
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.