Closed GoogleCodeExporter closed 9 years ago
I traced the bug down to the image2field conversion. Apparently the image2field
conversion becomes numerically unstable for certain input coordinates.
To really reproduce:
1) Download and extract the following ssl-vision settings files into a fresh
copy of
ssl-vision:
http://www.cs.cmu.edu/~robosoccer/small/movies/PhantomSettings.zip
2) run vision and start capture (it's setup using the generator plugin, so no
cameras
are required to reproduce this). Do NOT change the resolution or any of the
config
files, because it could prevent reproducibility of the bug.
3) using the dvr plugin on the right, load the "PhantomFrame" directory that
came
along with the zip file.
4) hit Playback of the video in the DVR movie plugin.
5) graphical client should show the ball in the center of the field where it
actually
is not.
More interestingly, you can directly reproduce this in code, using the camera 1
(not
0) calibration in the xml files:
For example, adding the following into the PluginDetectBalls::process function:
vector3d testresult;
vector2d testinput(745.607117,8.250000);
camera_parameters.image2field ( testresult,testinput,30.000000);
printf("test result: %f %f %f\n",testresult.x,testresult.y,testresult.z);
This code will produce the wrong coordinates in the center of the field:
test result: -1535.504509 -65.603917 30.000000
Interestingly, if only slightly changing the input pixels it actually provides a
(presumably) correct result:
vector3d testresult2;
vector2d testinput2(744.71,8.33);
camera_parameters.image2field ( testresult2,testinput2,30.000000);
printf("test result2: %f %f %f\n",testresult2.x,testresult2.y,testresult2.z);
test result2: -3680.968314 2650.294122 30.000000
So the bug is likely some instability in image2field.
Original comment by zick...@gmail.com
on 31 Mar 2010 at 1:27
With revision r185 this should now be fixed.
Technical details of the bug:
let r_d and r_un be the distorted and undistorted (respectively) radii from the
image
principal point.
The radial distortion model prior to r185 was:
r_d = r_un*(1 + distortion*r_un*r_un)
Since the radial distortion observed is of the barrel type, for this distortion
model, distortion assumes negative values. Hence, there are values of r_d for
which
r_un assumes complex values only. Since the estimation of r_un was a numerical
one,
it was unstable for these values of r_d.
The correct distortion model, implemented in r185 is:
r_un = r_d*(1 + distortion*r_d*r_d)
This relation is monotonically increasing, and one to one over the set of
reals, so
for every real value of r_un, there exists a unique real value of r_d. Of
course, it
is also easy to see that for every real value of r_d, there exists a real value
of
r_un. The distortion (r_un to r_d) is computed in r185 by analytical solution
of the
cubic equation.
Original comment by joydeep....@gmail.com
on 1 Apr 2010 at 7:42
Correction:
For the model in r185, [ r_un = r_d*(1 + distortion*r_d*r_d) ] , the relation is
monotonically increasing and one to one over the set of reals only for
non-negative
values of distortion. This is indeed the case, because for the barrel type of
distortion that is observed, distortion must be non-negative.
Original comment by joydeep....@gmail.com
on 1 Apr 2010 at 7:47
Original issue reported on code.google.com by
joydeep....@gmail.com
on 30 Mar 2010 at 5:31