Panotools rounding bug?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Panotools rounding bug?

PanoTools NG mailing list
Hello,

I'm using panotools to have a way to map pixel positions from images
taken from a camera with fixed mounting to azimuth and altitude.  I've
found the lens parameters to do this mapping, so I have this .pto file:

p f2 w360 h180 v360  E0 R0 n"TIFF_m c:LZW"

i w2560 h1920 f20 v115.300003051758 Ra0 Rb0 Rc0 Rd0 Re0 Eev0 Er1 Eb1 r-91.5480454981774 p56.1206691041098 y-116.148308683515 TrX0 TrY0 TrZ0 j0 a0.0652360889615975 b-0.118396567769254 c0.0640016515343118 d-36.3733937252929 e-42.9029343890171 g-402.633165871505 t536.698532676161 Va1 Vb0 Vc0 Vd0 Vx0 Vy0  Vm5 n"/home/steinar/track/out/clean_201412090100.jpg"

This will map x in my Thoby fisheye image to azimuth and y to
90-altitude.  That is, if y is 0, I should get the same result
regardless of x (y = 0 means the pole).  But this is what I get:

$ echo 0 0   90 0   180 0   270 0 | pano_trafo -r lens.pto 0
2040.171640 1084.863599
2031.337128 1100.300503
2044.760528 1109.326401
2053.617284 1093.875862

However, if I use -0.5 for y, then x doesn't matter:

$ echo 0 -0.5   90 -0.5   180 -0.5   270 -0.5 | pano_trafo -r lens.pto 0
2042.489582 1097.095860
2042.489582 1097.095860
2042.489582 1097.095860
2042.489582 1097.095860

The unexpected shift of -0.5 remains the same even if I rescale the
output, e.g. multiplying by 1000:
p f2 w360000 h180000 v360  E0 R0 n"TIFF_m c:LZW"

I still get the same with the output rescaled in the pto file:

$ echo 0 -0.5   90 -0.5   180 -0.5   270 -0.5 | pano_trafo -r lens.pto 0
2042.489582 1097.095860
2042.489582 1097.095860
2042.489582 1097.095860
2042.489582 1097.095860

However, if I now use y=0, I get something much closer to what I
originally expected:

$ echo 0 0   90 0   180 0   270 0 | pano_trafo -r lens.pto 0
2042.487385 1097.083601
2042.487367 1097.083606
2042.487350 1097.083611
2042.487332 1097.083616


If I had been actually creating an output image, an offset of half a
pixel probably isn't a big deal.  Still, this must be some kind of bug?

The workaround is simple, I can just rescale by a lot (since I'm only
using pano_trafo and will never actually create an image, the size
doesn't matter).

--
Steinar
Reply | Threaded
Open this post in threaded view
|

Re: Panotools rounding bug?

PanoTools NG mailing list


On 12 December 2014 13:19:01 GMT+00:00, Steinar Midtskogen wrote:
>
>$ echo 0 0   90 0   180 0   270 0 | pano_trafo -r lens.pto 0
>2040.171640 1084.863599
>2031.337128 1100.300503
>2044.760528 1109.326401
>2053.617284 1093.875862
>
>However, if I use -0.5 for y, then x doesn't matter:

pano_trafo is using pixel coordinates, starting at top left of the image. So a negative value doesn't really mean anything (especially for an equirectangular image). To translate these pixel coordinates to altitude-azimuth you need to shift them by 90 and 180 pixels.

--
Bruno
Reply | Threaded
Open this post in threaded view
|

Re: Panotools rounding bug?

PanoTools NG mailing list
"Bruno Postle [hidden email] [PanoToolsNG]"
<[hidden email]> writes:

> pano_trafo is using pixel coordinates, starting at top left of the
> image. So a negative value doesn't really mean anything (especially
> for an equirectangular image). To translate these pixel coordinates to
> altitude-azimuth you need to shift them by 90 and 180 pixels.

Actually, alt=90-y assuming a 360x180 degree equirectangular image where
alt=90 is zenith and alt=-90 is nadir.

I would expect negative y to mean that I would be on the (x + 180) % 360
meridian, but the flipover should happen at y=0, not -0.5.

I've been using panotools to track meteors, like this:

 http://norskmeteornettverk.no/bilder/2014/meteor-20141208.jpg

The grid was made using pano_trafo, feeding in az, alt points and
getting out points for lines in the photo.  However, when I did the same
thing for a camera pointing upwards, I got this:

 http://norskmeteornettverk.no/bilder/2014/meteor-20141209-grid.jpg

Note that the zenith point is a circle 1 degree wide, not a point!
That's how I discovered this oddity.


A minimal .pto file to reproduce this issue is:

$ cat x.pto
p f2 w360 h180 v360
i w1000 h1000 f20 p90

$ echo 0 0 90 0 180 0 270 0 | pano_trafo -r x.pto 0 2> /dev/null
499.412993 489.530032
489.530032 499.587007
499.587007 509.469968
509.469968 499.412993

The expected result should be 500 500 for all four points.  But I get
points circled around 499.5 499.5 instead.

$ echo 0 -0.5 90 -0.5 180 -0.5 270 -0.5 | pano_trafo -r x.pto 0 2> /dev/null
499.500000 499.500000
499.500000 499.500000
499.500000 499.500000
499.500000 499.500000

If I rescale in the .pto file:
p f2 w36000 h18000 v360
i w1000 h1000 f20 p90

$ echo 0 0 9000 0 18000 0 27000 0 | pano_trafo -r x.pto 0 2> /dev/null
499.499991 499.400296
499.498425 499.400308
499.496860 499.400345
499.495295 499.400407

Still a circle around 499.5 499.5, but not the same as above, much
tighter instead!

pano_trafo version 2013.0.0.4692917e7a55

I might not have the most recent version.  Can anyone with something
more recent check if the results are the same for something more recent?

--
Steinar
Reply | Threaded
Open this post in threaded view
|

Re: Panotools rounding bug?

PanoTools NG mailing list


On 12 December 2014 19:39:51 GMT+00:00, Steinar Midtskogen wrote:

>
>A minimal .pto file to reproduce this issue is:
>
>$ cat x.pto
>p f2 w360 h180 v360
>i w1000 h1000 f20 p90
>
>$ echo 0 0 90 0 180 0 270 0 | pano_trafo -r x.pto 0 2> /dev/null
>499.412993 489.530032
>489.530032 499.587007
>499.587007 509.469968
>509.469968 499.412993
>
>The expected result should be 500 500 for all four points.  But I get
>points circled around 499.5 499.5 instead.

It certainly looks like a bug to me, is there a similar problem at the nadir?

>pano_trafo version 2013.0.0.4692917e7a55
>
>Can anyone with something
>more recent check if the results are the same for something more
>recent?

I'd be surprised if any of this stuff had changed in the last few years.

--
Bruno
Reply | Threaded
Open this post in threaded view
|

Re: Panotools rounding bug?

PanoTools NG mailing list
"Bruno Postle [hidden email] [PanoToolsNG]"
<[hidden email]> writes:

> On 12 December 2014 19:39:51 GMT+00:00, Steinar Midtskogen wrote:
>>
>>A minimal .pto file to reproduce this issue is:
>>
>>$ cat x.pto
>>p f2 w360 h180 v360
>>i w1000 h1000 f20 p90
>>
>>$ echo 0 180 90 180 180 180 270 180 | pano_trafo -r x.pto 0 2> /dev/null
>>499.412993 489.530032
>>489.530032 499.587007
>>499.587007 509.469968
>>509.469968 499.412993
>>
>>The expected result should be 500 500 for all four points. But I get
>>points circled around 499.5 499.5 instead.
>
> It certainly looks like a bug to me, is there a similar problem at the
> nadir?

Yes.

$ cat > x.pto << EOF
p f2 w360 h180 v360
i w1000 h1000 f4 v180 p-90
EOF

$ echo 0 180 90 180 180 180 270 180 | pano_trafo -r x.pto 0 2> /dev/null
499.524241 496.722328
502.277672 499.524240
499.475759 502.277672
496.722328 499.475760

$ echo 0 179.5 90 179.5 180 179.5 270 179.5 | pano_trafo -r x.pto 0 2> /dev/null
499.500000 499.500000
499.500000 499.500000
499.500000 499.500000
499.500000 499.500000

The subtraction of 0.5 appears to happen for x as well.

An error of half a pixel is not much (though quite significant for me
since I'm not using pixels but degrees), but it could perhaps negatively
impact the matching algorithm.  While a workaround is to increase the
output resolution, it would be nice to get this fixed.  Is
https://bugs.launchpad.net/hugin/ the right place to report it?

I'll have a look at the source code repository and look for suspicious
+/- 0.5.  My guess is that that +/- 0.5 is added explicitly somewhere
(twice, symmetrically), but it was probably added for a reason, and it
would be great if the one who wrote this could weigh in.

--
Steinar
Reply | Threaded
Open this post in threaded view
|

Re: Panotools rounding bug?

PanoTools NG mailing list
The patch below (2013 branch) does indeed seem to fix the problem.
There's also similar code in src/hugin_base/nona/SpaceTransform.cpp.

I guess the question is, why the translation of half a pixel in the
first place?

-Steinar

diff -r 4692917e7a55 src/hugin_base/panotools/PanoToolsInterface.cpp
--- a/src/hugin_base/panotools/PanoToolsInterface.cpp   Sun Oct 27 12:22:49 2013 +0100
+++ b/src/hugin_base/panotools/PanoToolsInterface.cpp   Sat Dec 13 13:56:07 2014 +0100
@@ -260,15 +260,15 @@
 bool Transform::transformImgCoord(double & x_dest, double & y_dest,
                        double x_src, double y_src) const
 {
-    x_src -= m_srcTX - 0.5 ;
-    y_src -= m_srcTY - 0.5;
+    x_src -= m_srcTX;
+    y_src -= m_srcTY;
     
     void * params= (void *) (&m_stack);
     bool ok = execute_stack_new(x_src, y_src, &x_dest, &y_dest, params) != 0;
     if(ok)
     {
-        x_dest += m_destTX - 0.5;
-        y_dest += m_destTY - 0.5;
+        x_dest += m_destTX;
+        y_dest += m_destTY;
     }
     else
     {
Reply | Threaded
Open this post in threaded view
|

Re: Panotools rounding bug?

PanoTools NG mailing list
In reply to this post by PanoTools NG mailing list
On 13 December 2014 11:47:45 GMT+00:00, Steinar Midtskogen wrote:

>An error of half a pixel is not much (though quite significant for me
>since I'm not using pixels but degrees), but it could perhaps
>negatively
>impact the matching algorithm.  While a workaround is to increase the
>output resolution, it would be nice to get this fixed.  Is
>https://bugs.launchpad.net/hugin/ the right place to report it?

Yes please file a bug at launchpad, it is more likely to get attention there, also it won't get forgotten. Include your test cases and patch.

>I'll have a look at the source code repository and look for suspicious
>+/- 0.5.  My guess is that that +/- 0.5 is added explicitly somewhere
>(twice, symmetrically), but it was probably added for a reason, and it
>would be great if the one who wrote this could weigh in.

I assume this function was once used solely for accessing integer pixel values, it would be interesting to find out why the change was made in Hugin and not in libpano13.


--
Bruno