Incorrect shift of 0.5 in coordinate translation

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