Discussion Mars Express/HRSC

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
The other day I attended the i-Mars Final Dissemination Event here at UCL (it's nice to find that your Uni shares interest in your hobby ;) )

i-Mars is (or was) a project to use high-resolution imagery (mainly the HRSC datasef generated by Mars Express, but also locally CTX and HiRISE) to create co-registered 3D datasets including elevation and orthoimages. They specialise mainly on finding change (new impacts, moving dunes, dust devil tracks, polar ice falls, etc.), but also showed a few cool 3D movies of terrain flyovers.

This got me to look into the HRSC data to use for Orbiter, to replace the current MOC/MOLA data. Unfortunately HRSC currently has got fairly patchy coverage, and they don't seem to provide high-level data products so far, so I'll need to stitch the mosaics together myself. But certain scenic areas like Valles Marineris and Olympus Mons seem to be well-covered, so I'll try a local high-res treatment of Valles Marineris to see if this is feasible.
 

llarian

Well-known member
Joined
Apr 1, 2009
Messages
575
Reaction score
159
Points
58
Location
Ottawa
I haven't checked recently myself either, but is there any chance that Pavonis Mons is included in the Valles Marineris and Olympus Mons datasets?
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
I haven't checked recently myself either, but is there any chance that Pavonis Mons is included in the Valles Marineris and Olympus Mons datasets?

The front page of the i-Mars site contains the current level-4 DTM coverage (actually from 2015, according to the caption). According to that, Pavonis Mons is not covered. In fact I may have been wrong about Olympus Mons as well.

Level-3 coverage is more extensive (75% of the surface according to another quote), but I think level-3 doesn't contain the stereo DTM data. I don't know if only a subset of the level-3 data is suitable for level-4 generation, or if they are simply still in the processing pipeline.

I am currently generating a global DTM mosaic from all the level-4 data I can find (up to orbit 6500) to see what is available. Might take me a while to download and process.

Edit: Level-5 coverage is even sparser. Level-5 contains the co-registered mosaics. (hopefully including seam removal). Currently there appears to be only a single area ("MC11E", identified on the i-Mars image) available at level 5. This area was of interest since it contains a number of landing sites.
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Just a quick update on this. It's taking a bit longer than expected (and I am feeling bad for neglecting potentially more pressing issues for this, but hey, it's my hobby ;) ):

I have pretty much completed the HRSC elevation layer (using the current MOLA data to fill the gaps). This is looking quite reasonable, but may need more work. I am currently averaging the data from overlapping HRSC fragments, but it would be better to establish a quality ranking of the fragments and add them to the mosaic in order of quality (worst to best). Mars Express has quite an elliptic orbit, so the camera distance varies considerably. And since the data are generated from stereo images rather than radar distance measurements, image quality (lighting conditions, local weather) also affect the elevation data quality. I am in contact with a researcher at FU Berlin who is working on the HRSC data, and I got a quality ranking list for some parts of the surface which I will try for this.

The surface texturing will take more work. For a start, the amount of data is huge (12.5 m resolution for the panchromatic nadir images - my 2TB drive dedicated to Mars data is slowly filling up with the HRSC data).

The first processing step is a brightness correction against a global albedo reference. I am using my MOC mosaic for that: The global MOC mosaic is mapped into a low-resolution bilinear basis expansion. Each of the HRSC fragments is mapped into the same basis, the basis coefficients are shifted to fit the reference, and then used to adjust the low spatial frequencies of the full resolution HRSC fragment. In other words, at frequencies of the basis expansion and lower, the surface will look like the MOC reference, while higher frequencies will make use of the HRSC high resolution data.

Next, the fragments are feathered and added on top of the MOC background.

Adding HRSC colour channels is yet more work. The colour channels are lower resolution (50m) than the panchromatic channel, so I will need to employ some pansharpening mechanism. I am trying different colourspace conversions (HSV, HSI, HSL, LAB) to see which extracts the closest match to the nadir channel.

The other problem is that there is no real global colour reference to match the fragments to. According to a paper, the FUB guys are simply matching against a constant "Mars" colour at low frequency, but maybe I can do a little better and use the MDIM/Viking composite as a reference. Problem is, I am not too happy with the albedo on this image, so I might try to do another colourspace conversion and swap the intensity channel against MOC. I might need to do the entire mosaicking in HSI space anyway, because some HRSC fragments have a nadir channel but no colour channels.

To top it all, the original MOC data was mapped into an areographic reference frame, while MOLA and HRSC are using areocentric coordinates. For the current Orbiter Mars data, I mapped MOLA to areographic, but now it makes more sense to map everything to areocentric (and it better matches Orbiter's rendering geometry anyway). Also, I am now using elevation data referenced against the reference sphere instead of the geoid, so the oblate ellipsoid shape of Mars will be correctly represented.

TL:DR: I'm still crunching away at making Orbiter better :cheers:
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
Excellent Textures martins! Any plans for Mercury or Venus?

Don't know - do you have sources for good quality high resolution orthoimages and DTMs?

I always have a slightly bad conscience when spending a lot of time on those textures. My time would probably be better spent on actually working on the Orbiter code. The textures could really be done by anybody with a bit of geoimage processing knowhow and way too much time on their hands.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Don't know - do you have sources for good quality high resolution orthoimages and DTMs?

I always have a slightly bad conscience when spending a lot of time on those textures. My time would probably be better spent on actually working on the Orbiter code. The textures could really be done by anybody with a bit of geoimage processing knowhow and way too much time on their hands.

And some CPU cycles spare... and a Matlab license AFAIR, or did this change?
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
And some CPU cycles spare... and a Matlab license AFAIR, or did this change?

Well yes, for most of my processing pipeline I'm using Matlab, but that's just a matter of convenience, since I am pretty familiar with it. But since much of the pipeline needs to be rewritten from scratch for each new project anyway, this isn't written in stone. Much of the Matlab code is just invoking external GIS utilities like GDAL, and I suspect GDAL integrates much better with Python than Matlab.

Some of the tools I did do myself (for example an edge-distance function I am using for feathering the image fragments when building mosaics), I did in C++ for performance's sake and then just compiled into a Matlab mex file. Probably compiles just as well into a Python module. You are welcome to it if you want to give it a go. :thumbup:
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Well yes, for most of my processing pipeline I'm using Matlab, but that's just a matter of convenience, since I am pretty familiar with it. But since much of the pipeline needs to be rewritten from scratch for each new project anyway, this isn't written in stone. Much of the Matlab code is just invoking external GIS utilities like GDAL, and I suspect GDAL integrates much better with Python than Matlab.

Some of the tools I did do myself (for example an edge-distance function I am using for feathering the image fragments when building mosaics), I did in C++ for performance's sake and then just compiled into a Matlab mex file. Probably compiles just as well into a Python module. You are welcome to it if you want to give it a go. :thumbup:


Good to know :) Venus would be some stronger problem, since we have only radar altimeter data and would to guess on the geology.

But AFAIR, Venus would be a the best next candidate since we have full Magellan data of it. Mercury is still WIP.

Not sure if I can really give it a go, I still know about nothing about how to do such a project. But it sounds like a solvable problem, for example like OpenFOAM, which is a series of specialized C++ modules based on a common domain model chained together by configuration files to process a simulation. Maybe it would be possible to do the same to have something like a common backend for Orbiters planet texture model and changing front-ends and middleware processing pipelines for different data sources.
 
Last edited:

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
1,008
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Don't know - do you have sources for good quality high resolution orthoimages and DTMs?

This will start you on the right direction, as far a I know:
https://astrogeology.usgs.gov/searc...es/Venus_Magellan_Topography_Global_4641m_v02

I only ask that if you convert the radar "surface" images, you invert the brightness scale. To me it looks perfectly realistic with darker basalt tones. I hate that bright orange look...


On that site, there are other "products" available, like Pluto, just browse that site for Digital Elevation Maps:
https://astrogeology.usgs.gov/searc..._presentation_form&v1=Digital+Elevation+Model
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
To quote the Doctor.

To top it all, the original MOC data was mapped into an areographic reference frame, while MOLA and HRSC are using areocentric coordinates. For the current Orbiter Mars data, I mapped MOLA to areographic, but now it makes more sense to map everything to areocentric (and it better matches Orbiter's rendering geometry anyway). Also, I am now using elevation data referenced against the reference sphere instead of the geoid, so the oblate ellipsoid shape of Mars will be correctly represented.

We already can with the 2016 planet texture+elevation data.

For very oblate planets like the gas/ice giants (and probably for Earth as well) we would need an "oblateness" parameter. That can correct radius as a function of latitude. This parameter would be needed in: rendering the atmosphere, rendering L1-4 planet textures, and calculating atmospheric altitude.

Currently having a spherical Earth is a limit for NASSP because the AGC assumes an ellipsoidal earth when running programs like P22, it also presents some problems for the LVDC with launch site radius (although we do have a workaround, so this has been on our wishlist for a while.


For the terrain, all we'd need to is reprocess the elevation data. The other parts are a bit harder.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Changing the rendering code to work with elliptical body would be a real nightmare. What about simply altering the radius of the sphere depending on camera location ?
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Oh whoops. I did not mean to post that in this thread. This was suposted to go in the thread Urwumpe just created....

Your method could work, in low orbits, but what about the case of a high orbit over Jupiter's equator. The limb of the planet has a definite elliptical shape. "Terrain" wise this is easy to accomplish, just some reprocessing.

The hard parts would be lighting (eclipses, that you just implimented, and vessel shadowing), and atmosphere haze.

Since ellipses are a pain to work with mathematically, could we approximate them?
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Jupiter and other gas giants are special cases in rendering. They have their own renderer which doesn't use atmospheric rendering at all. So, making them elliptical isn't that much of a problem. I haven't thought about any approximations, but yeah why not, do you have some ideas how to ? Maybe a transformation between sphere and ellipsoid (approximation) could be done in the vertex shader for Jupiter and alike, without need to mess-up with tile 3D-structures. This would probably not work for Earth.
 

jarmonik

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 28, 2008
Messages
2,651
Reaction score
785
Points
128
Just wait a minute. We can just flatten the graphics by reducing the length of polar axis in a matrix. Which would leave the sunlight occlusion checks. This would not work for planets with land-able solid surface.
 

n72.75

Move slow and try not to break too much.
Orbiter Contributor
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,687
Reaction score
1,337
Points
128
Location
Saco, ME
Website
mwhume.space
Preferred Pronouns
he/him
Just wait a minute. We can just flatten the graphics by reducing the length of polar axis in a matrix. Which would leave the sunlight occlusion checks. This would not work for planets with land-able solid surface.

Well my point in linking to that post by Martin, is that we already have oblateness for Mars. And mars has a higher oblateness than Earth. I don't think this is currently properly handled by our atmosphere class, but that's super easy to fix.
 
Top