[X] My Assistant

[helvick]

Just setting this up as a topic.

Rodolfo (RNeuhaus) has pointed out that he gets hard to interpret results when using Joe Knapp's online Parallax Calculator.

I don't know the formulas behind this calculator but have been trying to work out my own.

Taking (for now) that the geometries are as follows:
Pancam, 16deg FOV, 300mm separation between L and R and a 1deg toe in.
Navcam, 45deg FOV 200mm separation between L and R and no toe in.

Parallax formula - Distance to object=half the Camera Separation/Tan angle between the point in the L+R images. (I don't think this is 100% correct for parallel cameras but it should be good to a close first approximation provided things aren't too close).

Sticking with the Navcam which doesn't have any toe in my gut feel for things is that distant objects should be affected less by parallax. So taking Joe Knapps sample calculation for Navcam. Left Camera 512 pixels, right camera 500 pixels.
Separation is 12 pixels so the parallax angle is 12 * (45deg/1024pixels) = 0.527344 degrees.
The distance should then be (100mm/tan(0.527344 deg).
That gives me 108m.
Joe Knapps calculator gives me 20.3m.

The Pancam is a bit trickier because of the toe in angle, I need to think a bit more about whether my default assumption that it can be compensated for by simply subtracting 64 pixels from the right image position is valid or not.

Anyway - something is amiss in either my numbers or Joe Knapp's calculator. Anyone out there able to throw some light on this.

[algorimancer]

Updated AlgorimancerPG photogrammetry and rangefinding application to version 2.1. The main change is the ability to save accumulated calculated results to a textfile, similar to the way this was handled by the batch procession utility before. Still haven't added a selection utility, still mentally deciding how best to handle that.

http://www.clarkandersen.com/RangeFinder.htm

[dilo]

Nice software. However, I have impression that error on distance is widely sub-estimated (using Parallax Calculator I obtained higher, more reasonable numbers)...
I would like to better know the coordinate system (xyz) you are using and I would like to precisely select points throug cross-air, instead the Windows pointer...
Thanks.

[algorimancer]

Nice software. However, I have impression that error on distance is widely sub-estimated (using Parallax Calculator I obtained higher, more reasonable numbers)...
I would like to better know the coordinate system (xyz) you are using and I would like to precisely select points throug cross-air, instead the Windows pointer...
Thanks.

Thank you.

The error is indeed sub-estimated. The way this works is, based upon the camera models I am able to extract a unique sight-vector normal to the center of the selected pixels and originating from a known point for each camera. These vectors and the originating points are in the coordinate system in which the masthead was calibrated; there is no consistent correspondence to the rest of the rover or the ground, since the camera moves. The results are self-consistent for a particular stereo pair, but not with other stereo pairs (additional transformations of the coordinates would be required). The resulting coordinates I have (by request) transformed so that the x & y axes are generally aligned with those of the images as viewed in a monitor (x is + right, y is + up), and the origin is the midpoint between the cameras principal points. Since the cameras are not oriented in parallel (there are rotations about 3 axes relative to each other), there are some aspects of the coordinates derived from the images which are less than intuitive, however everthing seems self-consistent.

As to the error... I find the photogrammetric position from the input pixels as the approximate intersection of the two resulting lines based upon the cameras principal points and the pixel-intersecting vectors. I say approximate intersection because a true intersection will never actually happen, what I find is the midpoint between those lines, and the error reported is the actual minimum distance between the lines (I state all this somewhere in the documentation). Something closer to the true error would be to take this minimum distance and add to it the size of 1 pixel at that range (also given in the results). And of course it is only as accurate as the pixels chosen by the user, so multiply that pixel size by however many pixels of precision are managed. I'm sure someone who does photogrammetry professionally could come up with a better measure of accuracy, I'm just going on geometry.

As to the difference in error between this application and the parallax finder application, the major difference is that I'm calculating in 3D and the parallax finder app is working in 2D, so the majority of the accuracy difference would lie there. I'm also using the very good camera calibration data acquired in the lab prior to the launch. Taking all of that into account, the given errors (adding in pixel size at range) seem reasonable, as is the difference in results between the two applications. I might add that all the position, range, distance, and error results given by my app are in meters, which may make the error seem smaller than it is. An error of 0.5 sounds good until you think in terms of measuring the size of a meter scale object.

A cross-hair point selector sounds like a good idea, I'll look into that.

[dilo]

Thanks for the infos, algorimancer.

About the error estimation, now I understand your method and the difficulty to work in 3D instead 2D, with never-intersecting lines (!).
Your considerations are valid in the plane perpendicular to the line of sight (the XY plane, approximately).
But in the Z (distance) direction you are forgetting to add the uncertain arising from small parallax angle errors, which is by far the main error factor for distant objects!
You will agree that a very small azimut error must introduce a huge distance error for a far, small-parallax object close to horizon. At the limit, when parallax angle is comparable or smaller than angle covered by a pixel, this effect becomes dramatic! This should happens for ranges of about 300m (NavCam) or 1Km (PanCam).
Now look to this plot of the ranging error as a function of distance for the MER stereo cameras, assuming a 0.25 pixel stereo correlation accuracy (from MAKI ET AL.: MARS EXPLORATION ROVER ENGINEERING CAMERAS):

To estimate this z-direction error, you can start from this plot but multipling error by 2 at least...
Or, you can use empiric calculation method, considering many alternative rays located 0.5 pixels around original ones and then report the range for XYZ positions separately (a little bit complicated, but I like it).