new Moon textures from LRO-LOLA data !

[emazarico]

The LOLA data is now available on NASA PDS !
You can find the common products at http://imbrium.mit.edu/DATA/, but we also created GeoJPEG2000 files (available in http://imbrium.mit.edu/DATA/LOLA_GDR/), much easier to import in software like ArcGIS (projection information is included in the headers, so that should work transparently).

And we are also releasing ready-made textures for Celestia! Some of you had produced normal maps from the Kaguya altimetry data, but I encourage you to check out these new VTs. In addition to a LOLA normal map, a texture showing the topography in false-color was made. Both are 32k (level0-5).
More details at http://imbrium.mit.edu/EXTRAS/CELESTIA/

Enjoy !

Erwan
for the LOLA Science Team

[Cham]

Thanks a lot for these textures! The colorfull texture (with and without the normal map) is simply awesome !

[chris]

Beautiful!

Looks like there are still some seams visible between stripes, but it's still an incredible experience to explore the Moon with this new normal map applied. I'm looking forward to seeing the final maps. Can you tell us how much additional elevation data is expected to be gathered?

--Chris

[t00fri]

Hi Erwan,

if looked at in "splendid isolation" (i.e. LOLA normalmap only), the new LOLA topography data are really very nice. Since the Kaguya experiment claims to have very good control over the coordinate precision, I overlaid as a first testing step the normalmaps from Kaguya and LOLA, both as obtained with my nmtools.

Indeed, there are local mismatches of up to 2-4 pixels for a 2048x1024 normalmap size. I am sure you have discussed this with the Kaguya people already. What's the result??

In addition, there is a substantial mismatch with the Clementine base data, which is well known and not surprising. John Van Vliet already went through a tedious remapping algorithm with the Celmentine data relative to Kaguya. But now (as he also noted over at our CM site) there is the additional mismatch of Kaguya versus LOLA...Any thoughts you might want to share?

One question one might have is whether everybody used the same Moon radius?

Fridger

[John Van Vliet]

--- edit ---

[emazarico]

Chris:
good eyes. We had some issues with the blending of various 10-degree latitude band grids, but that should be settled very soon. (too much data to do it globally at once).
We're expecting LOLA to continue operating for much longer. So far we've collected >1.3 billion measurements. The main thing for global scale though is the cross-track spacing at the equator, and only time can help fill those in. After 1 year of nominal mission (~September), we should have an average spacing at the equator of about 1-1.5km. That's 1/30th of a degree. So the level 4 should be pretty well covered. Keep in mind that the swath width (from the 5 beams) is just 50m, so there will always be quite a bit of interpolation going on between the various tracks for the highest resolution grids.
We're also working on improving the orbits themselves, which should reduce artifacts due to geolocation inconsistencies between adjacent tracks. This will especially improve the normal maps, which are most sensitive to those artificial steps.

Fridger:
we did look at differences with Kaguya early on, but have not characterized it recently.
Everybody's using 1737.4km.
We created a special 32768x16384 grid to generate those VTs (not a standard PDS product), so there shouldn't be further interpolation/downsampling errors. And our orbits should not be off by kilometers (which is the level of your mismatch). I will look into that...

John:
the normal map "exageration" factor is 2.0
Looking forward to using your new Clementine map (it's not out yet, right?).

[John Van Vliet]

--- edit ---

[emazarico]

Improved VTs available on the same website.
There is still a very small seam issue at the equator. We will also correct the (bigger) 0/360 step in the near future.
Also, for the image, I now write the 8-bit BIN directly instead of going through GMT/imagemagick/etc; this may remove some of the "offsets" which you observed? If not, those are probably real

Chris, one thought regarding VTs. Currently, I have to redefine the grids every time to be -180/180 instead of the "standard" 0/360 (and given I forget everytime, I end up having to do everything twice!). In addition, this is/will be the standard for other missions. Is it possible/easy to implement a flag in the CTX files that can tell Celestia to expect a 0/360 map?

[John Van Vliet]

--- edit ---

[emazarico]

I am not saying this is the international standard. I am just saying that NASA planetary missions are likely to use this standard from now on. Expect Mercury, Vesta, etc. maps to also be 0/360. Obviously, this is workable, so it is not a problem. But it would also probably be very few lines of code change. I understand modifying the ssc files is a bad idea, and it would not allow to mix VTs with different longitude origin.

[t00fri]

Erwan,

We created a special 32768x16384 grid to generate those VTs (not a standard PDS product),

it would be great if you could also offer the non-tiled elevation data as signed 16 bit binary format in 32k size on your site. I mean precisely those data that you used for your 32k VTs.

Since people working with textures here use ISIS3 a lot, it could also be .cub (ISIS Cube) format or an .IMG/.LBL pair, whatever is convenient. One reason is e.g that I am implementing a number of improvements into my VT tools (as I wrote to you already) and also want to generate direct VT tiles in highest quality DXT5nm that my latest Nmtools (and Celestia) support as well. Incidentally, the latest nmtools also come with CUDA support for saving time.

Thanks,
Fridger

[John Van Vliet]

--- edit ---

[t00fri]

t00fri the LDEM_64.LBL/LDEM_64.IMG is 23040x11520
http://imbrium.mit.edu/DATA/LOLA_GDR/
but it is 16 bit unsigned

just convert it

John,

that I know, thanks. I have been playing with this PDS data set so far. What I think would be important, is to have the SAME data as used for Erwan's VT's but non-tiled. As he wrote, their 32k data set was specially made (not just blown up from the 22.5k data).

Fridger

[John Van Vliet]

--- edit ---

[t00fri]

John

at this early state it would not make much of a difference
the 64 px/deg has such a low point count
as you can see from this highpass

From a more scientific perspective, there are a number of good reasons for working with precisely the same data as the ones released by the scientific team... I also suppose that the sampling density will improve with time.

It is indeed straightforward to get rid of most stripes with a standard combination of lowpass and highpass filters, but this does not have high priority right now, in my view.

Fridger

[emazarico]

Fridger,
I suppose I can make this 32k product available to you. It will not be available through the same website, so I will put it in a temporary space, on Monday hopefully. Is a JP2 ok? I don't know if your nmtools could handle 32bit, but GMT grd file would be another option.

Erwan

[t00fri]

Fridger,
I suppose I can make this 32k product available to you. It will not be available through the same website, so I will put it in a temporary space, on Monday hopefully. Is a JP2 ok? I don't know if your nmtools could handle 32bit, but GMT grd file would be another option.

Erwan

Many thanks, Erwan. That is very good news.

Yet, it sounds as if there is little chance to always have the corresponding un-tiled data set available after each update? Perhaps it would then be better to take the official LRO-LOLA data at PDS as a reference? For now at least, the sampling density seems too low for more than 16k textures, I would say. The 64 pixel/degree LRO-LOLA data set@PDS is thus about the maximum for now (without too much visible striping).

As to the format, there is some clearcut "convenience hierarchy":

• 1: 16 bit signed (-32768 .. 32767) => short type in C++
• 2: 16bit unsigned (0 .. 65535) => unsigned short type in C++
  (as used at the PDS archive for LRO-LOLA data)
• 3: ISIS cube format (.cub)
• 4: JP2

(1) and (2)
=========
Signed 16bit integers are accepted by Nmtools without any modiifications.

Since with

Code: Select all

DN = digital input number,
offset = 1737400 m,  (moon reference radius)
scale factor = 0.5

radius = DN * scale factor + offset;


+++++++++++++++++++++++
a conversion of DN <-> unsigned 16bit integers @PDS to signed 16bit integers would also require a corresponding modiification of offset = 1737400 m. That should not be forgotten (John?)
+++++++++++++++++++++++

The conversion itself in my Nmtools is trivial. I will presumably soon release a version accepting BOTH signed and unsigned 16bit integer input. However, the nmtools are not coded to handle 32bit.

Signed or unsigned 16 bit integers represent a popular
scientific input format ...

Typically: PDS IMG / LBL imaging data

(3) ISIS format is very convenient, since there are ISIS routines that can import IMG to ISIS3 and also generate any kind of binary data from .cub.

(4) JPEG2 format is the least convenient for many, since typically it would require the GDAL utilities to convert. They are VERY slow....

Thanks,
Fridger

[t00fri]

I just started a hopefully fruitful CelestialMatters thread about the new LRO-LOLA Moon imaging with a photoshooting in Celestia (.Sci), based on just 8k non-tiled Moon textures, with lots of useful links and some relevant notes about using my Nmtools in this context!

http://forum.celestialmatters.org/viewt ... =7803#7803

Enjoy,
Fridger

[John Van Vliet]

--- edit ---

[RVS]

LRO team had recently released new version of Moon topography data (http://imbrium.mit.edu/DATA/LOLA_GDR/). I used it (http://imbrium.mit.edu/DATA/LOLA_GDR/CDEM_64.IMG) to produce new 16K normalmap.
The comparison with the old one reveals some improvements in details. As well as in many previous cases (and in the case of data for Mars in http://pds-geosciences.wustl.edu/missio ... megdr.html) polar areas are by some esoteric (for me ) reasons very noisy, so I used additionally http://imbrium.mit.edu/DATA/LOLA_GDR/LDEM_80N_80M.IMG and http://imbrium.mit.edu/DATA/LOLA_GDR/LDEM_80S_80M.IMG files in polar stereographic projection and reprojected them. The result is not ideal, but quite acceptable. (Screen shots here are without albedo map:)


Let me remember an old topic: 'Earth-rise' and 'Earth-set' images were taken by the KAGUYA. Please compare my new rendering of the same scene with the full resolution photo from JAXA site:

The progress is obvious.
If you would intend to produce similar maps, don’t forget to take into account, that LOLA data are published with SCALING_FACTOR=0.5 (i.e. we need to use height exaggeration 0.5 to obtain realistic normalmap).
Unfortunately, the alignment with the existing surface maps (I use john Van Vliet’s, as without doubt the best now) is not perfect :