Need details on IppiResizeCenter

[gol]

It may sound dumb, but I'm using IppiResizeCenter using nearest neighbor (IPPI_INTER_NN) interpolation.
(I know it's no rocket science to do it myself, but it's there & working)

No interpolation is useful for things like screen magnifiers, or image editors, where you have to see pixels. Only problem, you don't just want to see the pixels, you wanna interact with them, thus you need to know precisely which pixel you're above.
So I'm trying to match a grid perfectly over a bitmap resized using IppiResizeCenter, trying to match the rounding errors of the function, but I just can't manage to get it perfect.

I have tried:

-accumulating a 64bitfloat position (=additions)
-multiplying a 64bit floatposition (=multiplications)
-same as the above, but with single-precision
-using a 64bit integer accumulator, as 32+32bit fixed point
-using alternate truncation methods like round(value-0.5)

..but there's always a mismatch between the grid & the stretched bitmap

Could you reveal how IppiResizeCenter is accumulating? If not in detail, at least if it's using a fixed or floating point accumulator?

[Yuri_Tikhomirov__Int]

Hi,

I see, you want to manage offsetin pixel.

SoI recommend you to use the function ippiResizeSqrPixel. It has more right-expanded API:
IppStatus ippiResizeSqrPixel_(const Ipp* pSrc, IppiSize srcSize, int srcStep, IppiRect srcRoi, Ipp* pDst, int dstStep, IppiRect dstRoi, double xFactor, double yFactor, double xShift, double yShift, int interpolation, Ipp8u* pBuffer);
The four double parameters allow do it because we have full transformation matrix
|dX| |xFactor 0 | |sX| |xShift|
| | = | | * | | + | |
|dY| | 0 yFactor| |sY| |yShift|

Thanks,
Beg

[gol]

Ok I spoke too fast, my grid still doesn't match perfectly.

I've spent hours on this, I tried pretty much every imaginable combination of these:

-Shift+X*Zoom, all in double float (& even extended precision)
-Shift+X*Zoom, result in single float
-Shift as single float, X*Zoom as single float, added separately
-all of these as single floats
-truncation & rounding, using FPU
-truncation & rounding, using IppsConvert_32f32s_Sfs/IppsConvert_64f32s_Sfs
-any of the above for top-left coordinate, accumulator as single precision & double precision
-64bit fixed-point accumulator

But something tells me that it can't be done because the stretching function probably isn't made to be that precise. If I was doing a stretching function I'd certainly use a fixed-point accumulator in the loop (but last time I made one it was a long time ago, there was no SSE & the FPU was slow), and floats to compute my first coordinates, not caring so much about precision. So if it's what the stretching function is doing, it's normal that I can't find a solution.
So I'm now doing my own non-interpolated stretcherbecause I spent a lot more time fiddling with this than it'd have taken to do it.

(I replied the wrong post/edited my previous post by mistake, though what I wrote below about ippiResizeSqrPixel being much better is still true for other reasons)

[gol]

Ok, ippiResizeSqrPixel is vastly superior in accuracy. Not only my grid matches perfectly (used double accuracy accumulator with truncation), its different interpolation methods also properly center their pixels. Thanks for the tip.

IMHO you should warn about not using ippiResizeCenter in the manual, it's harder to use,it's inacurate, and it doesn't support as many interpolation methods, what's the point? Ok, it doesn't require a temp buffer, but still..

[Yuri_Tikhomirov__Int]

Thanks for your opinion.
The functions ippiResize and ippiResizeCenter have been declared as obsolete in the documentation since IPP 6.1

Regards,
Beg

[gol]

May I suggest some kind of IppiResizeGetPixelTopLeft function, which would take the (required) same parameters as ippiResizeSqrPixel, as well as a pair of coordinates in the source bitmap, to return a pair of coordinates in the destination bitmap? (as well as a function to do the opposite)

It would only work with IPPI_INTER_NN, and would basically compute Shift+XYFactor*XY, but with whatever internal accuracy you use.
So that an image editor would be able to use ippiResizeSqrPixel & IPPI_INTER_NN, and still perfectly map source coordinates to on-screen coordinates (& vice versa).

[Vladimir_Dudnik]

Sure. Any feedback, bug reports or feature requests are welcome at Intel Premier Support

Vladimir

[matthieu_darbois]

Quoting - gol

May I suggest some kind of IppiResizeGetPixelTopLeft function, which would take the (required) same parameters as ippiResizeSqrPixel, as well as a pair of coordinates in the source bitmap, to return a pair of coordinates in the destination bitmap? (as well as a function to do the opposite)

It would only work with IPPI_INTER_NN, and would basically compute Shift+XYFactor*XY, but with whatever internal accuracy you use.
So that an image editor would be able to use ippiResizeSqrPixel & IPPI_INTER_NN, and still perfectly map source coordinates to on-screen coordinates (& vice versa).

Something totally inefficient but that should work (not tested) would be to apply the same resize function to a binary checkboard. It should then be fairly easy to map the black & white pixels to coordinates.
It doubles memory use and time taken but if that's not to much of an issue.

Matthieu