Showing results for 
Search instead for 
Did you mean: 

Help: Pixel Shift Problem when Resize an image with ippiResizeSqrPixel_32f_C1R

I am using Ipp6.0 version, The input and output image(Dicom image) only have one channel, 16bits per pixel. After Resize with ippiResizeSqrPixel_32f_C1R function, the interpolated image has about 0.5 pixel shift.

Some parameters for my test: original image size: 512*512; ResizeFactor=2.0; pfImageIn, pfImageOut is a memory block allocated with new operator

Here is part of my code, waiting for your help:

int iColSrc = iImgCol; // original image's width
int iLinSrc = iImgLin; // original image's height
int iColDst = short((float)iColSrc * fResizeCol) ; // dest image's width
int iLinDst = short((float)iLinSrc * fResizeLin) ; // dest image's height

IppiSize size = {iColSrc, iLinSrc};
IppiRect srect = { 0, 0, iColSrc, iLinSrc };
IppiRect drect = { 0, 0, iColDst, iLinDst };
Ipp8u *buf;
int bufsize;

//calculation of work buffer size
ippStatus = ippiResizeGetBufSize(srect,drect,1,iInterType,&bufsize);
buf = ippsMalloc_8u(bufsize);
iErrType = MemoryErr;
return false;
// resize m_pfImageIn
ippStatus = ippiResizeSqrPixel_32f_C1R(pfImageIn, size, iColSrc*(int)(sizeof(Ipp32f)), srect,
pfImageOut, iColDst*(int)(sizeof(Ipp32f)), drect,
fResizeCol, fResizeLin, 0, 0, iInterType, buf);

0 Kudos
4 Replies

Hell Kangscut,

What interpolation type are you using? (theiInterTypevalue) . Can youprovide the test image (bmp format if possible) so we can reproduce the issue.

Additionally, the latest IPP version is6.1 update 4, which can be getten following the guide onIPP Downloads, Registration and Licensing.How about the result iftry the new version?



0 Kudos

I'm working on 16bit dicom image too...
can i know why do you use ippiResizeSqrPixel_32f_C1R instead of using ippiResizeSqrPixel_16u_C1R that is supposed to be faster?

it will be surely more precise but you can't represent it on video as no monitor support 32bit grayscale so what's the benefit? are you working on multiple filter image effect so that you must keep the maximun definition on channel data?

0 Kudos

To answer to your question...are you using windows bitmap?

if yes you have to know that the windows Bitmap format require that address of each image row should be aligned onfour bytes resulting in one padding byte at the each image row end in case of odd image width.

i previously have your same problem of shifting


0 Kudos

To answer Carlo's question,

i believed the shift problem as above image should be resolved via set right stepBytes as we discussed in other threads, eg

The stepBytesmay not always equal tochannel*Width.
It may be ((nChannel*srcWidth+3)>>2)<<2 if a bmp image with4 bytes-aligned ora multiple of 32 when use ippiMalloc.

As it is unavoidable to involve the floatingoperation in Resize operation. if considering the cost of convertion of float 32f to 16u, theippiResizeSqrPixel_16u_C1R is not supposed to be faster thanippiResizeSqrPixel_32f_C1R ona general CPU.

To kangscut, aboutabout 0.5 pixel shift,

I guess, thereisrounding issue in some steps indata type conversion or inippiResizeSqrPixel internally.
Forexample,Intel IPP Library 6.1 Fixes List

IPP v6.1 update 3 (26 Nov 2009)

DPD200141560BZIP2 with ipp_ prefixes
DPD200140668ippiResizeSqrPixel_8u_C1R has differing results depending on CPU (rounding error problem)

Besideofupgrade tothe latest IPP version, we may say moreifyou have the exact information abouthowthe image wasstored/loaded/converted.

0 Kudos