Landsat Earth for Orbiter (LEO)

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,646
Reaction score
138
Points
153
Location
Langendernbach
A bit of googling shows open source versions of these functions for other languages. It should be feasible to at least script them, I would think.

And GeoTIFF specifications can also be found online if it helps.

I also have a GeoTIFF library for Java on my notebook.
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,003
Reaction score
117
Points
88
Location
Lisbon
Website
orbiterspaceport.blogspot.com
I can't help with the data, my laptop can't handle it.

But I can give some advice regarding image processing:
» Do a full resolution luminance mosaic
» Do a 1/3 or 1/4 resolution color mosaic with consistent results in mind. Using band X or Y will not matter much because the actual ground color will change with seasons, atmospheric dust/water vapour, etc, etc.
» Merge both as a final step

Dont' know if this will speed anything up, but I guess that working with larger areas might improve color stability.


Now, an even better approach would be to load the data separately.
Use a global lower resolution color map, and then generate the high resolution shadings using the height data and normal maps.
And of course, a specmap to give the albedo variations.
This setup could handle seasonal variations and might be easier to assemble.

Finally, if you simply correct a satellite image to match the colors seen at the ground, it will not work, because the light is completely different. From Orbit you have 2x atmospheric effects, from the ground only 1x. That's why the images are always so blue.

Sorry for rambling about so many things, but it might be helpful, because I've worked with satellite images many years ago and actually calculated atmospheric corrections by chanel, season, hour, etc, etc. It aint worth the effort, simply eyeball it :)

Just my :2cents:
 
Last edited:

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
But I can give some advice regarding image processing:
» Do a full resolution luminance mosaic
» Do a 1/3 or 1/4 resolution color mosaic with consistent results in mind.

Thanks for the input! I was thinking along a similar line, by histogram-registering the mosaics to the low resolution VisibleEarth map, i.e. use the high spatial frequency content from the Landsat images, and the colour information from the VE map. I am not sure about the definition of luminance, but I guess the principle is similar?

Here are the results from that experiment so far:

This is the VisibleEarth texture as currently used by Orbiter:


This is the high-resolution Landsat mosaic registered to the above image - it matches quite well


But the difference is of course in the detail. This is what the current texture looks like at extreme zoom:


And this is the corresponding Landsat image:


I am not entirely satisfied yet, so I'll keep exterimenting with the colour balance and histograms a bit more. My other idea was to do a FFT of the high-resolution Landsat image and the low-resolution VE maps, and substitute the VE data for the low frequency parts of the Landsat FT.

I like your idea about seasonal changes! But I guess that may still be a while ahead for Orbiter.
 

Linguofreak

Well-known member
Joined
May 10, 2008
Messages
4,125
Reaction score
30
Points
73
Location
Dallas, TX
One thing that does concern me a bit:

Between 3D terrain and high resolution imagery, how much is this going to weigh? X-Plane 9's global scenery runs around 80 gigs just for terrain meshes without any imagery.
 

Post much?

New member
Joined
Sep 10, 2009
Messages
28
Reaction score
0
Points
0
Will you go for maximum pltex quality when assembling the mosaic? The default map as it stands flags small islands as water and the coasts' specularity looks blocky because the tolerance is set too high. I feel when making a map of this size, skimping on the landmask stands in harsh contrast to the otherwise spectacular view at Level 15/16.
 

Xyon

Puts the Fun in Dysfunctional
Administrator
Moderator
Addon Developer
Webmaster
GFX Staff
Donator
Beta Tester
Joined
Aug 9, 2009
Messages
6,628
Reaction score
96
Points
123
Location
10.0.0.1
Website
www.orbiter-radio.co.uk
One thing that does concern me a bit:

Between 3D terrain and high resolution imagery, how much is this going to weigh? X-Plane 9's global scenery runs around 80 gigs just for terrain meshes without any imagery.

Plus that of other planets and moons, I suspect it might get quite large quite fast. It seems to be a perennial problem facing flight simulators - Orbiter will undoubtedly suffer with it more, because of its seamless scope.

Hard drive space isn't the premium it used to be, but 100GiB is still a lot - especially when pulled through a residential internet connection (like my 8Mbps one). Concerning, indeed, but still awesome in effect.
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
6,856
Reaction score
0
Points
0
Location
Toulouse
The "big ones" are going to be mostly the Earth, the Moon, & Mars I guess. For other planets & moons, coverage is often partial and the quality is lower. Though there is a regular progress (MESSENGER, Cassini, "soon" New Horizons...) in that area.

For unmapped bodies, I guess that a "random" heightmap generator should do it...
 

N_Molson

Addon Developer
Addon Developer
Donator
Joined
Mar 5, 2010
Messages
6,856
Reaction score
0
Points
0
Location
Toulouse
I would say, no height map is then better than a random one.

Depends, you probably want to recognize some known features like the Alps, the Himalayans, The Grand Canyon, Valles Marineris, Apollo landing sites, Tycho, Olympus Mons etc...
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
For unmapped bodies, I guess that a "random" heightmap generator should do it...

Generally yes, although I would argue that this would be a good application for the EPP sdk. If possible, could the EPP libraries be included with the next release (with Jedidias permission of course), and used to generate the randomized terrain? I can try to provide example code of how a system like that would work if needed.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,646
Reaction score
138
Points
153
Location
Langendernbach
What about approximating / generating a heightmap from tiles? You know, so that craters in terrain correspond to those on the image...

Is pretty hard to do. Then it would maybe be better to use low-quality terrain data from various sources - or like I said, no terrain at all, just a flat ellipsoid like it is now.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
0
Points
0
Location
404 ROAD NOT FOUND
I would go with procedural generation. Complete procedural generation if no heightmap, partial procedural generation if low-res heightmap, no procedural if high-res heightmap. That way you can have a LOD 16 in Alps, Himalaya and the Grand Canyon and have a base LOD 7 heightmap for the rest of the world, where Orbiter will seamlessly generate your LOD 16 based on that.
 

BruceJohnJennerLawso

Dread Lord of the Idiots
Addon Developer
Joined
Apr 14, 2012
Messages
2,585
Reaction score
0
Points
36
Is pretty hard to do. Then it would maybe be better to use low-quality terrain data from various sources - or like I said, no terrain at all, just a flat ellipsoid like it is now.

May be relevant to this:

http://forum.kerbalspaceprogram.com/entries/667-Procedural-Craters

I would like procedural craters myself, but it may not always work well due to the performance demands of constantly processing each crater over the whole surface. (ie overlapping craters affecting a single vertex twice) A decent way around this is to have a "crater map" data file that gets added on as a single layer (processed as a single addition heightmap that gets added to the main one). The "cratermap" file itself is generated before runtime by a SDK tool that reads a list of craters & generates the heightmap then. Craters would probably need something like center point lat/lon, rim height, central peak height/width/lon/lat, etc.
 
Last edited:

Loru

Moderator
Addon Developer
Donator
Joined
Sep 30, 2008
Messages
3,733
Reaction score
1
Points
36
Location
Warsaw
Few questions about patches/elevation.

How elevation map is implemened at the moment??
Elevation map or mesh?

In first case do elevation map patches have the same sizes and coordinates as texture maps?

In second case is it single global mesh or also patches loaded from separate files? (and what is format of the pach mesh if any)
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
35,646
Reaction score
138
Points
153
Location
Langendernbach
May be relevant to this:

http://forum.kerbalspaceprogram.com/entries/667-Procedural-Craters

I would like procedural craters myself, but it may not always work well due to the performance demands of constantly processing each crater over the whole surface. (ie overlapping craters affecting a single vertex twice) A decent way around this is to have a "crater map" data file that gets added on as a single layer (processed as a single addition heightmap that gets added to the main one). The "cratermap" file itself is generated before runtime by a SDK tool that reads a list of craters & generates the heightmap then. Craters would probably need something like center point lat/lon, rim height, central peak height/width/lon/lat, etc.

Well, you have to differ between Orbiter and KSP in one very important aspect: Orbiter uses a real solar system (our own) with real topography.

KSP uses a fictional (but inspired on our own) solar system, that has fictive topography.

That makes it easier to use procedural terrain, since it is its own reference.

Would you recognize Olympus Mons, if it is made by procedural terrain?
 

martins

Orbiter Founder
Orbiter Founder
Joined
Mar 31, 2008
Messages
2,352
Reaction score
9
Points
0
Website
orbit.medphys.ucl.ac.uk
Just a quick update, in case you were wondering why I first ask for help, and then don't follow up on it ...

Trouble is, whenever I test a new mosaic, I seem come across a new problem in my processing pipeline that I need to fix before distributing the code to you guys.

The latest issue was the fact that towards the equator, the overlap between the landsat scenes becomes smaller, to the point where the feathering mechanism described in the article isn't sufficient anymore to blend neighbouring scenes seamlessly. I have now switched from simply averaging the matched neighbour histograms to a linear interpolation between them over the area of a scene. This essentially blends the scenes not just over the overlap area, but over the entire scene support. I am still testing if this method is robust (if the overlap becomes too small, the histogram matching process itself may become unstable, if not enough samples are available to populate the entire histogram with sufficient accuracy).

I've also ironed out a few other bugs along the way that caused artefacts in specific scenes. Also, the code now automatically blends the water surfaces with low-resolution data from the VisualEarth map.

In the process of testing my tile generation algorithms, I've by now downloaded about a terabyte of Landsat data. (I tried to sample a wide variety of latitudes and surface types, to make sure that this doesn't cause problems).

Anyway, I still hope to upload the tile generation code sometime soon, to spread out the workload a bit. It will probably be Linux only, unless not enough potential helpers can handle that.
 

dbeachy1

O-F Administrator
Administrator
Moderator
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
8,615
Reaction score
184
Points
138
Location
VA
Website
alteaaerospace.com
BTW I have a Fedora x64 VM I can use to help with this once it's ready to go. I can also create a shared FTP account on my server that everyone can use to upload finished map data where Martin can then grab it. :) Once the project is ready to start I'll create the FTP account and PM the password to each person who needs it.
 

SolarLiner

It's necessary, TARS.
Addon Developer
Joined
Jun 14, 2010
Messages
1,847
Reaction score
0
Points
0
Location
404 ROAD NOT FOUND
As I don't want another dual boot problem, my Virtual Machine will do for Linux. Still here to help if needed (and I think it is hugely needed for now ;) )
 
Top