Help aligning DEM: Rotation/Translation issues

[forwork]

Hello,

I am working with Lunar South Pole stereo data and have successfully generated a DEM that is structurally very sound. However, I am facing A issue with its absolute placement relative to my reference DEM (LOLA: LDEM_87s_5mpp.tif).

My generated DEM sits a few kilometers away from where it should actually be. The rotation (angle) is slightly off, and it needs a translation (forward/backward shift) to sit perfectly over the reference DEM.

When I attempt to align it, the DEM seems to sit around the main target position across different iterations, but it refuses to lock onto the exact coordinates.

The pipeline I followed is:

• Bundle adjust, parallel_stereo, point2dem

• Multiple iterations of pc_align after the parallel_stereo's point2dem, hoping it would eventually settle.

• Using pc_align with a specifically calculated --max-displacement based on the measured distance difference.

• Applying the --highest-accuracy, algorithm flags in pc_align.

• Running map projection, gcp_gen followed by bundle_adjust and then mapproject and many other pipelines and commands i tried.

Despite these efforts, the DEM keeps shifting around the true position rather than snapping into place.

Help me with:

1. What is the recommended flags to handle a shift of a few kilometers or make a little rotation using pc_align command and it's iterations?

2. If I want to strictly correct the angle and bring the DEM forward/backward manually, what pipeline can be followed?

Thank you so much.

[Oleg Alexandrov]

A few km of translation can be a lot. Likely the ICP algorithm got confused. Large max displacement also means many outliers. 

Try to resample your DEM to same projection and resolution (grid size) as the LDEM_87s_5mpp.tif and crop them to a big enough box having both of them. You can hillshade these results. If they look similar enough try 

sparse-features hillshading-based alignment https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#feature-based-alignment

corelation-based alignment https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#correlation-based-alignment

It is suggested hillshading with gdaldem hillshade. The doc has more info. 

These should bring the clouds in the ballpark enough for ICP then to refine the remaining transform, perhaps. If you resume pc_align later with the initial transform from this, can set a notably smaller max displacement, as that is applied after the big transform is applied.

For the first of these alignment methods, you should also be able to inspect the match file between the hillshaded DEMs. It shold also print the observed shift, which will hopefully be on the order of what you expect.

Hope it works. Let me know if not.

--
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/8c3b4652-36bf-4c48-ba6f-6438be0e6d2bn%40googlegroups.com.

[forwork]

Hello,

Thanks for the helpful advice. To give you a bit more context, we are actually generating a DEM using Chandrayaan-2 OHRC data.

The new ASP 3.7 documentation explicitly mentions that the OHRC DEM is usually shifted relative to LOLA by about 4 km along the satellite track, which causes the default pc_align to fail.

Given our specific dataset and this known offset, I have two questions on how to proceed with the reference and resampling:

1. Which reference is better? For running pc_align and point2dem, is it better to use the CSV track points (lola.csv) or the ldem_27s_5mpp.tif as our reference?

2. What resolution should we use for resampling? The reference ldem_27s_5mpp.tif has a resolution of 5, while the OHRC data is extremely high resolution of ~0.28/0.31.

The ASP 3.7 documentation notes that for manual alignment, both the OHRC DEM and the LOLA point cloud were gridded to a 10 m grid size using the same projection before manually picking visually similar features to bring the clouds closer. So what resolution should we use 5 or 10 for OHRC dem generation?

[Oleg Alexandrov]

The new ASP 3.7 documentation explicitly mentions that the OHRC DEM is usually shifted relative to LOLA by about 4 km along the satellite track, which causes the default pc_align to fail.

Given our specific dataset and this known offset, I have two questions on how to proceed with the reference and resampling:

1. Which reference is better? For running pc_align and point2dem, is it better to use the CSV track points (lola.csv) or the ldem_27s_5mpp.tif as our reference?

2. What resolution should we use for resampling? The reference ldem_27s_5mpp.tif has a resolution of 5, while the OHRC data is extremely high resolution of ~0.28/0.31.

The ASP 3.7 documentation notes that for manual alignment, both the OHRC DEM and the LOLA point cloud were gridded to a 10 m grid size using the same projection before manually picking visually similar features to bring the clouds closer. So what resolution should we use 5 or 10 for OHRC dem generation?

For the purpose of alignment, likely the raw LOLA shots, so in CSV format, should work better. 

Though given how big the offset is, likely pc_align will fail at alinging to LOLA as stated there, so yeah, some preliminary alignment with a coarse DEM will likely work better to bring one in the ballpark, followed by fine aligment later against raw LOLA. Our pc_align can take an initial guess transform so this two stage approach works (as documented).

The difference in resolution is quite big. I am guessing grid your OHRC DEM at 5 m/pixel and compare with ldem_27s_5mpp.tif. So hillshade both, put them on top of each other with georeference information, and see how they compare in detail and shift. Then you can try your luck with our DEM-to-DEM alignemnt algorithms, based on hillshading, or dense correlation from hillshading, or Nuth and Kaab. If you invoke pc_align with the options to save the clouds afte ralignment, you can regrid the aligned one and see if you get any closer.

If you are not in the area where ldem_27s_5mpp.tif will work it gets tricky. Then yeah, then gridding the LOLA point cloud at 10 m / pixel and same for your DEM is likely the only option as otherwise LOLA is too rough.

Another option is to use prior Chandrayaan TMC DEMs as published by ISRO to help align your produced OHRC DEMs. For the Chandra example in the doc we showed how to get one. 

Hope something works. The OHRC misalignment is a big problem, but the provided logic should be enough to manage it.

 

 

[forwork]

Thank you so much for the detailed guidance and the documentations helped alot.

Following your explanation, I resampled and gridded the source data at 5 meters to match the ldem_27s_5mpp.tif reference layer. I then hillshaded both layers, manually picked tie-points using stereo_gui to generate a .match file, and ran pc_align with the following command pc_align \

  --num-iterations 0 \
  --max-displacement -1 \
  --match-file "<manual_features>.match" \
  --initial-transform-from-hillshading rigid \
  --initial-transform-ransac-params 1000 100 \
  --save-transformed-source-points \
  ldem_5m.tif dem_5m.tif \
  -o pc_align_output/run

This steps worked really well, the 5m output DEM is now tightly registered and sits exactly in the correct place when overlaid on the reference LDEM.

I have a critical follow-up question regarding how to perform pc_align on OHRC's native resolution of 0.28m using 5m based pc_align output to achieve OHRC aligned DEM at 0.28m?

[Oleg Alexandrov]

Following your explanation, I resampled and gridded the source data at 5 meters to match the ldem_27s_5mpp.tif reference layer. I then hillshaded both layers, manually picked tie-points using stereo_gui to generate a .match file, and ran pc_align

This steps worked really well, the 5m output DEM is now tightly registered and sits exactly in the correct place when overlaid on the reference LDEM.

I am glad it worked. Using a manually provided match file is not going to scale for large-scale processing but I am glad you verified it at least helps here. You could try at some point also the hillshading based methods I suggested as those try to build automatically the features you made manually. So, by dropping the match file done by hand. But one thing at a time. 

 

I have a critical follow-up question regarding how to perform pc_align on OHRC's native resolution of 0.28m using 5m based pc_align output to achieve OHRC aligned DEM at 0.28m?

The pc_align run that you are happy with wrote to disk two transform files, the direct transform, from source (2nd cloud in the pc_align invocation) to reference (1st cloud in the pc_align invocation). It also wrote the inverse, which goes the other way.

Since your command before was:

pc_align ldem_5m.tif dem_5m.tif  -o pc_align_output/run <with extra options>

Now you should be able to do:

pc_align ldem_5m.tif dem_0.28m.tif  -o pc_align_0.28m/run --max-displacement 100 --initial-transform pc_align_output/run-transform.txt --save-transformed-source-points 

So, this aligns to the 5m cloud not the resampled OHRC DEM at 5 m, but the fine resolution DEM you have at 0.28 m, it uses a small max-displacement (100 m beause clouds are now close) and it uses the previous aligment transform as helper. I think this should work. I am guessing here a little, but looks legit. So basically this resumes with pervious transform and continues the process but with the finer quality DEM.

You can grid the obtained saved cloud with point2dem and see if you still get it to be where you want to be.

The problem is that the 5m ldem is not great. Could be good, but maybe not enough. The gold standard is aligning directly to the LOLA RDR shots. So it is suggested to do the additional indepdenent alignemnt as follows, and see which you like more.

LOLA RDR shots can be downloaded for a given extent. We explain somewhere in the doc. The direct link is https://ode.rsl.wustl.edu/moon/tools?displaypage=lolardr. For LOLA RDR, which is a CSV file, you should specify --csv-format as described here: https://stereopipeline.readthedocs.io/en/latest/outputfiles.html#lola-with-radius-in-km

Then, since this is sparse, the order of clouds should be reversed (this is a limitation of our algorithm we use). So the invocation should be:

pc_align dem_0.28m.tif lola_rdr.csv -o pc_align_0.28m_lola/run --max-displacement 100 --initial-transform pc_align_output/run-inverse-transform.txt --save-transformed-source-points --csv-format '1:lon 2:lat 3:radius_km'.

You can peek in your CSV LOLA file to ensure that it agrees with the fields you see there.

So, this second command basically swaps the cloud order, introduces LOLA as a cloud, and uses the inverse transform instead of the direct one because the order was swapped.

This should hopefully give almost same result as the previous one, which you can check. You can grid both aligned OHRC DEMs and see how they compare to each other and the reference gridded LOLA.

It is important to note that precise alignment is very tricky. There likely can be a residual error or disagement between the two modalities. The one based on LOLA is likely safer as it does not have gridding error.

[Oleg Alexandrov]

I had a couple of errors in the pc_align command with lola rdr, it should be:

  pc_align dem_0.28m.tif lola_rdr.csv -o pc_align_0.28m_lola/run \
    --max-displacement 100 \

    --initial-transform pc_align_output/run-inverse-transform.txt \
    --save-inv-transformed-reference-points \
    --csv-format '2:lon 3:lat 4:radius_km'

What changed is the csv format string and the flag for saving the right point cloud. So as before swapping order of clouds results in some swaps in what gets saved and the transform.

[forwork]

Thank you so much, it worked incredibly well. I followed both paths you outlined, and we could generate the 0.28m resolution OHRC DEM with accurate global placement.

However, we are now encountering two specific issues with the output that we need your help with:

1. While the global alignment is good, the registration is not completely uniform across the entire strip. The specific craters and areas where we manually picked match points with coincidences well with ldem_27s_5mpp.tif. However, the areas where match points are not selected show a little offset around 50 meters, even though we had taken in total about 12 match points that too covering all directions of the dem_5m.tif.
How can we achieve a consistent, uniform placement throughout the entire DEM? 

2. The output DEM is introducing unwanted interpolation that fills up holes and the shadowed area which shouldn't be filled. We tried using --search-radius-factor to 10 and then 100 hoping to resolve it, but it doesn't make any diffrence.
How can this interpolation be resolved and shadowed areas kept from filling up?

[Oleg Alexandrov]

Thank you so much, it worked incredibly well. I followed both paths you outlined, and we could generate the 0.28m resolution OHRC DEM with accurate global placement.

I am glad there is progress.

 

However, we are now encountering two specific issues with the output that we need your help with:

1. While the global alignment is good, the registration is not completely uniform across the entire strip. The specific craters and areas where we manually picked match points with coincidences well with ldem_27s_5mpp.tif. However, the areas where match points are not selected show a little offset around 50 meters, even though we had taken in total about 12 match points that too covering all directions of the dem_5m.tif.
How can we achieve a consistent, uniform placement throughout the entire DEM? 

That is the danger of manual point placement. The best thing you could do could probably be alignment with dense correlation from hillshading. That is basically dense measuring of where the two DEMs disagree and then force a global shift.

This can still fail if a global shift does not exist, but may give you some ideas. Our doc is here

https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#correlation-based-alignment

The idea is that you hillshade both DEMs. Then you overlay them. These must be on the same grid. You can use gdalwarp with bicubic interp to put them to same grid. 

If you observer clear visual features in both, and clear shift beween them, this will likely work. You do the correlation beween these as suggested there. Inspect the disparity bands. This gives you horiziontal and vertical shift. All the motions you see beween the DEMs, so bad registration, are hopefully observed here. The disparity bands measure this. If not sure how to measure the disparity can skip this.

Then, this should make for you a match file. So not manual one, but automatic one. This you can inspect with stereo gui to compare to yours. If you like it, try to then follow the rest of the doc in that section with alignemnt with this match file.

Let me know if no luck. 

 

2. The output DEM is introducing unwanted interpolation that fills up holes and the shadowed area which shouldn't be filled. We tried using --search-radius-factor to 10 and then 100 hoping to resolve it, but it doesn't make any diffrence.
How can this interpolation be resolved and shadowed areas kept from filling up?

One option is to redo stereo with the option --nodata-value which is set to the value in the shadow. If you open an image in stereo_gui and click on various pixels, it will print the pixel values which will suggest which are lit pixels and which are shadowed.

If you already have the DEM, you can make a corresponding ortho image with point2dem run-PC.tif --orthoimage run/run-L.tif (see the doc for more details), and wipe values in shadow in that ortho image and making a mask. Then you apply the mask to the DEM to wipe pixels where the mapprojected image is in shadow. We have the image_calc program which can make a mask by thresholding and which can apply a mask by multiplication. See https://stereopipeline.readthedocs.io/en/latest/tools/image_calc.html

The true reason you see terrain in shadow is because our asp_mgm algorithm treats those as legit data and does some infilling.

 

--
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/0a6a9c12-ada6-478e-a8d7-62c03b205b72n%40googlegroups.com.

[Oleg Alexandrov]

One minor addition. If one has to mask shadowed areas in a DEM with an orthoimage or mapppjected image, the latter has to be with the same size, extent, and grid size as the DEM, or else image_calc won't work. Such masking is more of a post-hoc band aid. The gdalwarp command can be used to do such operations with options -tr -te, -t_projwin. Once these agrees, one does the mask and then applies it.