GXP matching is acting very strange using usgscsm (github build 0.1.436)

[thareUSGS]

Setting up the project and load two images from Mars2020_Jezero_N.

Loaded HiRISE *.cub (not available tiffs).
DTM for seed is available in attached zip file (can get original cube also).

Logfile was initialized from a Dos Batch file:

SET USGSCSM_LOG_FILE=C:\temp\usgscsm.log
start C:\"Program Files"\"BAE SYSTEMS"\"SOCET GXP 4.5.0"\Exe\StartSocetGxp.exe

Configuration settings for the images was defined using "hirise_setting.png" in attached zip file.

Used Adaptive Tie Point Matcher (quick strat) since Automatic Point Matcher would return nothing. Anyway with ATPM, only 2 (2 pairs) were matched. 36 (2 pairs) were not successful. See Jpeg in the zip file for point locations (even though most failed).

I have not really dug into the resulting log but there is an odd seemingly fall back to an "IdealSpacecraft" m_sensorIdentifier: "IdealCamera" . Also at the top there are some initial construction errors:

[2022-07-29 13:51:29.273] [usgscsm_logger] [info] Creating UsgsAstroFrameSensorModel
[2022-07-29 13:51:29.273] [usgscsm_logger] [info] Resetting UsgsAstroFrameSensorModel
[2022-07-29 13:51:29.273] [usgscsm_logger] [info] Constructing state from isd
[2022-07-29 13:51:29.371] [usgscsm_logger] [info] Constructing state from isd
[2022-07-29 13:51:29.385] [usgscsm_logger] [info] Constructing state from isd
[2022-07-29 13:51:29.551] [usgscsm_logger] [info] Sensor position does not have 3 values, UsgsAstroFrameSensorModel::constructStateFromIsd()
[2022-07-29 13:51:29.551] [usgscsm_logger] [info] Sensor velocity does not have 3 values, UsgsAstroFrameSensorModel::constructStateFromIsd()
[2022-07-29 13:51:29.561] [usgscsm_logger] [info] Sensor position does not have 3 values, UsgsAstroFrameSensorModel::constructStateFromIsd()
[2022-07-29 13:51:29.561] [usgscsm_logger] [info] Sensor velocity does not have 3 values, UsgsAstroFrameSensorModel::constructStateFromIsd()
[2022-07-29 13:51:32.238] [usgscsm_logger] [info] Sensor quaternion does not have 4 values, UsgsAstroFrameSensorModel::constructStateFromIsd()
[2022-07-29 13:51:32.391] [usgscsm_logger] [info] Sensor quaternion does not have 4 values, UsgsAstroFrameSensorModel::constructStateFromIsd()
[2022-07-29 13:51:32.451] [usgscsm_logger] [info] ISD is invalid for creating the sensor model.
[2022-07-29 13:51:32.590] [usgscsm_logger] [info] ISD is invalid for creating the sensor model.

Lastly, I wonder if we are trying to push too many ephemeris_times in the ISD (for GXP). Just a thought.
usgscsm_adaptiveTiePointMatcher_quickStrat_4pointsSuccessful_78not.zip

[jessemapel]

The failures you are seeing is GXP trying to initialize a frame sensor model. It has to go through all of the different models and try each one by one to see if it works. I would be surprised if we're pushing through too much data in the ISD. We've never had an issue with this before and we've worked with some very very large images.

[oleg-alexandrov]

I took a look at the log file. I hope you folks don't save that by default, the amount of detail is just outrageous.

It looks that eventually the library managed to load the right model, as I see lots of quaternions being printed and other good stuff.

So, I don't think the problem is your camera models. You can test them, if you want, with usgscsm_cam_test, but they are likely sound.

Most likely your images actually don't have enough matches, or something else is wrong with your dataset, rather than the camera model.

Are you having any luck with another image set? Can you examine your images and see if they actually look similar enough?

[thareUSGS]

No, we only want to create that log for debugging. It should be available in ASP/ISIS also (by setting that env. variable).

This is confusing behavior for GXP as we chose this pair because they worked really well in Socet SET (both initial image matching for triangulation and stereo) and if I'm not mistaken these images have worked well in previous versions using usgscsm. The hard part is the version of GXP and usgscsm have continued to evolve, so it has been hard to nail it down. Although, I am pretty confident that the image matching, triangulation and stereo methods in GXP have not changed much in the last few years. We have rolled the usgscsm version back a few times in GXP, but we might need to go further back to help track this odd image matching behavior down... I will try to roll back as far as I can and see what happens.

[jessemapel]

The logging is only for extreme debugging purposes like GXP where we what is happening with the camera model is a black box. #301 is aimed at making it more user friendly.

[jessemapel]

I looked into the logs a bit more and I don't see anything out of the ordinary. It properly sets up the models and then does some image to ground and ground to image calls within the image extents.

The information about an ideal_camera is because the HiRISE images you are using have been converted to an ideal camera. The HiRISE dejittering step converts to ideal cameras.

I think you'll need to reach out to BAE to get more help here. The model seems to be doing everything correctly. I'll try adding some more logging levels and see if we see anything at a higher level.

[thareUSGS]

Triangulation log using the latest artifact usgscsm v0.1.570 (*.dlls). Similar results (as previously posted) with regards to percentage of successful matches.
usgscsm_adaptiveTiePointMatcher_quickStrat_10pointsSuccessful_178not.zip

[jessemapel]

I'm going to close this as with DOI-USGS/ale#480 and #417 we have resolved this.