Closed thareUSGS closed 2 years ago
@oleg-alexandrov Please review issue. Note for some reason I couldn't assign you to the ticket (not that you need to work on this).
It looks like the last lines of .sup files are formatted the same way as the output model states. I was able to strip special characters with sed $'s/[^[:print:]\t]//g'
, which hopefully won't be too hard to mimic in cpp.
Since UsgsAstroPlugin::constructModelFromState deals with strings (not files), I don't think we should make any changes to UsgsAstroPlugin::constructModelFromState -- I think we should provide a helper function to scrape the state string from a .sup file, which should just be a matter of:
This helper function might fit in Utilities.cpp alongside stateAsJson
or in usgscsm_cam_test as a modification to readFileInString()
.
Sorry. I saw one of Trent's emails from 11 AM or so, and then I got pulled into unrelated work and failed to check my GitHub notifications for the rest of the day.
I broadly agree with Austin. One can make some little modifications to existing usgscsm_cam_test logic to read such a state file. First, read the whole file in one string, then use std::find to find the occurrences of SENSOR_STATE. Note that there are two such occurrences, and the second should be found. Then one advances by a few characters and the "substring" function in C++ can be used to collect only the portion from there to the end of the line.
As to the special character, the C++ function isprint() can be used to find if a character in a string is printable, and if not, ignore it. So, this will require processing the string character by character, and appending the printable characters to another string.
After that, one can continue with the existing logic.
To add, I think one has to have new functions in UsgsAstroPlugin.h analogous to canModelBeConstructedFromState() and constructModelFromState(), for handling .sup files, and they will only isolate the right substring and call the "state" functions mentioned right before. Then, these new functions be called by any user of the library, including ASP, ISIS, and the test executable.
Then a .sup testfile should be added to the list of regression testcases, and a handful of lines need to be added to usgscsm/tests/CMakeLists.txt having usgscsm_test load such a .sup file, also analogous to how this tool now adds ISD and state files.
background: GXP saves camera state as a single string near the bottom of its' "sup" (supplement) file per image. The .sup is only created when a triangulation is initialized and again after each triangulation solve (bundle adjustment). Three new files have been uploaded to a gxp_testing branch to facilitate this issue (files ESP_037330.) : https://github.com/USGS-Astrogeology/usgscsm/tree/gxp_testing/tests/data
From the .sup files, we are only interested in the SENSOR_STATE USGS_ASTRO_LINE_SCANNER_SENSOR_MODEL line. This again contains one giant camera state string. It seems to have an odd or special character "" which may need to stripped before attempting to load into usgscsm.
As a user I would like the usgscsm library to be able to parse a GXP .sup file to load the camera state. The goal is to allow sharing between GXP and other CSM applications like ASP and ISIS. The usgscsm camera state would need to open GXP .sup file, recognize it is a GXP .sup file, find/parse the camera state line, and load it into usgscsm.
definition of done (being able to run):
usgscsm_cam_test --model ESP_037330_1990_REDmos_hijitreged_postTriang.sup
If loading is possible, then I would also like to see testing from within usgscsm test application (usgscsm_cam_test.cc). Examples for using the testing application are already available in the repo.
If it is not possible to load a camera state from a .sup file, please document the issues here. For example, is the camera state mangled or other issue.
This is currently a one-way street. We are not attempting to support writing camera state to a GXP .sup file (just reading).
Resources: