kamaz
Unicorn hunter
- Joined
- Mar 31, 2012
- Messages
- 2,298
- Reaction score
- 4
- Points
- 0
Hello,
I am trying to convert lunar DEMs (digital elevation models) produced by the LOLA instrument aboard LRO into Orulex heighmaps. This was a partial success, but I have run into a few problems. So I will first describe how to get and convert the data and then list the issues I have run into.
Before I start, I would like to thank Martin Schweiger for writing Orbiter, artlav for making Orulex, MIT for the LOLA instrument and the produced data, and NASA/JPL for launching the probe that LOLA can ride on
Data source. The datasets can be downloaded from http://imbrium.mit.edu/DATA/LOLA_GDR/CYLINDRICAL/IMG/ . The interesting files (global) have names like LDEM_xxx.IMG, where xxx is data resolution in pixels per degree (i.e. LDEM_64.IMG means 64 pixels per degree, or roughly 500m per pixel). For resolutions higher than 128 pixels per degree, the files contain geografically smaller areas, as specified in file name. E.g. LDEM_1024_45N_60N_300_330.img means the area between 45N and 60N latitude and 300E (60W) and 330E (30W) longitude. (This particular area covers the northern shore of Sinus Iridum, Montes Jura and Bianchini crater which I was using for testing, because it is some spectacular terrain just a few seconds of flight out of Brighton Beach).
Data format. The .IMG files contain altitude maps in cylindrical projection. Each pixel is a 16-bit signed integer (little-endian). Pixel value is altitude above the reference sphere (R=1737.4km), expressed in meters * 2. (IOW, divide the pixel value by 2 to get altitude in meters). Each .IMG file is accompanied by a corresponding .LBL file which contains data description. The two most important lines in the .LBL file are LINES_SAMPLES which is the image size in X (longitude) and LINES which is image size in Y (latitude). The bitmap starts in the NW corner of the mapped area.
Data conversion. Conversion into Orulex heightmaps is relatively straightforward. The only issue is that the global DEMs appear to cover the area between 180W and 180E (and not 0E and 360E as the .LBL file says and Orulex wants). But that was trivial to fix. The conversion was done using two Python scripts (ActivePython 3.2) attached to this post -- one is for global DEMs, the other is for non-global DEMs.
Results. See the attached screenshots, showing the Bianchini crater and Montes Jura. default.jpg shows the view with artlav's heightmap ( http://orbides.1gb.ru/orbf/moon-hmap-lv8.zip ) . kaguya.jpg is rendered using the Kaguya dataset add-on I got from http://orbiter-forum.com/showthread.php?t=11250 . LRO.jpg is LRO data at 64 pixels per degree (LDEM_128.IMG downconverted to 64 pixels per degree). LRO512.jpg is rendered using the partial file LDEM_1024_45N_60N_300_330.img downconverted to 512 pixels per degree (you can see that the tile ends to the right of the image).
Problems encountered.
1. There appears to be a problem with artlav's original heightmap. It has minimum and maximum pixel values of -6000 and +8483, while Kaguya heightmap has -9140 and +10716 and my LRO heightmap has -9126 and +10759. The highest mountain peak on the Moon is +10786 m according to LRO stereo imaging -- http://lroc.sese.asu.edu/news/index.php?/archives/302-Highest-Point-on-the-Moon!.html -- which agrees both with Kaguya and LRO heightmaps (considering that the mountain peak in question is probably somewhere between the points of the DEM grid). artlav's heighmap thus has considerably smaller range, which, I believe, is the issue with underlying (Clementine?) data it is generated from. However, what I don't understand, is that if you look at screenshots, Montes Jura rendered from artlav's heightmap just look flat compared to Kaguya and LRO heightmaps. And I mean really flat -- the DG in the screenshot is flying at 29.71km alt over Sinus Iridum, and in real life, Montes Jura raises something like 5km above the level of Sinus Iridum (see http://imbrium.mit.edu/BROWSE/LOLA_GDR/LDEM_1024_45N_60N_300_330.HTML , bottom-right of the map).
2. After converting LDEM_128.IMG at full resolution (46080 x 23040) and saving the result into Heightmaps\moon-lv8.hei, Orulex crashes with "Undefined HEI loading error". However, after reducing the resolution by half (to 64 pixels per degree, i.e. 23040 x 11520) it works, as shown in the screenshot. After playing around with loading the produced global heightmap as a tile covering 1/4 of the Moon, I have found that I can load the 64 pixels per degree heighmap once but not twice. So I'm guessing that it is probably an out-of-memory error. The error message coud be more telling, however...
3. I have attempted to convert and load the partial 1024 pixels per degree heightmap LDEM_1024_45N_60N_300_330.IMG as a tile covering the relevant area (downsampled to 512 pixels per degree). This produced two issues:
3.a. After putting the heightmap coordinates in the moon.cfg file like this:
the heightmap appeared on the opposite hemisphere. I had to change the coordinates to:
to place it where it should be. That looks like a bug.
3.b. As you can see by comparing LRO.jpg and LRO512.jpg, there is no visible difference between the two. Which is very strange, because one is rendered with a DEM at 64 pixels per degree and the other one is at 512 pixels per degree (albeit only locally) -- i.e. 8 times the resolution. Yet it looks the same. In other words, I have loaded a DEM with 8 times more resolution, yet there is no improvement. Is there some DEM resolution limit that I am not aware of?
4. Question: What are memory limits related to loading high-resolution DEMs in Orulex? In particular, if we split the DEM accross many tiles, will it save memory, because Orulex will not load tiles which are currently invisible (i.e. on the opposite side of the planet)?
5. Question: What is the meaning of pixel data in the .hei file? I guess that it should be altitude in meters above the reference sphere, but it is not documented anywhere AFAICT, so, was my guess right?
6. Question: what is the "scale" argument when loading a heightmap tile in moon.cfg?
7. Question: does the "-lv8" part in the name of global heightmap (i.e. "moon-lv8.hei") mean something? After renaming the file to moon-lv9.hei, the global heightmap did not load. Also, what is the meaning of heightmap levels and associated config parametes (LevLimit, GlobalHMapLimit)?
Orulex.dll version is 0.19.0453, timestamp 2008-09-09. Orbiter 2010P1. My Orulex.cfg and moon.cfg files are attached.
Any help on the issues raised would be greatly appreciated.
Also, everyone is welcome to download and convert the data themselves
I am trying to convert lunar DEMs (digital elevation models) produced by the LOLA instrument aboard LRO into Orulex heighmaps. This was a partial success, but I have run into a few problems. So I will first describe how to get and convert the data and then list the issues I have run into.
Before I start, I would like to thank Martin Schweiger for writing Orbiter, artlav for making Orulex, MIT for the LOLA instrument and the produced data, and NASA/JPL for launching the probe that LOLA can ride on
Data source. The datasets can be downloaded from http://imbrium.mit.edu/DATA/LOLA_GDR/CYLINDRICAL/IMG/ . The interesting files (global) have names like LDEM_xxx.IMG, where xxx is data resolution in pixels per degree (i.e. LDEM_64.IMG means 64 pixels per degree, or roughly 500m per pixel). For resolutions higher than 128 pixels per degree, the files contain geografically smaller areas, as specified in file name. E.g. LDEM_1024_45N_60N_300_330.img means the area between 45N and 60N latitude and 300E (60W) and 330E (30W) longitude. (This particular area covers the northern shore of Sinus Iridum, Montes Jura and Bianchini crater which I was using for testing, because it is some spectacular terrain just a few seconds of flight out of Brighton Beach).
Data format. The .IMG files contain altitude maps in cylindrical projection. Each pixel is a 16-bit signed integer (little-endian). Pixel value is altitude above the reference sphere (R=1737.4km), expressed in meters * 2. (IOW, divide the pixel value by 2 to get altitude in meters). Each .IMG file is accompanied by a corresponding .LBL file which contains data description. The two most important lines in the .LBL file are LINES_SAMPLES which is the image size in X (longitude) and LINES which is image size in Y (latitude). The bitmap starts in the NW corner of the mapped area.
Data conversion. Conversion into Orulex heightmaps is relatively straightforward. The only issue is that the global DEMs appear to cover the area between 180W and 180E (and not 0E and 360E as the .LBL file says and Orulex wants). But that was trivial to fix. The conversion was done using two Python scripts (ActivePython 3.2) attached to this post -- one is for global DEMs, the other is for non-global DEMs.
Results. See the attached screenshots, showing the Bianchini crater and Montes Jura. default.jpg shows the view with artlav's heightmap ( http://orbides.1gb.ru/orbf/moon-hmap-lv8.zip ) . kaguya.jpg is rendered using the Kaguya dataset add-on I got from http://orbiter-forum.com/showthread.php?t=11250 . LRO.jpg is LRO data at 64 pixels per degree (LDEM_128.IMG downconverted to 64 pixels per degree). LRO512.jpg is rendered using the partial file LDEM_1024_45N_60N_300_330.img downconverted to 512 pixels per degree (you can see that the tile ends to the right of the image).
Problems encountered.
1. There appears to be a problem with artlav's original heightmap. It has minimum and maximum pixel values of -6000 and +8483, while Kaguya heightmap has -9140 and +10716 and my LRO heightmap has -9126 and +10759. The highest mountain peak on the Moon is +10786 m according to LRO stereo imaging -- http://lroc.sese.asu.edu/news/index.php?/archives/302-Highest-Point-on-the-Moon!.html -- which agrees both with Kaguya and LRO heightmaps (considering that the mountain peak in question is probably somewhere between the points of the DEM grid). artlav's heighmap thus has considerably smaller range, which, I believe, is the issue with underlying (Clementine?) data it is generated from. However, what I don't understand, is that if you look at screenshots, Montes Jura rendered from artlav's heightmap just look flat compared to Kaguya and LRO heightmaps. And I mean really flat -- the DG in the screenshot is flying at 29.71km alt over Sinus Iridum, and in real life, Montes Jura raises something like 5km above the level of Sinus Iridum (see http://imbrium.mit.edu/BROWSE/LOLA_GDR/LDEM_1024_45N_60N_300_330.HTML , bottom-right of the map).
2. After converting LDEM_128.IMG at full resolution (46080 x 23040) and saving the result into Heightmaps\moon-lv8.hei, Orulex crashes with "Undefined HEI loading error". However, after reducing the resolution by half (to 64 pixels per degree, i.e. 23040 x 11520) it works, as shown in the screenshot. After playing around with loading the produced global heightmap as a tile covering 1/4 of the Moon, I have found that I can load the 64 pixels per degree heighmap once but not twice. So I'm guessing that it is probably an out-of-memory error. The error message coud be more telling, however...
3. I have attempted to convert and load the partial 1024 pixels per degree heightmap LDEM_1024_45N_60N_300_330.IMG as a tile covering the relevant area (downsampled to 512 pixels per degree). This produced two issues:
3.a. After putting the heightmap coordinates in the moon.cfg file like this:
Code:
//heightmap =--------------file name-----------------|lower lat|upper lat|west lon|east lon| scale |O|F|U
heightmaphei=moon_45N_60N_300_330 |+000000045|+000000060|+0300.0000|+0330.0000|00032768|2|0|1the heightmap appeared on the opposite hemisphere. I had to change the coordinates to:
Code:
//heightmap =--------------file name-----------------|lower lat|upper lat|west lon|east lon| scale |O|F|U
heightmaphei=moon_45N_60N_300_330 |+000000045|+000000060|+0120.0000|+0150.0000|00032768|2|0|1to place it where it should be. That looks like a bug.
3.b. As you can see by comparing LRO.jpg and LRO512.jpg, there is no visible difference between the two. Which is very strange, because one is rendered with a DEM at 64 pixels per degree and the other one is at 512 pixels per degree (albeit only locally) -- i.e. 8 times the resolution. Yet it looks the same. In other words, I have loaded a DEM with 8 times more resolution, yet there is no improvement. Is there some DEM resolution limit that I am not aware of?
4. Question: What are memory limits related to loading high-resolution DEMs in Orulex? In particular, if we split the DEM accross many tiles, will it save memory, because Orulex will not load tiles which are currently invisible (i.e. on the opposite side of the planet)?
5. Question: What is the meaning of pixel data in the .hei file? I guess that it should be altitude in meters above the reference sphere, but it is not documented anywhere AFAICT, so, was my guess right?
6. Question: what is the "scale" argument when loading a heightmap tile in moon.cfg?
7. Question: does the "-lv8" part in the name of global heightmap (i.e. "moon-lv8.hei") mean something? After renaming the file to moon-lv9.hei, the global heightmap did not load. Also, what is the meaning of heightmap levels and associated config parametes (LevLimit, GlobalHMapLimit)?
Orulex.dll version is 0.19.0453, timestamp 2008-09-09. Orbiter 2010P1. My Orulex.cfg and moon.cfg files are attached.
Any help on the issues raised would be greatly appreciated.
Also, everyone is welcome to download and convert the data themselves
