Trouble Integrating bundle_adjust and mapproject Into ISIS Workflow

[Joshua Carter]

Hi, I'm very new to ISIS and ASP so this is somewhat of a beginner-oriented question. So my goal is to make a color mosaic of Valles Marineris using ASP, I noticed that after calibrating and cleaning the Viking Orbiter 1 data in ISIS, I needed to actually mapproject the images, so I just went through this workflow:

spiceinit from=cal_clear1.cub

spiceinit from=cal_clear2.cub

spiceinit from=cal_clear3.cub
... (and more)

bundle_adjust \
    cal_clear1.cub  \
    cal_clear2.cub  \
    cal_clear3.cub  \

    ...
     --max-pairwise-matches 100000 \
     --heights-from-dem /home/ytthe/.Isis/isis_data/base/dems/molaMarsPlanetaryRadius0005.cub \
     --heights-from-dem-uncertainty 10 \
     --tri-weight 0.1 \

     -o ba-valles-marineris-color/ba

mapproject --tr 200 --datum D_MARS --bundle-adjust-prefix ba-valles-marineris-color/ba /home/ytthe/.Isis/isis_data/base/dems/molaMarsPlanetaryRadius0005.cub cal_clear1.cub s_cal_clear1.tif
mapproject --tr 200 --datum D_MARS --bundle-adjust-prefix ba-valles-marineris-color/ba /home/ytthe/.Isis/isis_data/base/dems/molaMarsPlanetaryRadius0005.cub cal_clear2.cub s_cal_clear2.tif

...

and I end up getting tif files with large artifacts on the edges outside of the original boundaries, which is ruining my mosaics. Are there any fixes for this, or am I simply missing something? 

[Oleg Alexandrov]

Registrationis a lot more complicated than that, regretfully. The --heighs-from-dem option assumes you are already in the ballpark, both between images and relative to the ground. None of these are remotely true for Viking Orbiter 1 data, and surely the DEM you are making use of is not accurate to uncertainty of 10 meters, more like kilometers.

Registration and mosaicking is a painstakingly drawn-out process. First, ideally you have stereo pairs. With convergence angle of say 10 to 50 degrees. Then you do bundle adjust for a single pair only, no DEM constraint at all. You hopefully get a good enough solution. Then you run stereo with it. You may get a DEM. If you mapproject left and right imags onto that DEM and they agree, you are in business, otherwise one fails. 

Then, one needs a lot higher quality DEM than molaMarsPlanetaryRadius0005.cub to bring into global alignment. Then the alignment has to be transferred from the DEM to the cameas, then it has to be refined. 

In short, registration is painstaking and hard, even when you actually got all data to have all the information and all the detail. The best you can do without a lot of pain is a self-consistent DEM and images mapprojected onto it, which may take more than one step of stereo, as described here: https://stereopipeline.readthedocs.io/en/latest/next_steps.html#stereo-with-mapprojected-images

So muti-image bundle adjustment, followed by a few carefully picked stereo pairs, several DEM creation, merge them, hope for best, mapprojecton on them, then if happy apply a global alignment to some coordinate system like here: https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#applying-a-transform-to-cameras

We regretfully do not have an end-to-end scripted workflow, the tools have to be leaned painstakingly, applied with a lot of inspection, counting on high quality DEM comparable with the images, and even then one has to have quite some practice to get it done. Sorry.

Oleg

--
You received this message because you are subscribed to the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/ad09a78a-5101-4287-ac20-2fc53eb0e0ben%40googlegroups.com.