Framer Look Vector Fix

[acpaquette]

Brings framer look vector computation inline with LS model look vector computation. The only change I am unsure of is the negation of the look vector in imageToRemoteImagingLocus.

It seems like the "correct" change comparing to the line scanner but it could use a second set of eyes.

[acpaquette]

@oleg-alexandrov If you could give this a review that would be amazing!

[oleg-alexandrov]

I noticed a quirk with the look vector along the lines you are trying to remove exists in the Frame model when working with MSL. I chose to adjust things on my side to get expected results with the current code.

Will this change break existing camera models?

One may need to validate for a handful of Frame camera models, such as for Dawn, that the look vector was pointing away and now it is pointing towards the planet.

[acpaquette]

@oleg-alexandrov It may, I will do some manual verification through knoten to see if this breaks the camera models

[oleg-alexandrov]

The issue you see may not be an accident, but it may be due to how the sensor plane is interpreted. Sometimes it is behind the camera center. If you are encountering issues with MSL and not with other sensors, it may be simpler to tweak ale's MSL driver and not the others. (My branch I think applies the proper adjustment to cahvor.)

In either case, that the rays go away from the planet may cause problems with mapproject, though not with stereo triangulation for example, which can triangulate rays either way.

[acpaquette]

@oleg-alexandrov After a little more experimentation I agree with you on the larger fix likely being in the cahvor model/msl driver in ALE. There is still a significant discrepancy between how imageToRemoteImagingLocus computes the look vector vs how imageToGround computes the look vector. In examining them further, the look vectors are only accurate to the 8th decimal place.

Given the above code snippet, comparing the position of the spacecraft/rover to the ground coord computed the look vector seems correct ie matches the look vector compute by imageToRemoteImagingLocus. However the ground coord we get from surfpt given position and look vector is extremely different than the ground coord we compute in imageToGround. Looking into the csm logs the look vector we compute in imageToGround for the image I am using at 0.5, 0.5 is -9.71032, -23.2575, -23.7358, normalizing that vector I get:

That is comparing the look vectors, as I mentioned above it's only accurate to the 8th decimal place resulting in very different ground coordinates. I have checked the rest of the math and everything up until the look vector computation is correct. Just to clarify this is produced with USGSCSM that does NOT contain the above changes. Something is going on with the look vector between the two functions. I think the way forward here is picking one way to compute the look vector and changing it in one of the two functions.

[oleg-alexandrov]

Not sure. One may want to examine the two functions imageToRemoteImagingLocus and imageToGround and see what they do differently, starting with the input camera center and rotation matrix (and first verify if those two inputs are identical for these two functions).

As I see in the code, these start rather similar, with undistortion and then a rotation. Then there's an intersection with the ellipsoid in one of them.

One could try to dump some intermediate results in the C++ implementation and see where these differ.

A possibility may be that arithmetic operations that involve large numbers is the problem, given that the camera coordinates has numbers on the order of one million.

Likely unrelated to this, the Cahvor matrix is also stored only with float precision, so whether one normalizes the rotation matrix to have determinant exactly 1 or not can also result in a 1e-8 error.

[acpaquette]

Closing this, with help from @oleg-alexandrov I was able to get a rotation in ALE that doesn't require changes in USGSCSM