Landsat Earth for Orbiter (LEO)

[Urwumpe]

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.

 

[Spacethingy]

orbiter@home? :lol:
This looks absolutely awesome! I'm not anywhere near able to help I'm afraid (in any of the brain/soft/hard-ware departments ), but kudos to all you guys offering. Can't wait for the final result!

 

[4throck]

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:

 

[martins]

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]

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?]

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]

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]

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...

 

[Urwumpe]

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

I would say, no height map is then better than a random one.

 

[N_Molson]

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]

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.

 

[RisingFury]

I would say, no height map is then better than a random one.

What about approximating / generating a heightmap from tiles? You know, so that craters in terrain correspond to those on the image...

 

[Urwumpe]

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]

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]

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.

 

[Loru]

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]

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]

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]

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]

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 )