(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?
I see, you want to manage offsetin pixel.
SoI recommend you to use the function ippiResizeSqrPixel. It has more right-expanded API:
The four double parameters allow do it because we have full transformation matrix
|dX| |xFactor 0 | |sX| |xShift|
| | = | | * | | + | |
|dY| | 0 yFactor| |sY| |yShift|
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)
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..
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.