- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

(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?

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

I see, you want to manage offsetin pixel.

SoI recommend you to use the function ippiResizeSqrPixel. It has more right-expanded API:

IppStatus ippiResizeSqrPixel_

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

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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)

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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..

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

The functions ippiResize and ippiResizeCenter have been declared as obsolete in the documentation since IPP 6.1

Regards,

Beg

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

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).

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content

*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).

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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page