hugin-devs team mailing list archive

[Steinar Midtskogen <steinar@xxxxxxxxxxxxx>]

Public bug reported:

Minimal example to reproduce the problem:
$ 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

We're here mapping between polar coordinates and equirectangular
coordinates where altitude/latitude is 90-y.  So y=0 is zenith and y=180
is nadir, at which points and azimuth/longitude converge and do not
matter.  So the expected result should be 500 500 for all four points.
But I get points circled around 499.5 499.5 instead.

Let's try to shift by 0.5:
$ 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

A partial workaround is to increase the resolution:
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

Now the results converge better and there is less conflict, but the
result is still off by 0.5.  The error does not only apply to
zenith/nadir, but anywhere.

The following diff (relative to the 2013 branch) make pano_trafo produce the expected result in the first example (500 500 for all four points):
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
{

There's also similar code in src/hugin_base/nona/SpaceTransform.cpp and
./src/hugin_base/panotools/PanoToolsTransformGPU.cpp.  However, there
must be a reason why the shift by 0.5 was put there since it's pretty
explicit.  And the above patch does not seem to be a fix.  With it I'm
not getting good results from autooptimise.  The workaround is still to
increase the resolution(s) to a point where the shift becomes
insignificant.

In normal cases an error of half a pixel is not very significant.  I
stumbled upon this bug only because I've created .pto files for ip
cameras (with fixed mounting) and I use pano_trafo to convert between
image pixels and azimuth and altitude, and I use degree scale (but rely
on arc minute resolution).

** Affects: hugin
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1402542

Title:
  Incorrect shift of 0.5 in coordinate translation

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Minimal example to reproduce the problem:
  $ 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

  We're here mapping between polar coordinates and equirectangular
  coordinates where altitude/latitude is 90-y.  So y=0 is zenith and
  y=180 is nadir, at which points and azimuth/longitude converge and do
  not matter.  So the expected result should be 500 500 for all four
  points. But I get points circled around 499.5 499.5 instead.

  Let's try to shift by 0.5:
  $ 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

  A partial workaround is to increase the resolution:
  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

  Now the results converge better and there is less conflict, but the
  result is still off by 0.5.  The error does not only apply to
  zenith/nadir, but anywhere.

  The following diff (relative to the 2013 branch) make pano_trafo produce the expected result in the first example (500 500 for all four points):
  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
  {

  There's also similar code in src/hugin_base/nona/SpaceTransform.cpp
  and ./src/hugin_base/panotools/PanoToolsTransformGPU.cpp.  However,
  there must be a reason why the shift by 0.5 was put there since it's
  pretty explicit.  And the above patch does not seem to be a fix.  With
  it I'm not getting good results from autooptimise.  The workaround is
  still to increase the resolution(s) to a point where the shift becomes
  insignificant.

  In normal cases an error of half a pixel is not very significant.  I
  stumbled upon this bug only because I've created .pto files for ip
  cameras (with fixed mounting) and I use pano_trafo to convert between
  image pixels and azimuth and altitude, and I use degree scale (but
  rely on arc minute resolution).

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1402542/+subscriptions