Systemic Errors in CTX at the top (start or stop?) of images when generating ground points

[jlaura]

Issue Description

CTX (line scan sensor model) is behaving strangely at the top of images.

Examples

I am seeing consistent, systematic errors at the top of CTX images using the CSM. These errors are evident when using the sensor model to project from the image to the ground. In the attached images, the pink pluses (+) are a grid of points at every 1000 pixels in the image, projected to an BCBF coordinate. Note the extreme shift in the uppermost set of points in this first image (B05_011720_1832_XN_03N217W).

In the next image (B04_011377_1843_XN_04N212W), the effects are less pronounced at the top of the image. Instead, note how eight rows from the bottom, the regular grid suddenly widens. Points on the left (west) side of the image maintain good ground alignment while points on the right (east) side are incorrect.

Finally, here is an example (B01_010018_1993_XN_19N191W) where the top rows of points are incorrect and are 'wrinkled' significantly to the top-right (NE). This is in contrast to the first example where the points shift dramatically to the left.

Processing Steps

• spiceinit from=lvl0 shape=ellipsoid
• gen_csm - to create the ISD file using the gen_csm.py script described by the ASP team.
• Knoten generate_ground_point using a high resolution DEM to compute the BCBF position of the intersection via the CSM. (I can provide the notebook and DEMs if desired).

Environment

ale                       0.8.7           py310h91b1402_1    conda-forge
csm                       3.0.3.3              hc9558a2_0    conda-forge
cspice                    66                h7f98852_1015    conda-forge
isis                      6.0.0                         0    usgs-astrogeology
usgscsm                   1.6.0                h924138e_0    conda-forge

Attachments

ISDs.zip

[oleg-alexandrov]

Some simple sanity checks here (without using logic for generating ground points) could be:

• Use cam2map on the .cub file. If things are so bad in the ISIS camera model as well, the result should be very distorted
• Compare the ISIS and CSM image-to-ground and ground-to-image logic. There's an example here: https://stereopipeline.readthedocs.io/en/latest/tools/cam_test.html. This uses an ellipsoid rather than a DEM, but its height above the nominal Mars datum can be customized to agree with your DEM.

One could also try to do stereo with a well-behaved and poorly behaved CTX image, and inspect the DEM and error image (output of point2dem --errorimage), which would make use of results of triangulation, so projection from image to ground.

Here of course talking about the tools I am familiar with. Maybe going directly to your knotten notebook may be faster.

On my side I've worked with LRO NAC CSM very exhaustively in the last month or so, on more than 800 images. There's some jitter, but no weirdness as you see. This would be interesting to track down.

[jlaura]

@oleg-alexandrov Thanks for the suggestions. I was having similar thoughts about how to isolate this yesterday afternoon.

The map projected images do not look warped as one would expect if the ephemeris information was not good. These were projected via the ISIS sensor though, so that really only validates the input SPICE.

Next, I did a sanity check on the ground to image logic into the DEM. The images below demonstrate that that is where the error is. This is simply calling the CSM, so this appears to be a knoten problem. The images below are the same three areas, with identical grid spacing. In this test, I set the height above the ellipsoid inside of the knoten generate_ground_point to zero. Therefore, the grids are projected onto the ellipsoid. Notice how the systematic errors completely disappear! Pending feedback, it seems that this issue needs to be migrated over to knoten.

Height above the ellipsoid 0

   

Original images; Height above the ellipsoid from DEM.

   

[jessemapel]

Yeah this looks like you are hitting the edge of a DEM pixel. I don't know if the knoten code is interpolating at all, but doing at least a bilinear interpolation on the DEM may fix this issue. I'm going to close this here as it doesn't appear to be a problem with the library or the model.

[jlaura]

@jessemapel I am reopening this over here on Knoten as it seems to be an issue inside of the generate_ground_point function. I will continue to work on the issue over here.

I am not convinced that the issue is interpolation within the DEM, because the underlying DEM is a 20mpp ASP generate DEM (not a MOLA scale DEM). Having said that, I will test. When you are suggesting interpolation, are you suggesting a bilinear interpolation inside of the generate_ground_point function grabbing elevations from surrounding pixels or are you suggesting straight up smoothing the DEM?

[oleg-alexandrov]

You can try smoothing the DEM and then regridding it with with bicubic interpolation at 1 m/pixel with gdalwarp -r cubicspline just to see how the existing code handles a much higher resolution smooth DEM.

[jlaura]

I tested with an upsampled DEM and the results are the same. I suspect that this is in the logic for generate_ground_point. I am testing that now by comparing the output of generate_ground_point and an ISIS sensor model using the same high-resolution DEM.

Found it! Inside the generate_ground_point function a latlon_to_pixel call is made. That call can return line/sample locations that are outside of the DEM bounds. Here are the pixel coordinates, followed by iterations of image2ground where valid pixel locations and DEM heights are being returned and then where invalid pixel locations and the dataset no data value are being returned.

Valid

4000 7000
21446 742 -2692.362
21653 720 -2692.4055
21653 720 -2692.4055

Invalid

1000 8000
4741 -3284 -32767.0
5158 -3292 -32767.0

The generate_ground_point code has no check to ensure that the pixel location in the DEM is valid (either because it is inbounds or because it is not the DEM defined NDV).

@jessemapel and @oleg-alexandrov were both correct, that this is occurring because the data are stepping off of a DEM pixel. In this case, the 'step' is from a valid height to a NDV 'height'.

One can see how ISIS solves this running campt where the reported error states: "Requested position does not project in camera model; no surface intersection". I think it makes the most sense to catch this error in knoten and have generate_ground_point provide an error if no valid height can be extracted. The other option is to alter plio such that pixel locations outside the image do not simply return the NDV. Input solicited about where folks think the fix should be made.

I am leaning towards both places because both are wrong for different reasons.

[jlaura]

This is super old. I believe this has been fixed with better DTM intersection code.

[oleg-alexandrov]

Could be nice to revisit, maybe, if doing related work, once the DTM intersection code is pulled in.

[jlaura]

I think that this is the fix, assuming one is using a surface from here.

[oleg-alexandrov]

Ah, I see. I assumed it was the unrelated logic in ISIS for intersecting with a DTM. Thanks for clarifying.