Phantom Balls Detected

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download the recorded frames from
http://www.cs.cmu.edu/~robosoccer/small/movies/ssl-vision-data/PhantomBalls.tar.
gz
2. Extract the archive to some folder
3. Load the folder from the DVR recorder
4. Use the DVR recorder to play back frames from the folder

What is the expected output? What do you see instead?
Espected output: The ball should be reported at a single static location
(from the images and the thresholded data, it seems to be quite obvious)
Output seen: In certain frames (they keep changing), "phantom" balls are
reported at locations which certainly do not have any balls or ball-like
objects. The locations of the phantom balls seem to vary between different
trials.

Original issue reported on code.google.com by joydeep....@gmail.com on 30 Mar 2010 at 5:31

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

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