pc_align rotating the results

[Janko Trisic Ponce]

Hi everyone,

I'm currently doing some HiRISE DTMs, and so far everything until point2dem has worked well. The DTM overlaps quite well with the basemap I'm using as a reference (THEMIS), and the profiles look ok.

The issues arise when I run pc_align: I am aligning it with some MOLA shots that I cut to overlap the DTM I obtained with point2dem, but once it's done, the new aligned DTM is slightly rotated and shifted - depends on the algorithm I use and the subpixel mode in what degree there is rotation and shift. It's not something major (around 10m in the worst cases) but given HiRISE's high resolution, it counts. What I have observed is that after pc_align, the DTM doesn't cover all the original MOLA shots, because of the mentioned shift and rotation.

I am currently running different tests to see what are the results and try to pinpoint the source of the error, but I wanted to see if anyone has had a similar problem. 

So far, I have used --datum D_mars, but for some tests I've also used --datum MOLA to see if there is any change. I'm also trying different algorithms to see which suits it best, but until now my first iteration has been the most successful, with asp_bm and subpixel-mode 1 (although I know this will depend on the area and the stereopair itself). I will also try different --max-displacement options. The stereopair I'm using is PSP_009735_1985-PSP_009880_1985.

I will give an update once my tests are done. Here is a visual representation of what I'm talking about (purple are the shots outside of the DTM; the first one is using asp_bm, spx 1, the second one using asp_sgm spx 9; from blue to red, is the quality of the disparity from MOLA to DTM in m, blue being less than 5m, red being greater than 20m):

I know it seems like there are very few purple spots, but before alignment to MOLA they overlapped perfectly, and this will be relevant if I want to mosaic several DTMs.

Thank you for your help in advance!

Janko

[Oleg Alexandrov]

You can try pc_align with the option --compute-translation-only. you can try a smaller --max-displacement (say no more than 2x the final expected translation norm).

I think --datum is not used unless you have lon,lat,height above datum, and I think MOLA may have radius from palnet center measurements.

This looks to me like a very sparse cloud. 

If you want to mosaic several DEMs, pc_align will not give you pixel-level accuracy. Ideally all overlapping images should be bundle-adjusted together. This will create self-consitent DEMs (hopefully). Or you an align one DEM to MOLA, then, if happy enough, align the other DEMs not to MOLA but to the DEM you already aligned. This requires a good overlap, not just around edges.

--
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/4c8c1e9e-2fdf-450e-aee5-ff5bcdfed51dn%40googlegroups.com.

[Oleg Alexandrov]

To add, if you want to mosaic several DEMs and also have them aligned, one would have to use a combination of pc_align and bundle_adjust. Such as bundle-adjust first, do stereo, mosaic, see if there is good agreement, then align the mosaicked DEM to MOLA, apply the transform to cameras with bundle_adjust options for initial transform and applying transform only, then redo stereo or simply use pc_align to move the mosaicked DEM.

One could also get a larger CTX DEM first, align that one to MOLA, then align the HiRISE mosaicked DEM to CTX. 

In either case, if you have several eventual DEMs to mosaic, applying a single alignment transform to their mosaic will give better results than aligning them individually and then mosaic.