oleg-alexandrov
commented
7 months ago I tested this quite a bit and it appears to work rather well. One gotcha is that bundle_adjust must be invoked with the same value of --datum as what is used when GCP are created, as otherwise there can be hundreds of pixels of offset.
I just made sure the datum WKT string is saved when the GCP file is created. Then on loading in bundle_adjust, if GCP are present it is enforced that --datum is specified, and the datum semi-axes are compared with what was recorded in the GCP file.
There's also a command-line tool now that avoid the GUI altogether but employs the same logic of finding match points from raw camera image to orthoimage that then result in GCP (https://stereopipeline.readthedocs.io/en/latest/tools/gcp_gen.html).
The doc for the stereo_gui approach got updated as well (https://stereopipeline.readthedocs.io/en/latest/tools/stereo_gui.html#creating-gcp-with-with-orthoimage-and-dem).
Our doc in https://stereopipeline.readthedocs.io/en/latest/tools/stereo_gui.html#view-create-move-delete-save-interest-point-matches-gcp-and-vwip-files suggests using stereo_gui to create GCP by creating matches from a given raw image and an orthoimage or a DEM, and then borrowing the xyz coordinates from the DEM to create a GCP.
Likely this worked when this was documented, which was developed likely for Earth and pinhole cameras, but does not seem to work for two Mars testcases I looked at, one with images M0100115.cub and E0201461.cub from our regression test suite, and another one with a HiRISE Mars image. To be looked into at some point.
In addition, the doc there needs to be expanded with the specific bundle adjustment command once the gcp file is used. And the GUI interface for first specifying a DEM and then a GCP file got even myself confused as one has to read the doc carefully to use it well.