Help Needed with CTX Image DEM Generation

[squidward-qwq]

Hi everyone,

I'm encountering some issues while generating DEM (Digital Elevation Model) from CTX (Context Camera) images. The resulting DEM has a lot of noise and several areas appear blank. Please refer to the attached image for reference.

Here's the process I follow for generating the DEM:

Use mroctx2isis to convert CTX images obtained from the PDS website into cub format.
Use the spiceinit command to assign SPICE kernels to the cub file.
Use the ctxcal command for CTX radiometric calibration.
Use the ctxevenodd command for CTX radiometric calibration.
Use the cam2map command to apply a map template to the image.
Use the parallel_stereo command to generate a point cloud.
Use point2dem results/output-PC.tif to generate the DEM.

I'm seeking advice on improving the accuracy of the DEM generated through this process. Any suggestions or insights would be greatly appreciated.

Thanks in advance for your help!

Best regards

[oleg-alexandrov]

The problem is most likely different illumination. You can try overlaying in stereo_gui the two images you pass in to parallel_stereo (after cam2map) and toggle one on and off. If the lightning changes noticeably, that is the problem. (Also check for large changes in features between images.)

If so, there is no solution except getting different data. Stereo correlation does not tie well together images with different lightning.

[squidward-qwq]

I’ve captured an image in stereo_gui but I’m not certain if the variations in brightness are significant enough to affect the stereo matching results. Could you take a look and advise?

[rbeyer]

These images have the sunlight from fundamentally different directions, which means that the correlator will not be able to do it job. These images also look like Mars polar images taken in fundamentally different seasons, not just different lighting directions, so that doesn't help either.

You will need to find other data to make a stereo terrain model here.

You may want to evaluate HiRISE images, which do a better job of reporting which images are part of an intentional stereo pair, and CTX images are often taken as "ride-alongs" to HiRISE images, so if you can find a HiRISE stereo pair near where you want, there is a very good chance that there is also a CTX pair taken on those same orbits, and you should be successful in making stereo terrain from them.

For example, HiRISE images ESP_022064_0930's web page indicates that it is a stereo pair with ESP_022210_0930, and if you can find CTX images from orbit 22064 and 22210, you're in business. So there is a G10_022210_0933_XN_86S343W and a G10_022064_0932_XN_86S344W CTX image that you could use to make a good model.

[squidward-qwq]

Dear rbryer,

First and foremost, I would like to express my gratitude for your response.

I have encountered an issue with the DEM images I generated using CTX images G10_022210_0933_XN_86S343W and G10_022064_0932_XN_86S344W. The quality of the DEM images is not satisfactory. I have attached the images for your reference.

Here are the steps and commands I executed:

Step 1: Convert IMG format images to CUB using mroctx2isis.
Step 2: Add SPICE information to the CUB image. Command used: spiceinit from=/home/ubuntu22/mars_stereo/text5/1.cub web=true url=https://astrogeology.usgs.gov/apis/ale/v0.9.1/spiceserver/
Step 3: CTX radiometric calibration. Command: ctxcal from=1.cub to=1.cal.cub
Step 4: Remove systematic noise. Command: ctxevenodd from=1.cal.cub to=1.evenodd.cub
Step 5: Apply a map template (I encountered some issues here; the point cloud generation failed after applying the map template, so I did not include it in this experiment). The map template is as follows:

TargetName         = Mars
EquatorialRadius   = 3396190.0 <meters>
PolarRadius        = 3376200.0 <meters>
LatitudeType       = Planetocentric
LongitudeDirection = PositiveEast
LongitudeDomain    = 360
ProjectionName     = Sinusoidal
CenterLongitude    = 227.95679808356
MinimumLatitude    = 10.766902750622
MaximumLatitude    = 34.44419678224
MinimumLongitude   = 219.7240455337
MaximumLongitude   = 236.18955063342
PixelResolution    = 426.87763879023 <meters/pixel>

Step 6: Generate point cloud. Command: parallel_stereo /home/ubuntu22/mars_stereo/text5/1.cub /home/ubuntu22/mars_stereo/text5/2.cub --alignment-method affineepipolar -s /home/ubuntu22/mars_stereo/text5/stereo.default.example results/output
Step 7: Generate DEM. Command: point2dem results/output-PC.tif

Do you have any suggestions on how to resolve these issues?

Best regards

[squidward-qwq]

Here's my stereo.default.example file:

# -*- mode: sh -*-

# Pre-Processing / stereo_pprc
################################################################

# Pre-alignment options
#
# Available choices are (however not all are supported by all sessions):
#    NONE           (Recommended for anything map projected)
#    EPIPOLAR       (Recommended for Pinhole Sessions)
#    HOMOGRAPHY     (Recommended for ISIS wide-angle shots)
#    AFFINEEPIPOLAR (Recommended for ISIS narrow-angle and DG sessions)
#    LOCAL_EPIPOLAR (When affineepipolar is not aligning accurately enough,
#                    and for external stereo algorithms)
alignment-method affineepipolar

# Intensity Normalization
force-use-entire-range       # Use entire input range

# Select a preprocessing filter:
#
# 0 - None
# 1 - Subtracted Mean
# 2 - Laplacian of Gaussian (recommended)
prefilter-mode 2

# Kernel size (1-sigma) for pre-processing
#
# Recommend 1.4 px for Laplacian of Gaussian
# Recommend 25 px for Subtracted Mean
prefilter-kernel-width 1.4

# Integer Correlation / stereo_corr
################################################################

# Select a stereo algorithm. See the documentation describing
# stereo.default for more details. Options are:
#
# asp_bm  (or use '0') - the ASP implementation of Block Matching.
# asp_sgm (or use '1') - the ASP implementation of SGM.
# asp_mgm (or use '2') - the ASP implementation of MGM.
# asp_final_mgm (or use '3') - ASP MGM at the the finest level.
# mgm - the originally published MGM implementation.

stereo-algorithm asp_bm

# Select a cost function to use for initialization:
#
# 0 - absolute difference (fast)
# 1 - squared difference  (faster .. but usually bad)
# 2 - normalized cross correlation (recommended)
cost-mode 2

# Initialization step: correlation kernel size
corr-kernel 21 21

# Initialization step: correlation window size
# corr-search -80 -2 20 2

# Subpixel Refinement / stereo_rfne
################################################################

# Subpixel step: subpixel modes
#
# 0 - disable subpixel correlation (fastest)
# 1 - parabola fitting (draft mode - not as accurate)
# 2 - affine adaptive window, bayes EM weighting (slower, but much more accurate)
# 3 - affine window, (intermediate speed, results similar to bayes EM)
subpixel-mode 1

# Subpixel step: correlation kernel size
subpixel-kernel 21 21

# Post Filtering / stereo_fltr
################################################################

# Automatic "erode" low confidence pixels
filter-mode 1
rm-half-kernel 5 5
max-mean-diff 3
rm-min-matches 60
rm-threshold 3
rm-cleanup-passes 1

# Triangulation / stereo_tri
################################################################

# Size max of the universe in meters and altitude off the ground.
# Setting both values to zero turns this post-processing step off.
near-universe-radius 0.0
far-universe-radius 0.0

[oleg-alexandrov]

Perhaps you can try to show how your "L.tif" and "R.tif" images look like. They are in the output directory. They should be very similar except for some local differences.

Also your two input images that you passed to stereo would be good to see.

Your DEM looks skewed. See if using point2dem with: point2dem --stereographic --auto-proj-center helps.

[squidward-qwq]

Dear Oleg,

Thank you for your response, and I apologize for any inconvenience my queries may have caused. Upon reviewing my "L.tif" and "R.tif" images, I've observed that their performance appears to be quite satisfactory, as shown in the attached figures. There are no noticeable lightning changes.

However, I encountered some issues when attempting to use the point2dem --stereographic --auto-proj-center command. The output DEM still does not meet the desired standards, as illustrated in the attached figures.

I would appreciate any further guidance or suggestions you might have on this matter.

Best regards

[rbeyer]

Can you do two things for us? (1) Please paste in the full command line that you are using to invoke point2dem to generate the above DEM TIF. (2) Run gdalinfo on the above DEM TIF, and paste the output here.

[squidward-qwq]

Dear rbyer,

I have successfully executed the point2dem command with the following output:

(isis) ubuntu22@DESKTOP-C4DA540:~/mars_stereo/text5$ point2dem --stereographic --auto-proj-center results/output-PC.tif
--> Setting number of processing threads to: 4
Writing log info to: results/output-log-point2dem-04-09-1106-15370.txt
Estimating the median longitude and latitude for the cloud.
Bounding box and triangulation error range estimation: [*************] Complete!
QuadTree: [**********************************************************] Complete!
Collected a sample of 25706753 positive triangulation errors.
Error percentiles: Q1 (25%): 29.2211, Q2 (50%): 37.7217, Q3 (75%): 45.1598.
Computing triangulation error cutoff based on --remove-outliers-params.
Triangulation error cutoff is 135.479 meters.
Starting DEM rasterization
--> DEM spacing: 7.44209 pt
                 or: 0.134371 px
Creating output file that is Vector2(5333,5356) px.
Writing: results/output-DEM.tif
DEM: [***************************************************************] Complete!
Percentage of valid pixels: 51.9874%

Following the gdalinfo execution on the resulting output-DEM.tif, here are the details:

Driver: GTiff/GeoTIFF
Files: results/output-DEM.tif
Size is 5333, 5356
Coordinate System is:
PROJCRS["unknown",
    BASEGEOGCRS["Geographic Coordinate System",
        DATUM["D_MARS",
            ELLIPSOID["MARS",3396190,0,
                LENGTHUNIT["metre",1,
                    ID["EPSG",9001]]]],
        PRIMEM["Reference meridian",0,
            ANGLEUNIT["degree",0.0174532925199433,
                ID["EPSG",9122]]]],
    CONVERSION["Stereographic",
        METHOD["Stereographic"],
        PARAMETER["Latitude of natural origin",-86.7417,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",16.0067,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",1,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["easting",east,
            ORDER[1],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]],
        AXIS["northing",north,
            ORDER[2],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]]]
Data axis to CRS axis mapping: 1,2
Origin = (-21407.176670923272468,19226.643813429611328)
Pixel Size = (7.442091663800895,-7.442091663800895)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
  PREDICTOR=3
Corner Coordinates:
Upper Left  (  -21407.177,   19226.644) ( 10d14'48.07"E, 86d23'57.12"S)
Lower Left  (  -21407.177,  -20633.199) (  8d55'46.30"E, 87d 4' 2.97"S)
Upper Right (   18281.498,   19226.644) ( 20d55'48.58"E, 86d24'14.76"S)
Lower Right (   18281.498,  -20633.199) ( 22d 3'31.78"E, 87d 4'24.65"S)
Center      (   -1562.839,    -703.278) ( 15d32'28.07"E, 86d45'12.45"S)
Band 1 Block=256x256 Type=Float32, ColorInterp=Gray
  NoData Value=-3.4028235e+38

Please let me know if you need any further assistance or clarification.

Best regards

[oleg-alexandrov]

What you show looks reasonably good. The process seems right. Likely something is still odd with the data. See if you have better luck with our dataset in the CTX doc. Your own dataset seems to still have some rather different illumination.

[squidward-qwq]

Hi Oleg,

I’ve followed the method outlined in the document, but I’m still encountering some issues as shown in the attached image. There are still many noise points present. Could you please advise on how to resolve this?


Could the issue be related to precision limitations? I’m noticing a lot of noise points that shouldn’t be there.

[oleg-alexandrov]

This shows you are on the right track. Better results can be obtained with the asp_mgm algorithm (https://stereopipeline.readthedocs.io/en/latest/next_steps.html#nextsteps). That is, use parallel_stereo --alignment-method affineepipolar
--stereo-algorithm asp_mgm --subpixel-mode 9. This algorithm is quite a bit slower though.

Also consider using mapprojection: https://stereopipeline.readthedocs.io/en/latest/next_steps.html#mapproj-example.

[oleg-alexandrov]

I will also suggest a CTX pair known to work. For example, take a look at this: https://stereopipeline.readthedocs.io/en/latest/examples/ctx.html

The goal would be here to see if your process is not right or the images.