remap of remap is not equal to remap

asked 2016-08-19 17:35:07 -0600

gregoireg
21 ●1 ●2 ●6

I have two successive remap calls and I'm trying to merge them:

for (int j = 0; j < h; j++)
    for (int i = 0; i < w; i++) {
        float x, y;
        x = mapx2.at<float>(j, i);
        y = mapy2.at<float>(j, i);
        x = RANGE(x, 0, w - 1);
        y = RANGE(y, 0, h - 1);
        mapx1_2.at<float>(j, i) = mapx1.at<float>(y, x);
        mapy1_2.at<float>(j, i) = mapy1.at<float>(y, x);
    }

The overall result looks the same but details are different. Here is an example. The first extract with the two successive remaps shows a smooth line. The second extract with the single merged remap is not smooth.

I tried to cast x and y to int but with the same result.

I understand that "interpolation of interpolation" is not the same as a single merged interpolation. How could I fix the problem?

PS: I asked the question on Stackoverflow but here should be a better place to get an answer I think.

edit retag flag offensive close merge delete

add a comment

2 answers

Sort by » oldest newest most voted

answered 2016-08-19 22:17:23 -0600

Tetragramm

7376 ●13 ●37

Short answer: You're missing the interpolation. Your floats are getting down-converted to int when you access the pixel of the second map and you're losing the interpolation between them.

I honestly don't know if there's a good way to solve this. If one of the remaps is a simple transform, you can simply apply it yourself to make it work, but if they're both arbitrary...

edit flag offensive delete link

Comments

I'm still confused. The extract looks GOOD when the two successive remaps occur. It's NOT, when I have the single merged remap. From your explanation, I would have thought the opposite.

gregoireg ( 2016-08-20 02:20:04 -0600 )edit

In my case, map[xy]2 is completely arbitrary but map[xy]1 corresponds to a 45-degree 3D rotation around the Y axis. I used this link to convert the transformation into a remap. I calculated the transformation with this link. In my code above, x and y are float. So even if I manage to replace mapx1 and mapy1 by sin/cos formula, how is it going to change and fix my problem?

gregoireg ( 2016-08-20 02:26:12 -0600 )edit

So, let's pretend that you're only shifting 0.25 pixels in the x direction, in both maps. You look up pixel (0,0) and see that the x is 0.25. Great. You check the range, and it's within the range, so that's good. Now you look up the second map. Here you can't look up what is in pixel 0.25, since there's no such thing. So it rounds to 0 and looks up what is in pixel 0, which is 0.25 again. Now your final shift is 0.25, when it should be 0.5.

All along, the first map is being rounded to the nearest int, which leads to the jaggies. If you know the math (which you say you do), you can do the floating point math on the values directly and not lose any precision.

Tetragramm ( 2016-08-20 13:36:29 -0600 )edit

Very clear explanation. I got it now. The int-casting is done by "map[xy]1.at". Thanks.

gregoireg ( 2016-08-20 14:07:54 -0600 )edit

add a comment

answered 2016-08-20 05:04:59 -0600

rosietesmen
1 http://www.3d-architec...

The overall result looks the same but details are different. Here is an example. The first extract with the two successive remaps shows a smooth line. The second extract with the single merged remap is not smooth.

edit flag offensive delete link

add a comment

remap of remap is not equal to remap

2 answers

Comments

Links

Question Tools

Stats

Related questions

remap of remap is not equal to remap edit

2 answers

Comments

Links

Question Tools

Stats

Related questions

remap of remap is not equal to remap