Georeferencing CTX without gaps and shifts

194 views
Skip to first unread message

mikita belikau

unread,
Aug 6, 2022, 3:21:55 PM8/6/22
to Ames Stereo Pipeline Support
I have a question: how to georeference CTX images so that when you open several CTX overlapping images there are no gaps between them? Key point is to remove gaps (shifts).

I was first thinking first about using image_align and align CTX images one to each other, but:
1) for some reason image_align can not do this, maybe I need to have more attempts
2) conceptually this is wrong, cause aligning will be good only for 1 reference image, but if we choose another reference image this will be wrong

I will give a bit of context what I want to have at the end.

So, imagine I detected on HiRISE images some features, e.g. craters, sand dunes. Now I want to display this features (e.g. craters) all together on the top of CTX.
Here we have problems that:
1) HiRISE images are not aligned - there is a shift between them
2) CTX and HiRISE are also not aligned - there is shift
3) CTX images also have shift - not aligned

All this 3 points are valid if you open this images (.LBL for HiRISE and .tif for CTX) in QGIS 'as is' - without pre/post processing.

My basic idea for this was:

a) Align HiRISE images to some reference with the help of image_align and then put this on top of CTX - initial question is here https://groups.google.com/g/ames-stereo-pipeline-support/c/Q9nI-lkL_uU 
But I realized, that even though technically image_align is doing it's job for HiRISE, as I said, conceptually this is wrong if we choose different reference image. And since we don't know which image could be 'true' reference - this will be wrong. So, I stopped going this way.

b) Considering conclusion from a) I tried this way: detect features in HiRISE opening it 'as is'. And then manually move detected features (vector .shp file) and manually move it to the place where they should be on CTX. Without retrojecting. I know it's wrong, cause this images have different projections, but this part works fine.

And then again: CTX images are not aligned. So, moving to another CTX/HiRISE will create a problem of 'true' reference. And again we need somehow to remove shift between them.

So, my question is how to align CTX images? Geographically correct way, I mean.

I tried to search here in this google group, but from the first glance didn't find anything suitable.

Does anybody know how to to this?

divyamp

unread,
Aug 6, 2022, 3:29:04 PM8/6/22
to mikita belikau, Ames Stereo Pipeline Support
Hi Mikita,

I haven’t used image_align yet but I’ve used pc_align to do this with DTMs - HRSC is a good reference data source to align HiRISE and CTX to because all HRSC images should be in a common and consistent spatial reference frame, since the data products are automatically aligned to the global MOLA data. I would recommend aligning CTX first to HRSC, and then HiRISE to CTX, due to the resolution differences (like described in Tao et al. 2018). 

I hope this helps!

Divya

Divya M. Persaud, Ph.D.

On Aug 6, 2022, at 12:21 PM, mikita belikau <miki...@gmail.com> wrote:

I have a question: how to georeference CTX images so that when you open several CTX overlapping images there are no gaps between them? Key point is to remove gaps (shifts).
--
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 on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/b1ddcef7-5e78-4e15-91a1-cdc08497ce25n%40googlegroups.com.

Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]

unread,
Aug 6, 2022, 3:31:19 PM8/6/22
to mikita belikau, Ames Stereo Pipeline Support
Alignment is always a tough problem. The image_align tool won't work for you, as it assumes that the images are already very similar except for some shift. That is usually not the case, as images acquired in different perspectives can look very different because of the 3D terrain, view angle, planet curvature, etc. And mapprojecting them before aligning the images to the ground is going to mapproject them incorrectly, so the alignment needs to be fixed before that.

The ideal solution is to bundle-adjust all raw images with their cameras together. If you do that, I will suggest using --camera-weight 0, or a small value, in bundle_adjust (to ensure they move as much as they want to, to align well to each other). Then, one would create a DEM from the bundle-adjusted images, then mapproject all images onto that DEM with given --bundle-adjust prefix. 

This is likely easier said than done. You have a mix fo HiRISE and CTX, which have different resolutions. It is not clear if their illumination is similar enough. 

I don't think there's another way though. One can't just treat orbital images without regard to their perspective or camera model. 

If interest point matching fails, because of different illumination, the alternative is to pick interest point matches by hand. There's a write-up here. https://stereopipeline.readthedocs.io/en/latest/tools/stereo_gui.html#creating-interest-point-matches-using-map-projected-images

In either case, I will suggest starting easy. Pick two CTX images which make a stereo pair and one HiRISE image. See if bundle_adjust can find matches among them. 


From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of mikita belikau <miki...@gmail.com>
Sent: Saturday, August 6, 2022 12:21 PM
To: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] Georeferencing CTX without gaps and shifts
 
--

Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]

unread,
Aug 6, 2022, 3:35:58 PM8/6/22
to divyamp, mikita belikau, Ames Stereo Pipeline Support
The alternative solution suggested by Divya sounds good too. Create a DEM from CTX images. Align to 3rd party DEM with pc_align. Create a DEM from HiRISE images. Align to 3rd party DEM. Apply the alignment to images, as described here: https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#applying-the-pc-align-transform-to-cameras

This avoids the tricky problem of matching CTX to HiRISE, if you have individual stereo pairs for each. 

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of divyamp <div...@gmail.com>
Sent: Saturday, August 6, 2022 12:29 PM
To: mikita belikau <miki...@gmail.com>
Cc: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: [EXTERNAL] Re: Georeferencing CTX without gaps and shifts
 

mikita belikau

unread,
Aug 6, 2022, 4:35:30 PM8/6/22
to Ames Stereo Pipeline Support
Oleg, Divya thanks for your suggestions.
I need to read about the approaches you described, but from what I understand Divya's approach is 'easier' and I'll start from that. If not, I will stick to what Oleg is suggesting.

Do, Divya, am I right, that you approach is following

1) Download HRSC images for the region where I have CTX and HiRISE
2) run pc_align for HRSC (as a reference) and CTX
3) then run pc_align to output CTX from 2) and align HiRISE to it

Is this correct?

I just briefly checked description of pc_align https://stereopipeline.readthedocs.io/en/latest/tools/pc_align.html#

I see that this requires DEM. For me question is: will pc_align treat HRSC/CTX/HiRISE images (tif/lbl(jp2) format) as DEM? Or I need to take it from somewhere?

Oleg, regarding the difference in illumination, camera angles - for sure this your comment is relevant, cause as you know all this different sources have different parameters, so, yes, it's a tough problem.  

mikita belikau

unread,
Aug 6, 2022, 4:40:13 PM8/6/22
to Ames Stereo Pipeline Support
And another question:

I see these options for HRSC

What image do I need?Untitled.png

Oleg Alexandrov

unread,
Aug 6, 2022, 5:49:29 PM8/6/22
to mikita belikau, Ames Stereo Pipeline Support
>  For me question is: will pc_align treat HRSC/CTX/HiRISE images (tif/lbl(jp2) format) as DEM? Or I need to take it from somewhere?

A DEM needs to be created with ASP for each of CTX and HiRISE. Then for HRSC you will have to get DEMs. So stereo pairs are needed. So that is why it is more work. It is quite hard to avoid DEMs in this line of work as that's the surest way of taking advantage of the 3D nature of the terrain imaged by the pictures. 

Alternatively, with stereo_gui you can pick the same crater rims, for example, in a preexisting DEM, and then in each of the pictures, and create GCP. Then, bundle_adjust would simply use those GCP to bring the images over to align to the DEM, and then one can mapproject the images onto that DEM. So, this avoids creating  your own DEM, but is less reliable as one is limited by accuracy of picking points by hand and their small number.



astr...@gmail.com

unread,
Aug 6, 2022, 6:42:05 PM8/6/22
to Ames Stereo Pipeline Support
I'm a bit late to the party, but I think it's important to note that there are three separate things being discussed, and each one requires careful thought.

(1) How do you do relative cartographic control (image-to-image)?
(2) How do you do absolute cartographic control (image-to-reference)?
(3) What sort of datum reference and software can be used?

For (1), ASP can do image-to-image registration, as discussed above.  I have found its exact nature a tad confusing, but I haven't explored it in detail because I use USGS's ISIS programs to perform the registration.  But, ISIS is much less user-friendly and I think their all-in-one control tool never really got finished.  As opposed to ASP's which requires no real user input and just runs from one command.

However, automatic image-image registration is only as good as (a) the feature-matcher vs (b) how similar/different the images are.  Unless I'm way out of touch with how good ASP is, CTX-to-HiRISE is going to be very hard to do with any automated tool because of the factor of ~20x pixel size difference.  And, I'm not how much of the parameters you can play with in ASP.  This is a case where I would want to do it manually in ISIS, at least at the start.

For (2), this is again something that I do in ISIS by picking control points on a reference image and telling ISIS they must stay at or within a certain position, defined by the uncertainty of that reference's own control.  I think ASP handles this in a side way via the suggestions above of using pc_align of your data to the reference, but (I may have missed it in the thread above) I think pc_align really needs a DTM, so you'd have to go with HRSC or MOLA as your reference (see note in below paragraph about HRSC).

For (3), CTX-to-MOLA has a factor of ~100x difference in pixel size, while CTX-to-THEMIS is around 20x.  I was unaware that HRSC is formally controlled to MOLA; indeed, I thought that the HRSC team keeps talking about making controlled mosaics but doesn't really have funding to do it and so hasn't.  Maybe my information is out-of-date?  HRSC would be nice because it offers an intermediate pixel scale between THEMIS and CTX.

With those in mind, Oleg's point about a DTM in this work, for some step, I think (correct me if I'm wrong) is partially due to the alignment to a reference part and partly due to the issue of images are rarely taken at nadir pointing and so have some foreshortening due to topography which ASP can fix if it has a DTM.  If you don't fix that foreshortening, then you will have misalignments no matter what you do.  Some form of the example below is my go-to to illustrate the point that even when you've cartographically controlled three CTX images to each other, if you don't have a DTM or a DTM with enough fidelity to resolve the topography, then you will still have those misalignments.

Untitled.jpg

mikita belikau

unread,
Aug 7, 2022, 7:38:53 AM8/7/22
to Ames Stereo Pipeline Support
I just realized I replied to the last message via email, so I duplicate my response here

Thanks a lot for your detailed answer.
With my current knowledge about Mars data I didn't get everything that you carefully explained, but I will try my best to get a deeper understanding of what you described.

For me ASP is preferable, cause (at least for now) it abstracts things in a more high-level way that currently is easier for me ;-)

So, for now I understand that for me there is no other way to do this (properly) without DTM. Ok, I will dig in this direction.  

Just one quick question: HRSC belongs to ESA Mars Express. And you're talking about Themis, which I found under 2001 Mars Odyssey Orbiter.
Again, for now at least, I have no knowledge about Themis data now, but I am a bit confused and want to clarify: can I use Themis data the same way as HRSC? Or is this completely different? 
Just this question I want to clarify.

astr...@gmail.com

unread,
Aug 7, 2022, 10:43:00 AM8/7/22
to Ames Stereo Pipeline Support
Yes: HRSC is Mars Express, and HRSC is specifically a stereo camera so they can make DTMs.  I mentioned THEMIS (from Mars Odyssey) because THEMIS has been made into a controlled dataset, tied to MOLA.  Hence, it can be used as a reference for where images can go (your initial message: you can tie one CTX image to another, but there's no guarantee that now both are where they really should be on Mars).  There is no DTM from THEMIS.

Oleg Alexandrov

unread,
Aug 7, 2022, 12:52:58 PM8/7/22
to mikita belikau, Ames Stereo Pipeline Support
Here's how to use ASP to make DEMs: https://stereopipeline.readthedocs.io/en/latest/tutorial.html

As to where to get HRSC DEMs, I think the screenshot you showed before had an option to download ready-made DEMs, if I remember correctly. Otherwise, you can align your CTX DEM to MOLA, and then later HiRISE to CTX (can't align HiRISE to MOLA as that one is too sparse and HiRISE's footprint is too small). 


mikita belikau

unread,
Aug 7, 2022, 5:34:45 PM8/7/22
to Ames Stereo Pipeline Support
Oleg, thanks for the reply.
On the screenshot I see it's written Digital Terrain Map - is this the same as DEM? I was suspecting this, but just was unclear.

And thanks for the tutorial. Will try to find what will work for me.

Jan-Peter Muller

unread,
Aug 8, 2022, 6:53:01 AM8/8/22
to astr...@gmail.com, Ames Stereo Pipeline Support

Dear Colleagues

I wanted to support what Divya had said (thanks, Divya!) about the importance of HRSC and provide further information.

All HRSC DTM  (Digital Terrain Model) products which have v50 and above [1,2] or are within a controlled photomosaic are co-aligned to MOLA [3]. The HRSC DTM products (single-strip) are available via https://pds-geosciences.wustl.edu/missions/mars_express/hrsc.htm but their actual source location is https://archives.esac.esa.int/psa/ftp/MARS-EXPRESS/HRSC/MEX-M-HRSC-5-REFDR-DTM-V1.0/

The photocontrolled mosaics described in [3,4] are available from http://hrscteam.dlr.de/HMC30/. They have been in production in 2015. There are 5 half-quadrangles in the public domain. You can visualise each HRSC single-strip DTM and the HRSC controlled photomosaic DTMs and ORIs at http://i-mars.eu/web-gis.php.

A single 50m DTM and 12.5m ORI HRSC mosaic (not in a map-quad format) of the whole of Vallis Marineris is available at https://www.cosmos.esa.int/web/psa/UCL-MSSL_Valles-Marineris_HRSC_v1.0 and the paper describing its production at [5]. There is also a HRSC mosaic of the South Pole available at https://www.cosmos.esa.int/web/psa/UCL-MSSL_iMars_HRSC_v1.0 and described in [6].

There is a multi-resolution (HRSC, CTX and HiRISE) DTM and ORI mosaic of the Oxia Planum (Rosalind Franklin ExoMars rover) site available at https://www.cosmos.esa.int/web/psa/ucl-mssl_oxia-planum_hrsc_ctx_hirise_madnet_V1.0 and described in [7] along with a super-resolution 1m colour ORI and 2m DTM using SINGLE IMAGES only using the MADNet 2.0 (called "Super-3D") at https://www.cosmos.esa.int/web/psa/ucl-mssl_oxia-planum_cassis_srr-madnet_v1.0 and described in [8].

There are ≈3500 CTX DTM products most of which are co-aligned to HRSC DTMs and ORIs produced using CASP-GO based on ASP (https://github.com/mssl-imaging/CASP-GO) available at https://www.cosmos.esa.int/web/psa/UCL-MSSL_iMars_CTX_v1.0 which are described in [9]. All the UCL products are available through https://www.cosmos.esa.int/web/psa/ucl-mssl_meta-gsf. There will be some huge lunar MADNet products coming soon so please watch this space.

We are working on a 3m DTM of the whole of Valles Marineris using Super-3D based on CTX images co-registered and orthorectified to the aforementioned 12.5m HRSC ORI mosaic  by Sebastian Walter at FU Berlin.

We also developed an automated co-registration and ortho rectification scheme (ACRO, [10-12]) which was applied to thousands of CTX scenes of the South Pole [6] as well as to making a CTX mosaic of the MC11 map-quad reported in [12,13]. This software (part of which is available at https://github.com/UCL-iMars) is unsupported and in MatLab but the rest could be made available if someone is prepared to invest the time. Please get in touch if that is of interest.

It should be noted that the global CTX product available from Caltech and the global THEMIS product are NOT orthorectified and therefore are not co-aligned to anything apart form the 463m MOLA DTM which at the equator is really only 2km due to the sparse coverage.

Do get in touch if you have any follow-up questions

Best regards
Jan-Peter

-- 
Professor Jan-Peter Muller
Head, Imaging Group
Mullard Space Science Laboratory
Department of Space and Climate Physics
University College London
Holmbury St. Mary
Dorking
Surrey
RH5 6NT, UK
http://maps.google.co.uk/maps?f=q&hl=en&q=rh5+6nt&z=17&t=h

Tel:+44-1483-204151
Fax:+44-1483-278312
email: j.mu...@ucl.ac.uk
https://www.ucl.ac.uk/mssl/people/prof-jan-peter-muller
[1] Gwinner, K. et al. (2009) Derivation and Validation of High-Resolution Digital Terrain Models from Mars Express HRSC Data. Photogrammetric Eng Remote Sens 75, 1127–1142 

[2] Gwinner, K. et al. (2010) Topography of Mars from global mapping by HRSC high-resolution digital terrain models and orthoimages: Characteristics and performance. Earth and Planetary Letters 294, 506–519

[3] Gwinner, K. et al. (2016) The High Resolution Stereo Camera (HRSC) of Mars Express and its approach to science analysis and mapping for Mars and its satellites. Planetary and Space Science 126, 93–138
 
[4] Michael, G., et al., 2016. Systematic processing of Mars Express HRSC panchromatic and colour image mosaics: Image equalization using an external brightness reference. Planet. Space Science 121, 18-26, doi: 10.1016/j.pss.2015.12.002

[5] Tao, Y.; Michael, G.; Muller, J.-P.; Conway, S. J.; Putri, A. R. D. Seamless 3D Image Mapping and Mosaicing of Valles Marineris on Mars Using Orbital HRSC Stereo and Panchromatic Images. Remote Sensing 2021, 13, 1385. doi:10.3390/rs13071385

[6] Putri, A. R. D., Sidiropoulos, P., Muller, J. P., Walter, S. H., & Michael, G. G. (2019). A New South Polar Digital Terrain Model of Mars from the High Resolution Stereo Camera (HRSC) onboard the ESA Mars Express. Planetary and Space Science. DOI: 10.1016/j.pss.2019.02.010

[7] Tao, Y.; Xiong, S.; Conway, S. J.; Muller, J.-P.; Guimpier, A.; Fawdon, P.; Thomas, N.; Cremonese, G. Rapid Single Image-Based DTM Estimation from ExoMars TGO CaSSIS Images Using Generative Adversarial U-Nets. Remote Sens. 2021, 13, 2877. doi:10.3390/rs13152877

[8]  Tao, Y., Xiong, S.; Muller, J.-P.; Michael, G.; Conway, S. J.; Paar, G.; Cremonese, G.; Thomas, N. Subpixel-Scale Topography Retrieval of Mars Using Single-Image DTM Estimation and Super-Resolution Restoration. Remote Sensing 2022, 14, 1–25.doi:10.3390/rs14020257

[9] Tao, Y., Muller, J. P., Sidiropoulos, P., Xiong, S.-T., Putri, A. R. D., Walter, S. H. G., Veitch-Michaelis, J., Yershov, V. (2018) Massive Stereo-based DTM Production for Mars on Cloud Computers. Planetary Space Science, 154, 30–58. DOI: 10.1016/j.pss.2018.02.01.

[10] Sidiropoulos, P. & Muller, J.-P. A Systematic Solution to Multi-Instrument Coregistration of High-Resolution Planetary Images to an Orthorectified Baseline. Ieee T Geosci Remote 56, 78–92 (2018).

[11] Sidiropoulos, P., Muller, J.-P., Watson, G., Michael, G. & Walter, S. Automatic Coregistration and orthorectification (ACRO) and subsequent mosaicing of NASA high-resolution imagery over the Mars MC11 quadrangle, using HRSC as a baseline. Planetary Space Science 151, 33–42 (2017).

[12] Sidiropoulos, P. & Muller, J.-P. A Systematic Solution to Multi-Instrument Coregistration of High-Resolution Planetary Images to an Orthorectified Baseline. Ieee T Geosci Remote 56, 78–92 (2018).

[13] Sidiropoulos, P. & Muller, J.-P. Large-Scale Co-Registration of Mars High-Resolution NASA Images to HRSC: A Case-Study of the MC11-E Quadrangle. in vol. 47 2034 (Lunar and Planetary Science Conference, 2016).

mikita belikau

unread,
Aug 8, 2022, 9:18:49 AM8/8/22
to Jan-Peter Muller, astr...@gmail.com, Ames Stereo Pipeline Support

Jan-Peter Muller, thanks a lot for your detailed answer.
It's funny - I tried to reach you around a year ago ;-) and I failed with this task and it's really great to get your reply here on this topic.

I will certainly reach you - just need time to go through links you provided.
Again, thanks a lot. I really appreciate your help


--
You received this message because you are subscribed to a topic in the Google Groups "Ames Stereo Pipeline Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ames-stereo-pipeline-support/G9kRgwFeM_I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ames-stereo-pipeline...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/8bf92650-b1e3-ad37-0d5a-96f25c650198%40ucl.ac.uk.

astr...@gmail.com

unread,
Aug 8, 2022, 11:05:39 AM8/8/22
to Ames Stereo Pipeline Support
Thanks for the information, Jan.  As I said, my information for HRSC, which dates to about 2016/2017, might be out-of-date, and it sounds like some of it was.

mikita belikau

unread,
Aug 11, 2022, 4:53:28 PM8/11/22
to Ames Stereo Pipeline Support
Dear All!
While reading the docs you provided and digging deeper into theory behind it I tried to build a plan of the steps I need to do to align HiRISE images.

As I understand, high-level plan should look like this

1) Get DEM for HRSC
2) align HRSC to this DEM (using pc_align)
3) align CTX to HRSC from 2) (using pc_align)
4) align HiRISE to CTX from 3)  (using pc_align)

What I did so far is:

1) Get DEM for HRSC
I found a DEM for desired area in iMars http://i-mars.eu/web-gis.php
I downloaded both DEMs for spheroid and areoid, cause I don't know which one I need

2) align HRSC to this DEM (using pc_align)

I run this command

pc_align /Original/HMC_13E20_dt5.tif /Original/h2228_0002_bl3.lbl --max-displacement 10000 -o aligned

which gave me following output:

ASP 3.0.1-alpha
Build ID: 23a8216c
Build date: 2022-05-17

pc_align /Original/HMC_13E20_dt5.tif /Original/h2228_0002_bl3.lbl --max-displacement 10000 -o aligned

uname -a
Darwin Laptops-MBP.fritz.box 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64

sysctl -a hw 2>/dev/null | grep -E "ncpu|byteorder|memsize|cpufamily|cachesize|mmx|sse|machine|model" | grep -v ipv6
hw.ncpu: 4
hw.byteorder: 1234
hw.memsize: 17179869184
hw.perflevel0.l1icachesize: 32768
hw.perflevel0.l1dcachesize: 32768
hw.perflevel0.l2cachesize: 262144
hw.perflevel0.l3cachesize: 4194304
hw.optional.mmx: 1
hw.optional.sse: 1
hw.optional.sse2: 1
hw.optional.sse3: 1
hw.optional.supplementalsse3: 1
hw.optional.sse4_1: 1
hw.optional.sse4_2: 1
hw.cpufamily: 1479463068
hw.cachesize: 17179869184 32768 262144 4194304 0 0 0 0 0 0
hw.l1icachesize: 32768
hw.l1dcachesize: 32768
hw.l2cachesize: 262144
hw.l3cachesize: 4194304



Vision Workbench log started at 2022-08-11 22:13:01.

2022-08-11 22:13:01 {0} [ console ] : Detected datum from /Original/HMC_13E20_dt5.tif:
Geodetic Datum --> Name: D_MARS  Spheroid: MARS  Semi-major axis: 3396000  Semi-minor axis: 3396000  Meridian: Reference_Meridian at 0  Proj4 Str: +proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +a=3396000 +b=3396000 +units=m +no_defs
2022-08-11 22:13:01 {0} [ console ] : Will use datum (for CSV files): Geodetic Datum --> Name: D_MARS  Spheroid: MARS  Semi-major axis: 3396000  Semi-minor axis: 3396000  Meridian: Reference_Meridian at 0  Proj4 Str: +proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +a=3396000 +b=3396000 +units=m +no_defs
2022-08-11 22:13:01 {0} [ console ] : Computing the intersection of the bounding boxes of the reference and source points using 9000000 sample points.
2022-08-11 22:15:02 {0} [ console ] : Reference box: (Origin: (78.5086, 14.7424) width: 11.7319 height: 15.5158)
2022-08-11 22:15:02 {0} [ console ] : Source box:    (Origin: (77.054, 7.38124) width: 4.0071 height: 13.6041)
2022-08-11 22:15:02 {0} [ console ] : Intersection reference box:  (Origin: (78.5086, 14.7424) width: 2.55241 height: 6.24288)
2022-08-11 22:15:02 {0} [ console ] : Intersection source    box:  (Origin: (78.5086, 14.7424) width: 2.55241 height: 6.24288)
2022-08-11 22:15:02 {0} [ console ] : Intersection of bounding boxes took 120.684 [s]
2022-08-11 22:15:02 {0} [ console ] : Reading: /Original/HMC_13E20_dt5.tif
2022-08-11 22:15:12 {0} [ console ] : Loaded points: 19447395
2022-08-11 22:15:12 {0} [ console ] : Loading the reference point cloud took 9.95805 [s]
2022-08-11 22:15:12 {0} [ console ] : Reading: /Original/h2228_0002_bl3.lbl
2022-08-11 22:15:14 {0} [ console ] : Loaded points: 4606303
2022-08-11 22:15:14 {0} [ console ] : Loading the source point cloud took 2.18368 [s]
2022-08-11 22:15:14 {0} [ console ] : Data shifted internally by subtracting: Vector3(565037,3.1738e+06,1.04707e+06)
2022-08-11 22:15:14 {0} [ console ] : Loading reference as DEM.
2022-08-11 22:15:14 {0} [ console ] : Building the reference cloud tree.
2022-08-11 22:15:38 {0} [ console ] : Reference point cloud processing took 23.8119 [s]
2022-08-11 22:15:39 {0} [ console ] : Filtering gross outliers
2022-08-11 22:17:06 {0} [ console ] : Filtering gross outliers took 87.8384 [s]
2022-08-11 22:17:06 {0} [ console ] : Reducing number of source points to 100000
2022-08-11 22:17:10 {0} [ console ] : Number of errors: 100000
2022-08-11 22:17:10 {0} [ console ] : Input: error percentile of smallest errors (meters): 16%: 4636.03, 50%: 4965.27, 84%: 5128.57
2022-08-11 22:17:10 {0} [ console ] : Input: mean of smallest errors (meters): 25%: 4451.96, 50%: 4670.75, 75%: 4790.27, 100%: 5034.47
2022-08-11 22:17:10 {0} [ console ] : Initial error computation took 4.05211 [s]
2022-08-11 22:22:09 {0} [ console ] : Match ratio: 0.75001
2022-08-11 22:22:09 {0} [ console ] : Alignment took 298.412 [s]
2022-08-11 22:22:09 {0} [ console ] : Number of errors: 100000
2022-08-11 22:22:09 {0} [ console ] : Output: error percentile of smallest errors (meters): 16%: 34.9832, 50%: 110.51, 84%: 354.852
2022-08-11 22:22:09 {0} [ console ] : Output: mean of smallest errors (meters): 25%: 27.3362, 50%: 54.6555, 75%: 87.1502, 100%: 351.565
2022-08-11 22:22:09 {0} [ console ] : Final error computation took 0.508349 [s]
2022-08-11 22:22:09 {0} [ console ] : Alignment transform (origin is planet center):
  0.9981307946889654  0.01480199133395067 -0.05929433148375537    3785.381563750911
-0.01413245186957091    0.999831732678318  0.01169530391323897   -5667.984098547138
  0.0594574679725776 -0.01083546870321696   0.9981720303235636   -1110.772715296247
                   0                    0                    0                    1
2022-08-11 22:22:09 {0} [ console ] : 2022-08-11 22:22:09 {0} [ console ] : Centroid of source points (Cartesian, meters): Vector3(577775.16,3179670.8,1038291.4)
2022-08-11 22:22:09 {0} [ console ] : Centroid of source points (lat,lon,z): Vector3(17.811151,79.701203,-1566.3641)
2022-08-11 22:22:09 {0} [ console ] :
2022-08-11 22:22:09 {0} [ console ] : Translation vector (Cartesian, meters): Vector3(-11793.935,-2225.2647,-3108.9133)
2022-08-11 22:22:09 {0} [ console ] : Translation vector (North-East-Down, meters): Vector3(-1645.2428,11206.084,5042.9061)
2022-08-11 22:22:09 {0} [ console ] : Translation vector magnitude (meters): 12398.147
2022-08-11 22:22:09 {0} [ console ] : Maximum displacement of points between the source cloud with any initial transform applied to it and the source cloud after alignment to the reference: 23210.212 m
2022-08-11 22:22:09 {0} [ console ] : Warning: The input --max-displacement value is smaller than the final observed displacement. It may be advised to increase the former and rerun the tool.
2022-08-11 22:22:09 {0} [ console ] : Translation vector (lat,lon,z): Vector3(-0.02791236,0.19893747,-5023.9819)
2022-08-11 22:22:09 {0} [ console ] :
2022-08-11 22:22:09 {0} [ console ] : Transform scale - 1 = -4.773959e-15
2022-08-11 22:22:09 {0} [ console ] : Euler angles (degrees): Vector3(-0.62193913,-3.4086724,-0.81119203)
2022-08-11 22:22:09 {0} [ console ] : Euler angles (North-East-Down, degrees): Vector3(0.27078703,0.018475645,3.5524998)
2022-08-11 22:22:09 {0} [ console ] : Axis of rotation and angle (degrees): Vector3(0.18128273,0.95547769,0.2328067) 356.43719
2022-08-11 22:22:09 {0} [ console ] : Writing: aligned-transform.txt
2022-08-11 22:22:09 {0} [ console ] : Writing: aligned-inverse-transform.txt
2022-08-11 22:22:09 {0} [ console ] : Writing: aligned-beg_errors.csv
2022-08-11 22:22:10 {0} [ console ] : Writing: aligned-end_errors.csv
2022-08-11 22:22:11 {0} [ console ] : Writing: aligned-iterationInfo.csv
2022-08-11 22:22:11 {0} [ console ] : Saving to disk took 1.361244 [s]

From the output it seems to be Ok'ish, but I'd like to see this aligned HRSC file which I don't see. Should I run some additional command 

What are my next steps (assuming my high-level plan is correct)? Should I run bundle_adjust or mapproject?

I am asking, cause documentation contains sample of usage for another data (like csv) and it's not clear what to do next.


Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]

unread,
Aug 11, 2022, 5:09:04 PM8/11/22
to mikita belikau, Ames Stereo Pipeline Support
I guess the plan should be to align every single DEM to HRSC.

You will only have HRSC DEMs, I guess. The rest need to be produced.

Note that HRSC resolution is quite a bit lower than HiRISE, and likely also than CTX. I am not sure you will be able to get pixel-level agreement at CTX resolution or HiRISE resolution. It should be within the ballpark though.

I downloaded both DEMs for spheroid and areoid, cause I don't know which one I need

Only spheroid DEMs are supported.

2) align HRSC to this DEM (using pc_align)

> I run this command

> pc_align /Original/HMC_13E20_dt5.tif /Original/h2228_0002_bl3.lbl --max-displacement 10000 -o aligned


I don't quite know what the .lbl thing is. The tool expects DEMs in .tif files. I never used it with .lbl.


> 2022-08-11 22:22:09 {0} [ console ] : Translation vector magnitude (meters): 12398.147


That is a huge translation, 12 km. I am not sure what you are doing here. I don't know how one can get two DEMs on Mars to be so far off. 


> From the output it seems to be Ok'ish, but I'd like to see this aligned HRSC file which I don't see. Should I run some additional command 


See the pc_align doc for how to save the output point clouds.


> What are my next steps (assuming my high-level plan is correct)? Should I run bundle_adjust or mapproject?

> I am asking, cause documentation contains sample of usage for another data (like csv) and it's not clear what to do next.


You need to create stereo DEMs. That is a lot of work. You can start here: https://stereopipeline.readthedocs.io/en/latest/tutorial.html



Mauro S

unread,
Aug 11, 2022, 9:13:30 PM8/11/22
to mikita belikau, Ames Stereo Pipeline Support
Dear Mikita,

I 'm new to Stereo Pipeline , so please take all I will say with no offence and more like a  line of thinking and sorry if I comment on something very obvious to you.
So: 
If I did not understand wrong, you want to make a mosaic of CTX images from an area, and superpose HIRISEs . 
Did you checked this product? 


So let me express some things I learned and might help you:
1) you have different products from less to higher resolution-> hrsc images , ctx, hirise
And two dems available. Mola and hrsc dt4

Your workflow should be (please Oleg correct me)
1)Gather a ctx , pair,
2)make a DEM  with them (by using parallel_stereo  and pont2dem

3) allign that ctx_dem.tif to hrsc dt4 with pc_allign
4)re-do the dem using point2dem but this time introducing the allignment and asking for the orthoimage.

5) gather hirise pair,  and process with hiedr2mosaic.py
6)make a a dem with those as in 2
7)pc_align the hirise_dem to ctx_dem from 3
8)re do the dem as in 4 for the hirises,

Now the orthoimage from 8 should fit with ctx orthoimage.

I'm writing fro. Cellphone so tomorrow I will try to give you the commands for each step. But bassically I am following the workflow of this work



If you do not need the DEMs I think that is easy if you go throuh ISIS. 

A question I have after this is if instead of using pc_align we should use image_align 

Then the  workflow should be:
1) gather the ctx
2)mapproject to mola or the hrsc dt4
3)proces hirise edrs with hi2edr.py and maproject using cam2map from ISIS.
4)Image_align to the mapprojected ctx

This will produce a good mosaic ? Of caure it ia not ortorectified but will hirise and ctx match? I need to try it

Please  someone with more experience if can comment on this thoughts will be appreciated.

After this  Mikita if "we" succes, we can join and write some  "Stero for dummies" (it is so.ething I need)and share with the community.

Sorry all my english and fatfinger typos


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 on the web visit https://groups.google.com/d/msgid/ames-stereo-pipeline-support/d3cc8359-1aa9-4c38-abe2-06f2fe47746bn%40googlegroups.com.

Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC]

unread,
Aug 11, 2022, 9:33:01 PM8/11/22
to Mauro S, mikita belikau, Ames Stereo Pipeline Support
I am very skeptical that satellite image alignment problems can be solved without creating 3D models and aligning the DEMs and cameras, then projecting onto the aligned DEM. The image_align tool can't handle the fact that two images (maprojected or not) differ by a lot more than a shift.  

From: ames-stereo-pi...@googlegroups.com <ames-stereo-pi...@googlegroups.com> on behalf of Mauro S <mgs...@gmail.com>
Sent: Thursday, August 11, 2022 6:13 PM

To: mikita belikau <miki...@gmail.com>
Cc: Ames Stereo Pipeline Support <ames-stereo-pi...@googlegroups.com>
Subject: Re: [EXTERNAL] Re: Georeferencing CTX without gaps and shifts
 

Mauro S

unread,
Aug 11, 2022, 9:41:51 PM8/11/22
to Alexandrov, Oleg (ARC-TI)[KBR Wyle Services, LLC], mikita belikau, Ames Stereo Pipeline Support
Thanks Oleg, yes I agree specially if you have important topographic features.


mikita belikau

unread,
Aug 12, 2022, 4:32:18 AM8/12/22
to Ames Stereo Pipeline Support
Thank you very much for your detailed answer.
I guess, I am newer to ISIS/ASP/HiRISE than you, so all advices/suggestions from you and other persons are highly appreciated. And for sure, I am very grateful for this and I am not offended ;-)

Yes, you are right - at then end my final goal is to have geographically correct CTX (or HRSC, but CTX is preferable) as base layer with aligned HiRISE images. Assuming this is ready I will then produce shapefiles from this HiRISEs and will then publish them.
I particular I want to start with Jezero crater, so, obviously not all ready-to-use processed products could be used in the workflow for me. Correct me if I am wrong for Jezero crater there is nothing here http://murray-lab.caltech.edu/CTX/tiles/ , right? 

So, if you don't mind I will ask some question about what you replied.


"And two dems available. Mola and hrsc dt4"
So, sorry for dumb question, but currently I just have 1 DEM which I took from i-Mars website (Oleg said I need to use spheroid). And I am not quite sure if this is MOLA or HRSC DT4. How can I know this?


"1)Gather a ctx , pair,"
Ok, then question is: what should be the overlap for this? I understand that the more they overlap - the better, but is there some kind of rule for this?

"5) gather hirise pair,  and process with hiedr2mosaic.py"
Same question for overlap as for CTX. And here it's even more complicated, because of HiRISE coverage - even for Jezero crater it's not covered by HiRISE fully

"But bassically I am following the workflow of this work https://gi.copernicus.org/articles/8/293/2019/"
Ok, thanks a lot. I really need some step-by-step guide for "dummies" to proceed, cause as a newbie my impression is that you need to have a PHD to do all this things ;-)


"If you do not need the DEMs I think that is easy if you go throuh ISIS. "
Tooling is not that important as long as it is opensource. Just from what I got ASP is more user-friendly than ISIS 


"A question I have after this is if instead of using pc_align we should use image_align "
What I got from the replies of Oleg it is not possible to use image_align for this.

"we can join and write some  "Stero for dummies" (it is so.ething I need)and share with the community"
Sure! People don't need to struggle next time they want to do this.

Again, thanks for your reply. Will take some time to read this paper you're using as a reference for this workflow.

Regards,
Mikita

mikita belikau

unread,
Aug 12, 2022, 4:47:34 AM8/12/22
to Ames Stereo Pipeline Support
Oleg, thanks for your reply.

My comments are below.


" Only spheroid DEMs are supported.  "
Ok, got it.


" I don't quite know what the .lbl thing is. The tool expects DEMs in .tif files. I never used it with .lbl.  "
.LBL is a reference file with metadata andit comes always with JP2 file, so maybe I need to convert first JP2 to tif. Will see if this will change anything, but probably it will not change, cause if gdal or whatever software can't read .LBL files it throws an error which was not the case in my experiment, so will see.


" That is a huge translation, 12 km. I am not sure what you are doing here. I don't know how one can get two DEMs on Mars to be so far off.   "
What I was trying with his this  command


pc_align /Original/HMC_13E20_dt5.tif /Original/h2228_0002_bl3.lbl --max-displacement 10000 -o aligned

is to align HRSC image h2228_0002_bl3.lbl  to DEM HMC_13E20_dt5.tif

See the pc_align doc for how to save the output point clouds."
Ok, now I see 14.46.9 Will try this


Jan-Peter Muller

unread,
Aug 12, 2022, 7:47:03 AM8/12/22
to ames-stereo-pi...@googlegroups.com

Dear Colleagues

I addressed the specific comment about the Murray labs product but perhaps this was missed "It should be noted that the global CTX product available from Caltech and the global THEMIS product are NOT orthorectified and therefore are not co-aligned to anything apart from the 463m MOLA DTM which at the equator is really only 2km due to the sparse coverage of MOLA footprints."

There are an array of CTX and HiRISE products available for Jezero crater which USGS and JPL have produced, see https://astrogeology.usgs.gov/maps/mars-2020-jezero-crater-landing-site-controlled-orthomosaics which includes 3 CTX and 6 HiRISE products.

Best
Peter

On 12/08/2022 02:41, Mauro S wrote:

⚠ Caution: External sender


mikita belikau

unread,
Aug 12, 2022, 9:02:32 AM8/12/22
to Ames Stereo Pipeline Support
Jan-Peter, thanks a lot for our comment and reference.
Will explore links you posted

mikita belikau

unread,
Aug 13, 2022, 6:09:44 PM8/13/22
to Ames Stereo Pipeline Support
Dear all!
I am still trying to figure out what are my next steps considering the input that I have now for:

a) HRSC file
b) DEM for HRSC (downloaded from http://i-mars.eu/web-gis.php)
c) CTX file
d) HiRISE files. 

But now after investigating what Mr. Jan-Peter posted here https://astrogeology.usgs.gov/maps/mars-2020-jezero-crater-landing-site-controlled-orthomosaics I think that I can reuse this somehow to what I need to do for Jezero.

So, as I undestand, the link above contains:
2) Orthorectified CTX image itself that covers part of the Jezero crater https://astrogeology.usgs.gov/search/map/Mars/Mars2020/JEZ_ctx_B_soc_008_orthoMosaic_6m_Eqc_latTs0_lon0

This is all cool and this data partially cover Jezero crater with HiRISE.
So, now I am trying to figure out if this is possible to use this data as ground truth (reference) and align (coregister) other HiRISE images, which have overlap with subset from 4) with the help of pc_align or image_align. How do you think?

If this will work somehow - this would be great. However for me the original question still remains how to build a step-by-step algo with commands of what I need to do for the areas on Mars where there is no preexisting data in public domain.

Mauro S

unread,
Aug 13, 2022, 7:34:18 PM8/13/22
to mikita belikau, Ames Stereo Pipeline Support
The problem Mikita is that fpr the new hirises you want to incorporate you still need to orthorectified them.

So you still need for the new HIRISEs to generate a dem with an sterepair. 
So your workflow wiuld be 
1 have two overlaping hirises
2 generate a dem
3 align your new dem to the reference (hirise dem or ctx dem from the mosaic)
4 generate again the dem with the alignment info and at the same time tge orthorectified hirise image.
That final image should fit with the  public mosaic

I owe you the command for the workflow . If you wait me in two weeks I have some free time and share it with you 

Regarding your question we have MOLA as the main reference , from there the HRSC , with rhat you can generate your own ctx dems as your new reference and from there the hirise dems. 

mikita belikau

unread,
Aug 14, 2022, 11:38:31 AM8/14/22
to Ames Stereo Pipeline Support
Mauro, Ok, if even with this preexisting partial information I still need DEMs on all levels to align overlapping HiRISE images, then I will figure out how to do this. 
Feel free to provide commands - I hope, it will take me less then 2 weeks to understand this, but in case you'll still have time for this after 2 weeks - would be great to have it! ;-)
For now I will try to stick to the paper you mentioned as a base for your work.

Regards,
Mikita 

mikita belikau

unread,
Aug 21, 2022, 7:52:27 AM8/21/22
to Ames Stereo Pipeline Support
Dear All!
Still in the process of figuring out what is the RIGHT way to align HiRISE images (and possible CTX) with DEMs.
I went through all links you guys posted above. And I have some questions. Conceptual question.

1) I see that here https://astrogeology.usgs.gov/maps/mars-2020-jezero-crater-landing-site-controlled-orthomosaics for North-West part of Jezero crater we have DEM (for both HiRISE and CTX) and orthorectified images (both HiRISE and CTX)

Untitled 2.png

2) From the other side here  https://ode.rsl.wustl.edu/mars/productsearch we also have DEMs and orthorectified HiRISE images for nearly same area as we have in 1) (there is a good overlap)

Untitled.png

And if we compare how the orthorectified HiRISE images and DEMs from these 2 source look together - I see that there is also a shift 

Untitled 3.png

(which in turn means that there is also a shift between orthorectified HiRISEs)

So, my very naive question is following: since DEM and HiRISE aligned to it are supposed to be a 'ground truth' for me what should I consider for the North-West part of Jezero as 'true' ground-truth?
I suspect, that these DEMs and orthorectified HiRISE images were produced with different approaches (and maybe parameters) and that gave this difference, which as QGIS tells is more than 100 meters

Untitled 4.png

Is this Ok? As for me this difference is quite big.

Oleg Alexandrov

unread,
Aug 21, 2022, 11:57:39 AM8/21/22
to mikita belikau, Ames Stereo Pipeline Support
To understand the source of shift between DEMs from different sources you may need to very carefully study their assumptions and metadata. Note that sometimes there may be different ellipsoid radii used as well (one can check that with gdalinfo or in QGIS). Likely the Mars 2020 Jezero dataset cared more about local accuracy than global placement. Even if all your DEMs are from one source, say PDS, one should verify if any two of them agree and read about what they say their global alignment is relative to. The ASP pc_align tool can align DEMs and tell you the translation (in North-East-Down) coordinates that exists between them before the alignment. 

mikita belikau

unread,
Aug 22, 2022, 3:44:00 AM8/22/22
to Ames Stereo Pipeline Support
Oleg, thanks for your reply.
Indeed, I was suspecting that assumptions for these 2 datasets were different.
I am not quite sure I understand this part of your reply "Likely the Mars 2020 Jezero dataset cared more about local accuracy than global placement." My knowledge about the topic does not allow me to see the difference between these 2 ideas: global and local placements. How come they contradict each other? Because of different ellipsoid models used for them?

Jan-Peter Muller

unread,
Aug 22, 2022, 7:28:16 AM8/22/22
to ames-stereo-pi...@googlegroups.com

Dear Mikita

It looks like the CTX products were coaligned vertically with MOLA (https://astrogeology.usgs.gov/search/map/Mars/Mars2020/Jez_MARS2020_CTX_DEM_Science_Mosaic) and some horizontal georeferencing was done in ArcGIS Pro but against what image base is not stated. I thought I had seen that this was against HRSC but I cannot find any reference for this in any of these official products.

A HRSC map half-quad has been created of HRSC which has 50m DTM and 12.5m ORI with the PAN band available at the previously referenced official HRSC site at http://hrscteam.dlr.de/HMC30/MC13E/

I would start by looking at the offset of the CTX-ORI to the HRSC-ORI and then HiRISE wrt CTX. Hopefully it wont be spatially variant.

Good luck
Jan-Peter

Oleg Alexandrov

unread,
Aug 22, 2022, 11:39:06 AM8/22/22
to mikita belikau, Ames Stereo Pipeline Support
Here I was just guessing that the creators of the Mars 2020 Jezero dataset were not so focused on having their dataset align precisely relative to some global dataset. Not sure. 

mikita belikau

unread,
Aug 24, 2022, 3:22:44 AM8/24/22
to Ames Stereo Pipeline Support
Jan-Peter, thanks for your reply.
I am not quite sure what does this part mean "some horizontal georeferencing was done in ArcGIS Pro but against what image base is not stated". Does this mean that after automated procedures from ISIS/ASP/whatever framework
finished execution then manual alignment was done to fine-tune resulting image?

mikita belikau

unread,
Aug 24, 2022, 3:23:17 AM8/24/22
to Ames Stereo Pipeline Support
Oleg, thanks. Now it's more clear.

mikita belikau

unread,
Aug 24, 2022, 4:13:29 AM8/24/22
to Ames Stereo Pipeline Support
Dear all!
Now after digging deeper this topic I understand that there are many ways and approaches for creation of aligned HiRISE/CTX/etc.
And it's not always clear what technique/pipeline was used for the particular dataset.

As I understand different teams/organization use different input for alignment and it seems like often (or maybe even always) result of the work for teams/organization do not match each other ;-) Which is fine.
 
Now questions. As I see, website of The University of Arizona https://www.uahirise.org/results.php?keyword=Jezero&order=release_date&submit=Search has quite big archive of stereo pairs and attached DTMs/HiRISE orthorectified images. E.g., for Jezero crater area it has 170 images and most of them are stereopairs.
So, as I understand, I can directly get the orthorectified HiRISE images from there, cause they are already aligned. 
Now the question is how can I know what are the steps that were taken for creation of this DEMs/ORI HiRISE?
Another question is that Mars Orbital Data Explorer (PDS) https://ode.rsl.wustl.edu/mars/productsearch has also some amount DTMs and appropriate ORI HiRISE images.
And so, question is: is this the same data as university exposes? It's not clear cause website of the The University of Arizona has significantly bigger amount of DTMs then PDS is exposing (at least for Jezero crater region).
And the most important question: are these ORI HiRISE/DEMs produced in the same way for both university and PDS archive?

Jan-Peter Muller

unread,
Aug 24, 2022, 1:13:31 PM8/24/22
to mikita belikau, Ames Stereo Pipeline Support

Dear Mikita

The standard method for the UoA/HiRISE-PDS is the use of MOLA withoin the SOCET system developed by USGS to provide a base albeit the resolution difference is huge (≈1600 x). Another method is to mosaic individual HiRISE images together and then orthorectify to DTMs like MOLA.

Our approach is to create a cascade of spatial resolutions starting with HRSC level-4 products (with version #≥50) available from the ESA-PSA or mirrored PDS or if you're lucky the HRSC level-5 mosaiced images which have been employed bundle block adjustment (see Gwinner et al., 2016 for a full description of this standard photogrammetric technique). These HRSC products include DTMs at 50-150m spacing (dependent on the original *.ND (panchromatic) and *.S1 & *.S2 off-nadir stereo views (which are usually half the GSD of the nadir.

Using these HRSC ORI single-strip or mosaiced products (typically 100 images per half-quadrangle) you can then apply the ISIS interest-operator based automated co-registration (ACR) operator with your CTX images, create the stereo-based DTM and orthorectify the image. You can then repeat this exercise with HiRISE images using the CTX (6m) ORI image strips (or mosaic) as the new base image for HiRISE.

Hope that helps
Best regards
Peter

mikita belikau

unread,
Aug 26, 2022, 11:23:00 AM8/26/22
to Ames Stereo Pipeline Support
Dear Jan-Peter!
Thanks a lot for your message.

So, just to confirm that  got it right:

1) Since every team uses it's own pipeline/approach for creating the ORI HiRISEs (and possibly DTMs for them) it's Ok that ORIs from different sources are not aligned. And it's not just the pipeline, but also an auxiliary data that is used for this.
As I understand, your team uses CASP-GO software which has several modules and not all the modules are publicly available.  So, e.g. enthusiasts like me can not use this approach. Is this correct?

2) Considering that CASP-GO is not fully available publicly how do you think what other pipelines (like Chicago method, AU, etc) I can use for my initial task - to have globally aligned HiRISE (and possibly CTX/HRSC)? Do you have experience with any of them?

3) Another question for me is where to take stereo pairs images for generating DTMs. As I understand regardless of what pipeline/method you stick to you anyway need stereo pairs. For HiRISE images I can take them here https://www.uahirise.org/stereo/ , but it's not that clear where to take them e.g. for CTX. ODE interface https://ode.rsl.wustl.edu/mars/productsearch
gives all the images that satisfy certain criteria, but how to filter out only stereo pairs it's not clear. Maybe it does not have this at all. So, my question is where to take images for stereo pairs e.g. for CTX?

Regards,
Mikita Belikau

Jan-Peter Muller

unread,
Aug 26, 2022, 12:02:10 PM8/26/22
to ames-stereo-pi...@googlegroups.com

Dear Mikita

I have put inline responses below.

Good luck
Best regards
Peter

On 26/08/2022 16:23, mikita belikau wrote:
Dear Jan-Peter!
Thanks a lot for your message.

So, just to confirm that  got it right:

1) Since every team uses it's own pipeline/approach for creating the ORI HiRISEs (and possibly DTMs for them) it's Ok that ORIs from different sources are not aligned.
It certainly is not OK from my perspective for HiRISE products not to be aligned to a base reference map. I believe that where HRSC Level-5 mosaics and level-4 single strips are available, these would be your best source of reference maps. Given that there are often 12.5m orthorectified panchromatic nadir channel images available these can be used as base maps. Where CTX data is available then these can be co-registered to these HRSC basemaps but first they need to be co-registered and then orthorectified using the HRSC DTMs.

And it's not just the pipeline, but also an auxiliary data that is used for this.
As I understand, your team uses CASP-GO software which has several modules and not all the modules are publicly available.  So, e.g. enthusiasts like me can not use this approach. Is this correct?
The NASA PDART project is working on this and there is an alpha test version of C(ASP)-GO as an extension of ASP under development. The only routine not available is the kriging based gridpoint interpolation but ASP have. We do not have time to test the C(ASP)-GO version until late October due to pressures of other work. We are keen to have alpha testers but it is not guaranteed that everything will work smoothly.


2) Considering that CASP-GO is not fully available publicly how do you think what other pipelines (like Chicago method, AU, etc) I can use for my initial task - to have globally aligned HiRISE (and possibly CTX/HRSC)? Do you have experience with any of them
I am sure that other processing systems can be used, the key point here is the use of HRSC 3D mapping products as basemaps because they are inherently co-registered to MOLA which si teh global 3D height reference.


3) Another question for me is where to take stereo pairs images for generating DTMs. As I understand regardless of what pipeline/method you stick to you anyway need stereo pairs. For HiRISE images I can take them here https://www.uahirise.org/stereo/ , but it's not that clear where to take them e.g. for CTX. ODE interface https://ode.rsl.wustl.edu/mars/productsearch
gives all the images that satisfy certain criteria, but how to filter out only stereo pairs it's not clear. Maybe it does not have this at all. So, my question is where to take images for stereo pairs e.g. for CTX?

That is a GIS question and best targetted at a GIS analyst. I understand that the ODE shapefiles can be manipulated in ARCgis to extract possible stereo-pairs from any instrument which is not designed to capture stereo, like CTX or HiRISE. I have no familiarity with these tools and relied on former members of my group or collaborators at JPL and the Université de Nantes to do this for us. We do have MatLab code [1] which can find stereo and/or repeat and this was partially re-written by a former PhD student who has moved back to the Far East Asia.

The MatLab algorithm (non-GIS) is described in

[1] Sidiropoulos, P. & Muller, J.-P. On the status of orbital high-resolution repeat imaging of Mars for the observation of dynamic surface processes. Planet Space Sci 117, 207–222 (2015).

Stereo criteria for LROC-NAC which is also generally applicable to HiRISE and CTX is described in
[2]
Henriksen, M. R. et al. Extracting accurate and precise topography from LROC narrow angle camera stereo observations. Icarus 283, 122–137 (2017).

There was an old stereo-CTX catalogue produced by Ross Beyer in 2012 and we updated this to June 2016. It is downloadable from http://i-mars.eu/imars-products.php

Something that bitter experience showed us, you MUST look at the images before you try to match them as there are bad images due to situations such as transmission data drop-outs and dust storms. We tried to automate this filtering process [3] to obviate having to look at RDR images but we never managed to develop a robust system for CTX or HiRISE images due to lack of staff resources.

[3]  Sidiropoulos, P. & Muller, J.-P. Automatic quality assessment of planetary images. in vol. 10 EPSC2015-571 (European Planetary Science Congress, 2015). url: https://ui.adsabs.harvard.edu/abs/2015EPSC...10..571S/abstract

mikita belikau

unread,
Aug 27, 2022, 9:00:02 AM8/27/22
to Ames Stereo Pipeline Support
Jan-Peter thanks a lot for your response.
Is there a chance somehow to take part in testing of  this NASA PDART C(ASP)-GO? I don't see any reference for this publicly.

From what I understand i-mars project allows me download only HRSC DEMs

Untitled.png

even though it shows availability of HiRISE DEMs for part of Jezero crater I can't download them for some reason (there is no menu for this at least)

Untitled.png

Oleg Alexandrov

unread,
Aug 27, 2022, 12:51:50 PM8/27/22
to mikita belikau, Ames Stereo Pipeline Support
Is there a chance somehow to take part in testing of  this NASA PDART C(ASP)-GO? I don't see any reference for this publicly.

 
I don't think that logic will help you with your goal of alignment of images. Jan-Peter has some more code not part of that release, but I think that one is likely also orthogonal to your goals, but that's up to you two.

At some point this discussion should be taken offline, as this is a general-purpose forum and things have drifted a bit too far from asking questions about ASP itself.
Reply all
Reply to author
Forward
0 new messages