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

[MaxSt]

I understand that left and right rays only in theory should intersect at some distance.

But I wonder what's the usual error, in practice? If you shift left and right pointers vertically just a little bit, you should be able to assure the ray intersect. Just how much shift is needed, in terms of pixels or maybe degrees?

[algorimancer]

I understand that left and right rays only in theory should intersect at some distance.

But I wonder what's the usual error, in practice? If you shift left and right pointers vertically just a little bit, you should be able to assure the ray intersect. Just how much shift is needed, in terms of pixels or maybe degrees?

That's one of those problems which is going to have infinite solutions. If you held the ray from one camera constant, you could adjust the other camera's ray to achieve a perfect intersection. But you could move that ray about the plane spanned by the first ray and the origin of the second ray, and find infinite solutions along it. And of course there's no reason to assume that the first ray is the one to be fixed, which adds additional dimensions to the problem. It's basically a matter of constraining the error of the rays and saying that if each of the rays is allowed so much error in orientation, then the solution space is constrained to something like the intersection of two cones (where the apexes of the cones are the cameras' principal points).

In addition to the Analyse dialog giving the error allowing for +/- 0.5 pixels, the provided figure for intersection gap is a measure of the distance between the intersecting rays, so to figure how many degrees that corresponds to, simple trigonometry would be to take the inverse tangent of (half the gap distance divided by the range distance).

A few checks w/ Opportunity's navcam (pixel size is 0.04686770 degrees) give offsets of between 0.002 and 0.04 degrees.

Likewise w/ Spirit's pancam (pixel size 0.01600068 degrees) yield offsets of between 0.003 and 0.011 degrees.

This seems to further confirm that sub-pixel precision is being achieved. Someday it might be nice get a bunch of users to measure a bunch of objects, then combine the results and get a good sense of the true statistical error involved.

[MaxSt]

But you could move that ray about the plane spanned by the first ray and the origin of the second ray, and find infinite solutions along it.

Well, I mean if shift only vertically... should be one solution.

This seems to further confirm that sub-pixel precision is being achieved.

Oh, that's good. I tried to do something like that myself, but I'm getting much bigger vertical errors...

[algorimancer]

Oh, that's good. I tried to do something like that myself, but I'm getting much bigger vertical errors...

Try zooming in before selecting points. I find this can get me down to better than half a pixel error most of the time (optimistically half that). I tend to zoom in about ten times prior to selecting important points. Lot's of times no zoom at all yields adequate results, just depends what you're up to.

[MaxSt]

Try zooming in before selecting points.

No, I mean bigger errors with my own implementation... Something wrong with my CAHVOR model...

I wonder how they do "linearization" of pictures? Their results are very good, but when I tried that myself, I couldn't figure out how to select new CAHV vectors.

[algorimancer]

No, I mean bigger errors with my own implementation... Something wrong with my CAHVOR model...

I wonder how they do "linearization" of pictures? Their results are very good, but when I tried that myself, I couldn't figure out how to select new CAHV vectors.

If you get stuck on your CAHVOR model I'd be happy to share some tips or code with you, but I know it's more satisfying to figure out yourself.

I have little experience with transforming images (other than using existing software), so I'm not sure how I'd go about linearizing one. Seems like you might be able to use the existing CAHVOR model and just choose to project to a sphere rather than a plane, or something to that effect. I don't have a good mental model of what needs to happen.

[MaxSt]

If you get stuck on your CAHVOR model I'd be happy to share some tips or code with you, but I know it's more satisfying to figure out yourself.

True, true... Besides, you probably implemented photogrammetric model, and I'd like to work with actual CAHVOR vectors.

I have little experience with transforming images (other than using existing software), so I'm not sure how I'd go about linearizing one. Seems like you might be able to use the existing CAHVOR model and just choose to project to a sphere rather than a plane, or something to that effect. I don't have a good mental model of what needs to happen.

Well, I think they project object rays back a plane, which is defined by new CAHV vectors. The same plane for both cameras (in the case of navcams). So when I look at the pair of their linearized images, they fit each other very well - the objects far far away have the same coordinates on both images, and objects close to the rover are always on the same row. I guess their error is much less then a pixel.

[algorimancer]

True, true... Besides, you probably implemented photogrammetric model, and I'd like to work with actual CAHVOR vectors.

Actually my approach was indeed via the CAHVOR vectors, using that information combined with some simple vector analysis. I plug in a pixel coordinate, out comes a corresponding real-space vector emerging from the camera. I define a line originating at the coordinates of the C in the CAHVOR model, with the vector specifying the direction. Same for the other camera, then I find the approximate intersection of the two lines (points on each line where they're othogonal to each other, and I settle for the midpoint between those points as the photogrammetric point). I don't do any conversion to a separate photogrammetric model, I just work with what CAHVOR gives me. I have a copy of a paper somewhere which describes converting from CAHVOR to a specific photogrammetric model, but my sense is that the only purpose was to validate their equivalence.

[SteveM]

... I have a copy of a paper somewhere which describes converting from CAHVOR to a specific photogrammetric model, but my sense is that the only purpose was to validate their equivalence.

I suspect you mean Di and LI, "CAHVOR camera model and its photogrammetric conversion for planetary applications," JOURNAL OF GEOPHYSICAL RESEARCH, VOL. 109.