Csmcsv #4446

jessemapel · 2021-05-11T04:13:26Z

Description

Updates BundleAdjust to output separate Images CSV files for each sensor. This solves the issue of mismatched columns when different images are solving for different parameters. Currently when different parameters sets are being solved for only the very first observation's parameters are represented in the header and the images CSV is malformed with variable numbers of columns on each line.

Related to #4410

Examples

This impacts CSM bundle, multi-sensor bundle with and without scconfig, and held images. Here's a few examples and how this impacts them:

CSM bundle

If you are bundle adjusting with multiple CSM sensors, then each CSM sensor will have a separate images CSV containing the updates for that sensor's image parameters.

Multi-Sensor bundle with scconfig

If you are bundle adjusting with multiple ISIS sensors using scconfig, then each separate entry in your scconfig will result in a separate images CSV. For example, the following scconfig:

Object = SensorParameters
  Group = MARS_ODYSSEY/THEMIS_IR
    CamSolve=accelerations
    OverExisting=yes
    Twist=yes
    camera_angles_sigma=.25
    camera_angular_velocity_sigma=.1
    camera_angular_acceleration_sigma=.01
    SPSolve=none
  EndGroup
  Group = VIKING_ORBITER_1/VISUAL_IMAGING_SUBSYSTEM_CAMERA_B
    camsolve=angles
    Twist=yes
    camera_angles_sigma=1.0
    SPSolve=none
  EndGroup
  Group = VIKING_ORBITER_2/VISUAL_IMAGING_SUBSYSTEM_CAMERA_A
    camsolve=angles
    Twist=yes
    camera_angles_sigma=1.0
    SPSolve=none
  EndGroup
EndObject
End

You will have 3 images CSV files:

bundleout_images_MARS_ODYSSEY_THEMIS_IR.csv
bundleout_images_VIKING_ORBITER_1_VISUAL_IMAGING_SUBSYSTEM_CAMERA_B.csv
bundleout_images_VIKING_ORBITER_2_VISUAL_IMAGING_SUBSYSTEM_CAMERA_A.csv

Multi-Sensor bundle without scconfig

For example if you are bundle adjusting a set of LRO NAC images that contains both NAC left and NAC right images you will still get separate images CSV files:

bundleout_images_LUNARRECONNAISSANCEORBITER_NACL.csv
bundleout_images_LUNARRECONNAISSANCEORBITER_NACR.csv

Even if you are solving for the same parameters for both sensors.

Held images bundle adjustment

If you are holding some images fixed using jigsaw's HELDLIST parameter then you will have one images CSV file your your held images called bundleout_images_held.csv and another images CSV file for the rest of your images. The name of your non-helf images CSV will again contain the spacecraft and sensor name.

Testing

The following tests are expected to fail due to updated truth data:

jigsaw_app_test_radar (Failed)
jigsaw_app_test_scconfig (Failed)
jigsaw_app_test_scconfigHeld (Failed)

…smcsv

jessemapel · 2021-05-11T04:14:27Z

isis/src/control/apps/jigsaw/tsts/scconfigHeld/Makefile

+          > $(OUTPUT)/bundleout_scconfig_images_viking_2.csv;
+	$(CAT) bundleout_images_held.csv \
+          | perl -pe 's/(^|,|: )([^,:]+\/)([^,\/:]*\.)(net|cub)/\1\3\4/g' 2> /dev/null \
+          > $(OUTPUT)/bundleout_scconfig_images_held.csv;


This is a good example of what the new output can look like. This test has THEMIS images, Viking 1 images, VIking 2 images, and a held image.

isis/src/base/objs/CSMCamera/CSMCamera.cpp

jessemapel · 2021-05-11T04:15:17Z

isis/src/control/objs/BundleResults/unitTest.cpp

      }

+      QFile m_file;
+


This is a small fix to an unrelated issue where this file never got cleaned-up.

jessemapel · 2021-05-11T04:16:34Z

isis/src/control/objs/BundleSolutionInfo/BundleSolutionInfo.cpp

+          // Accumulate all of the images from previous observations
+          for (int obsIndex = 0; obsIndex < observationIndex; obsIndex++) {
+            imgIndex += m_statisticsResults->observations().at(obsIndex)->size();
+          }


I want to make this part better, but it'll be a lot of work to modify the RMS vectors so I'm starting with this change.

jessemapel · 2021-05-11T04:17:45Z

isis/src/control/objs/BundleSolutionInfo/BundleSolutionInfo.cpp


+        for (int k = 0; k < numImages; k++) {


This triple nested for loop isn't as bad as it looks because collectively it still just iterates over all the images. We just split the images up into 3 different tiers of sets. First we separate by instrument ID, then by observation, then by image.

jessemapel · 2021-05-11T04:18:32Z

isis/src/control/objs/BundleSolutionInfo/BundleSolutionInfo.h

@@ -13,6 +13,7 @@ find files of those names at the top level of this repository. **/
 #include <QObject>
 #include <QString>

+#include "AbstractBundleObservation.h"


This could be forward declared as a typedef but that's rather ugly, can be confusing, and even cause errors; so I just included it.

isis/src/control/objs/BundleSolutionInfo/BundleSolutionInfo.truth

jessemapel · 2021-05-11T04:20:06Z

isis/src/control/objs/BundleUtilities/AbstractBundleObservation.h

@@ -92,7 +92,6 @@ namespace Isis {
      //! Map between cube serial number and BundleImage pointers.
      QMap<QString, BundleImageQsp> m_cubeSerialNumberToBundleImageMap;
      QStringList m_serialNumbers;      //!< List of all cube serial numbers in observation.
-      QStringList m_parameterNamesList; //!< List of all cube parameters.


I don't want to have to store a whole bunch of strings for each observation, so I decided to just dynamically generate this for memory efficiency. It requires the same amount of code as generating and then saving them off anyway.

jessemapel · 2021-05-11T04:20:53Z

isis/src/control/objs/BundleUtilities/BundleObservation.cpp

+  // so always do at least 1
+  int numberCamPosCoefSolved = std::max(
+      solveSettings()->numberCameraPositionCoefficientsSolved(),
+      1);


I do not like this but it's needed to preserve functionality. Ideally, this wouldn't be here and the twist would not be there if we weren't solving for it, but that's not the current functionality for the output files.

jessemapel · 2021-05-11T04:22:17Z

isis/src/control/objs/BundleUtilities/BundleObservationVector.cpp

+      // update instrument ID to observation ptr map
+      // separate held observations out into their own entry
+      if (bundleObservation->numberParameters() == 0) {
+        m_instIdToObservationMap.insertMulti("held", bundleObservation);


This is how we generate a separate images.csv for held images. This works for the scconfigHeld test, but not for FunctionalTestJigsawHeldList I haven't figured out why yet.

jessemapel · 2021-05-11T04:22:38Z

isis/src/control/objs/BundleUtilities/BundleObservationVector.cpp

+    for (int i = 0; i < size(); i++) {
+      numParameters += at(i)->numberParameters();
+    }
+    return numParameters;


@kberryUSGS There's a chance you already made this change.

I did this a bit differently locally, but your version is better, taken along with your other changes.

jessemapel · 2021-05-11T04:24:24Z

isis/tests/FunctionalTestsJigsaw.cpp

+  EXPECT_NEAR(elems.at(56).toDouble(), 0.365064224,       0.00001);
+
+
+  QFile rightFile(prefix.path() + "/bundleout_images_LUNARRECONNAISSANCEORBITER_NACR.csv");


This test is an example of how the new images.csv output could be annoying. The NACL and NACR are two copies of the same system and we would solve for their images exactly the same way, but because they are actually different instrument IDs, we will output two images.csv files when we don't need to.

I want to talk to some users to see how they feel about this change.

That sounds like a great idea. If it does turn out that the users don't like this, is there a straightforward way to produce just one output CSV in the case where the solve parameters are identical?

…smcsv

krlberry

This looks good to me. Some comments / questions.

isis/src/control/apps/jigsaw/tsts/scconfigHeld/Makefile

isis/src/control/objs/BundleSolutionInfo/BundleSolutionInfo.truth

isis/src/control/objs/BundleUtilities/BundleUtilities.truth

krlberry · 2021-05-11T15:50:26Z

isis/tests/FunctionalTestsJigsaw.cpp

+  EXPECT_NEAR(elems.at(56).toDouble(), 0.365064224,       0.00001);
+
+
+  QFile rightFile(prefix.path() + "/bundleout_images_LUNARRECONNAISSANCEORBITER_NACR.csv");


That sounds like a great idea. If it does turn out that the users don't like this, is there a straightforward way to produce just one output CSV in the case where the solve parameters are identical?

krlberry · 2021-05-12T15:17:16Z

isis/src/control/objs/BundleUtilities/BundleObservationVector.cpp

+    for (int i = 0; i < size(); i++) {
+      numParameters += at(i)->numberParameters();
+    }
+    return numParameters;


I did this a bit differently locally, but your version is better, taken along with your other changes.

…tests

* Converted jigsaw scconfig tests. * Added jigsaw radar test * Updated tests to reflect PR #4446 changes & removed makefile tests * Updates to scconfig tests

* CSM CSV output * Small test clean-up * typo fix * obs header fix * Remove param list from bo * Added debug output * Now reurning * Fixed unit test * xml save test update * Clean up bundleresults unit test output * Fixed qfile member * Fixed old path * Changed header to use param names * Making separate csvs * Added reverse on obs by instId * Trying to fix multiple sensors * Fixed images header * More debug * removed debug outs * Added terrible imageindex search * Added held config fix * Updated for observation test * Updated jigsaw test makefiles * Updated with new tests

* Converted jigsaw scconfig tests. * Added jigsaw radar test * Updated tests to reflect PR DOI-USGS#4446 changes & removed makefile tests * Updates to scconfig tests