Improving DEM resolution from Kaguya TC data

[ladoramkershner]

Hello! I am working with the ASP to make DEMs with the Kaguya TC data. The workflow we are using is fairly simplistic and consists of isis ingestion of raw TC images > bundle_adjust > parallel_stereo (config below) > point2dem with an initial downward translation.

The config for the parallel stereo is:

alignment-method affineepipolar
prefilter-mode 2
prefilter-kernel-width 2.5

stereo-algorithm 0 
corr-seed-mode 1
cost-mode 2
corr-kernel 35 35

subpixel-mode 2
subpixel-kernel 25 25

rm-cleanup-passes 0
median-filter-size 7
texture-smooth-size 13
texture-smooth-scale 0.13

compute-error-vector true

We are creating the final DEM with dem-spacing of 35 (and a projection unit of meters), but it does not seem like that is the resolution of the output DEM. For example,

the highlighted crater is approximately 240m across, it is visible in the original image, but is not resolved in the output DEM. The DEM is at a fairly equatorial latitude (~10 \degs N), so I am wondering if some of our parallel_stereo parameters might be effecting our resolution in a way we aren't expecting.

I am fairly new to ASP, so I was just hoping something might jump out to an expert and help me narrow down my digging.

Thank you!

[oleg-alexandrov]

You can try using --stereo-algorithm asp_mgm. That one has better resolution than default block matching. There are more algorithms to experiment with, such as another implementation of mgm, then an OpenCV algorithm, if one tries the latest build from https://github.com/NeoGeographyToolkit/StereoPipeline/releases (technically that logic should also be in ASP 3.0.0, but I fixed some bugs in that code after it got released). There is more info here: https://stereopipeline.readthedocs.io/en/latest/next_steps.html#stereo-pipeline-in-more-detail I would be curious to know if any of this improves things. Your lunar terrain may also benefit from shape-from-shading, perhaps, descrbied at https://stereopipeline.readthedocs.io/en/latest/sfs.html, though that would require a significant time investment and provides only local refinement.

…

On Mon, Oct 18, 2021 at 1:00 PM Lauren Adoram-Kershner < ***@***.***> wrote: Hello! I am working with the ASP to make DEMs with the Kaguya TC data. The workflow we are using is fairly simplistic and consists of isis ingestion of raw TC images > bundle_adjust > parallel_stereo (config below) > point2dem with an initial downward translation. The config for the parallel stereo is: alignment-method affineepipolar prefilter-mode 2 prefilter-kernel-width 2.5 stereo-algorithm 0 corr-seed-mode 1 cost-mode 2 corr-kernel 35 35 subpixel-mode 2 subpixel-kernel 25 25 rm-cleanup-passes 0 median-filter-size 7 texture-smooth-size 13 texture-smooth-scale 0.13 compute-error-vector true We are creating the final DEM with dem-spacing of 35 (and a projection unit of meters), but it does not seem like that is the resolution of the output DEM. For example, [image: image] <https://user-images.githubusercontent.com/42873279/137787646-f238bfe3-923c-4223-a394-c830cd446493.png> the highlighted crater is approximately 240m across, it is visible in the original image, but is not resolved in the output DEM. The DEM is at a fairly equatorial latitude (~10 \degs N), so I am wondering if some of our parallel_stereo parameters might be effecting our resolution in a way we aren't expecting. I am fairly new to ASP, so I was just hoping something might jump out to an expert and help me narrow down my digging. Thank you! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#343>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKDU3DGZVFJETQ3ZX4WE6LUHR4FDANCNFSM5GHONBDA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[dpmayerUSGS]

Stereo tends to make slopes in craters shallower than they really are. For smaller craters, this shallowing can have the effect of erasing them altogether, even if the crater is resolvable in an ortho at the grid spacing of the DTM. A 240 meter crater in a 35 meter/pixel image is only ~7 pixels across. It's plausible that craters of this size class simply can't be resolved in a DTM under those conditions. The similarly-sized, fresh-looking crater north of your example is kind telling; that crater should be easier to resolve, but there's no sign of it in the hillshade.

Have you tried using smaller subpixel-kernel sizes? Kirk et al. (2021) recently found that subpixel kernel sizes of 13 x 13 yielded optimal (resolution * error) in HRSC and CTX data, regardless of what size corr-kernel was used (last paragraph of Sec 3.1). I'm not sure if this relationship would hold for Kaguya TC, but it would be simpler to try than switching matching algorithms right away. However, even if shrinking the subpixel kernel size improves the resolution somewhat, it still may not be enough to resolve craters in that size class.