I think the problem is that the data points are interpolated there at the edges, but not across the edge. If you get what I mean. So when they interpolated the missing data, near by data points weren't taken into consideration since they were at the other side of the image. That's my theory anyway

FWIW - IMG2PNG does work with the IMG's for me - but it's got a signed-problem I think.

I got the same problem opening it in Photoshop (it doesn't allow you to select signed or unsigned). I fixed it by adjusting the output and input levels to move the bright colors down and the dark colors up.

John...
as I noted earlier in response to mhoward, there was an issue with the cylindrical IMGs being unsigned instead of signed. This was corrected. Did you see that, and are talking about the IMGs currently on the website?


I personally haven't tried with the IMGs, but the JP2s seem fine when overlaid over a Clementine basemap. What do you mean by "way off" ?

Erwan

Did you see that, and are talking about the IMGs currently on the website?

yes but i still have not talked to them .
I still need to re check
the "signed" problem is that the is the 32/16 bit issue and the offset that is listed it the .LBL
example the 4 px/deg
------------
SCALING_FACTOR = 0.5
OFFSET = 1728216.

----- and -----
SAMPLE_TYPE = LSB_UNSIGNED_INTEGER
SAMPLE_BITS = 16
-------------------

the map is in positave east and 360
with the left 0 and right 360

BUT
qview and map2map see it is
the left north( 90lat 0long) as 0 lat and 180 long
and sees the middle pixel ( o lat 180long) and -90 and 360
only the north west 1/4 has map info

this is mostlikely do to the pixel values from 32 bit and 16 bit

Erwan,

I don't think there are any major problems with the most recent *.LBL files, but I wonder if it would be possible to upload copies of "LDEM_4.LBL" and "LDEM_16.LBL" with the "OFFSET" parameter in "OBJECT = IMAGE" corrected to "1737400." <meters>? The text description implies this is the offset used for forming the signed integers, but it is correctly listed on the machine-readable "OFFSET" line only in "LDEM_64.LBL". The other two *.LBL files, as John points out, give "1728216.", a number which may never have been correct.

This may seem a very insignificant point -- since users can easily hand-edit these text files -- but I was writing directions on how to use the LOLA data with a program that automatically reads the *.LBL files associated with the *.IMG files, and this seems to add an unnecessary level of complication and confusion.

In LDEM_16.IMG, assuming the 0.5 m per count scaling and 1737.400 km reference radius are correct, I find minimum and maximum data values of -9.047 km (at line 2566, sample 3001) and +10.614 km (at line 1354, sample 3221); a slightly smaller range, so far, than the Kaguya values of -9.140 km and +10.716 at nearly the same positions in their 16 samples per degree grid. This would correspond to a LOLA height range, from the Moon's center, of 1724.953 (minimum) to 1744.614 km (maximum). Is that correct?

Since obtaining altimeter data by satellite at a particular geographic point seems largely a matter of luck, I was wondering, as many must be, if anyone on the LOLA team has attempted integrating the raw data from Kaguya with the new data from LRO to produce a more complete and denser data set from which a more comprehensive gridded product might be produced?

One other very minor point: the *.LBL files say your grid is reported in the "MEAN EARTH/POLAR AXIS OF DE421" coordinate system. To the best of my knowledge, the Moon's Mean Earth/Polar Axis system is offset from the JPL DE421 ephemeris system by small rotations about each axis. Did you apply those corrections? If so, did you use the rotations recommended in the "IAU/IAG Working Group on Cartographic Coordinates" reports of Seidelmann et al. or some other ones?

Finally, although I find nothing materially wrong with the *.LBL files, I find the references to "planetopotential TOPOGRAPHY" and "GEOID" in the explanation of the data format slightly confusing. As I understand the explanation, the data represent "PLANETARY_RADIUS" rather than "planetopotential TOPOGRAPHY", and since no geoid is defined, and no correction for it required to use the data, the references to this additional computation seem unnecessary?

-- Jim Mosher

For what it's worth, I witnessed at LPSC an interesting interaction between a member of the LOLA team and a Chinese scientist on this subject that would be relevant here. The Chinese scientist was quizzing the LOLA team member on their tracking methods, and during his response the LOLA team member expressed frustration that only NASA was providing, as part of their data release, the tracking data on the spacecraft. Without tracking data I think it would be impossible to integrate LOLA data with Kaguya LALT or Chang'E topographic data. It may even be very hard to do so with the tracking data; I don't know. But I think it's impossible unless JAXA or China choose to provide that data, along with less-derived data products.

Ittiz

on almost all ( blue marble is an exception) maps there is a bit of a mis-match ether at the 0- 360 ( or -180 to 180 )

i have yet to see one that in not .

John,

Nothing is 32bit except the GRDs.



Jim,


This seems sensible. I will double-check tomorrow and correct it.
We are working on improving the labels in general. Very soon you'll have one label file per product format (jp2,img,grd).
Bottom line, I think LDEM_64.LBL is correct.



Good to see people integrating the data in their program already
On that website you say "Nonetheless, LOLA gridded data covering the period 2009-07-13 through 2009-12-17 are (unofficially?) available on an MIT website." Actually, this MIT website is the official LOLA PDS data node. PDS archives/mirrors it.


Emily is perfectly correct in her post. We don't want to take the Kaguya data at face value (even though they've done a good job) and simply put them in. The LOLA data are geolocated based on LRO orbit solutions, which we understand and are working on improving... And with time, we'll cover (very close) to those Kaguya tracks.


I think all your answers will be found in :
ftp://naif.jpl.nasa.gov/pub/naif/generic_...orientation.pdf
If you're familiar with SPICE, basically, in addition to using the "de421.bsp" kernel, we also load the following kernels, which define the "MOON_ME" frame.
moon_pa_de421_1900-2050.bpc, moon_080317.tf, moon_assoc_me.tf, also available from the NAIF website.


well, you can see that as superficial; but it's just recalling what is in this dataset, so that people know it's not geoid-related ("huge discovery: lava flows going uphill!"). We may release planetopotential topography grids in the future. Plus, in the RDRs, the geoid value at each LOLA point is defined.


Erwan

Thanks, Erwan! I have corrected my information. Thanks for your other answers, as well.

-- Jim

hi Erwan my fault i am used to 16 bit images as -32768 to 32767 or 0 to 65536
and the values for luner radi 1737400 + the lola measurement gives odd results in photo editors and
even in qview
like the img2png example above

having values so large can push the pixel value to a double or a 32 bit float
that is why i posted a different LBL

But on a different note

the 64 px/deg looks very nice for such an early product

a simple "emboss " on it .

This spot with dark rays is about where the Apollo 14 LM was impacted west of Fra Mauro. The image number is in filename.

Phil

Click to view attachment

The website with the Celestia textures has been updated with improved textures (new ZIP files).
Seams that were visible at 10-degree latitude interval are now gone, and the color scale for the false-color image has been changed.
There are still some minor issues with the normal map (equator, 0 longitude), so they may be further updated, but not immediately.

Erwan


screenshots (click to enlarge; large files ! ~4Mb, 2560x1600)

Most people are familiar with Ina (D-Caldera). Here are some mini-Inas on the floor of Hyginus crater. They were visible in Lunar Orbiter images, but not very clearly. Image number is in the filename.

Phil

Click to view attachment

This is what I do with the data:

Nice one, Ittiz! That's a LOT of water!

I'm updating my IMG2PNG utility to correctly convert LROC images to PNGs. The NAC images now get correctly converted except for one problem: Image orientation. Does anyone know how to determine from the embedded labels or the index.tab file whether an image needs to be mirror-flipped?

From LROCSIS.pdf (page 3) in the documents directory:


At first I thought I thought this was simple, i.e. that the NAC-R images needed to be mirror-flipped but apparently things are more complex: M102443238RC.IMG does not need mirror-flipping whereas M114185541RC.IMG needs to be mirror-flipped (unless I've managed to get myself totally confused).

you might not be .The minor errors in PDS are enough to make one confused
and as with any new release there will be some errors

but this is only a guess as i have not gone past the lola data yet .

I just had a long phone conversation with Mark Robinson. The very short version: it's complicated, and confusing even to him. The slightly longer version: you need the spacecraft kernels to figure out when to flip the images, and those haven't been released yet. Which one is oriented properly depends on three things: L vs R camera, which direction the spacecraft was facing (which is a thermal control issue), and whether imaging happens on ascending or descending orbits, which changes once every six months as the orbit evolves (it _just_ happened again a couple days ago). Mark said there is actually an active debate within the instrument team right now for whether they should make a change to the EDRs and go ahead and mirror-flip the ones that need flipping with the next release. They will have to re-release everything anyway to improve the calibration. I said I was hereby voting that they make that change! In the meantime, without the spacecraft kernels, I think all we can do is just inspect each image pair to determine which ones need flipping.

Also, he said that releasing WAC mosaics shouldn't be too far in the future, maybe 1 to 2 months; they're now 80% of the way to calibrating out the photometric effects.

Thanks, this information was very useful. I agree that it would be nice to have the images correctly oriented. Also it would be nice if the labels (or index.tab file) included the direction the spacecraft was facing and whether the orbit was ascending or descending. Then it would be possible to determine when to flip the images that need flipping if they do not get flipped in the next release.

The index.tab file includes the subspacecraft point, north azimuth and upper/lower left/right lat/lon. It may be possible to use some of this information to determine whether to mirror-flip but I don't think it would work in all cases.

I asked if they couldn't just put a flag in the header indicating whether the image needed to be flipped or not. His response was that most of the scientists were using ISIS to deal with the images (not to mention a surprising -- to him -- number of amateurs), and that if you have ISIS, you'll never even see this problem once the spacecraft kernels are released. But he was sympathetic to the plight of those of us who either fear ISIS or are stuck with Windows machines for one reason or another. For his part, he said he actually didn't care -- he is not one of the people who doesn't want to change the way the data came down from the spacecraft. He pointed out that the data are already changed, since there are actually two sets of electronics within each of the two cameras; the two sets of electronics handle every other line of the detector, something they had to do in order to get the readout rate for each line under the 337 microseconds it takes the spacecraft to advance one pixel's distance along track. Those two different sets of electronics are the source of the striping in early versions of images. He said that their calibration now corrects about 95% of that striping.

Hey! that's a Venusian cloud pattern....

Comparison between Kaguya DEM 16 and LRO-LOLA DEM16. Lola seems more defined.
Comparison

Sorry but the direct link to the photos don't work

Ciao
VB

ValterVB you might want to look at my posts on shatters.net ( search)


the lola is a mush larger image
32768x16384 px VS. the kaguya at 5760x2880 px

BUT if one looks at the close up's of
lola data


the one on the right is the raw tiff
( the left is a "cleaned up" version)
there are very few points .
Now this WILL improve over time so

also there is a remapped moon ( clementine) map posted here on this site - just search
or use the one mentioned on the mit web site
http://imbrium.mit.edu/EXTRAS/CELESTIA/

-- i know a shameless plug---

My experiments are with pure 3d not with normal map.
With LDEM64 I have some problem with memory (too much points...), so I try to install Ubuntu 64 bit and then try to rendering with this DATASET

I have a question: Are available high resolution dataset of the Apollo11 landing site?

Ciao
VB

Sorry for my english

no .Besides me and one other and the mit lola team the 23 k lola 64 px/deg is the highest res that is available
and that is a low point count inferred map .
for the apl 11 site you will need to use stereo pairs and "stereo pipeline" (ALPHA release) in ISIS 3

Not quite 11, but USGS covered Apollo 15 when working with the Apollo Pan Cam.

http://astrogeology.usgs.gov/Projects/webgis/

Someday, I'd like to work with that data set.

Joel Raupe just identified the Ranger 9 impact crater in an LROC image:

http://lunarnetworks.blogspot.com/2010/04/ranger-9.html

It's clear from a comparison with Ewen Whitaker's identification of the crater in an Apollo 16 image that this is correct.

Phil

I've been mapping the tracks of Lunokhod 2. The background map is a reduced version of a map I made a while ago, combining Apollo 15 images and the Soviet-era map of the route. Over it I have superimposed LROC images with the actual route shown in red. It's still uncertain in places so there are gaps, especially a large one near the beginning.

The drivers made a route map as they were going, but it was not precise because they did not have precise distance or direction information. An entirely separate issue is how that route should be positioned on the Apollo 15 images. The comparison shows they were often 500 m out, sometimes more. That's pretty good considering the difficulty of this type of work.

One interesting observation - they started a bit further north than they thought, drove further south than they expected and ended up further north than they thought. So the total distance driven probably exceeds the 37 km often stated.

Phil

Click to view attachment

Nice job!
I think the 37km is correct- it was based on the odometer thing dragging along at the rear of the rover.

ADMIN: FULL INLINE QUOTE REMOVED

"I think the 37km is correct- it was based on the odometer thing dragging along at the rear of the rover."

Yes, but that doesn't take slippage or gunk in the bearings (or other possible issues) into account. Odometers only give approximate results at the best of times.

Phil

Awesome work, Phil.

Superb Phil,
and very appreciated,.
Thanks

Indeed, I believe that the moon would have a super rotating atmosphere like Venus does due to its slow rotation.

A nice high sun view of Apollo 15.

Phil

Click to view attachment

"Joel Raupe just identified the Ranger 9 impact crater in an LROC image"

Nice impact! Now that we have LROC images of the interior of Alphonsus crater I'm planning to look at the "infamous dark patches" along the rilles on the floor near the rim, as well as the central peak, both of which were areas identified as "Lunar Transient Activity" sites in the 1960's.

--Bill

nice shot Phil
cool find
i will be having it here for a few days
Click to view attachment

I was looking for Ranger 6 when I chanced upon this - a new version of Ina in Mare Tranquillitatis. As far as I know this has not been seen before.

Phil

Click to view attachment

While browsing the LROC images, I found this interesting feature in Giordano Bruno crater: it looks like a frozen swirling pattern in a pool of impact melt.
Click to view attachment

Oh very cool. Which of the LROC images is that from?

Looks like an MI image of a concrete cast block that might have been taken during an MER ORT. Very nice.

For both the one I posted and charborob's (not sure which one was cool!), the image number is in the filename if you save it.

Phil

Duh. Thanks.

Here is an Apollo 15 orbital image of Ina and a PSRD article on lunar venting.

http://www.psrd.hawaii.edu/WebImg/moon-Ina.gif

http://www.psrd.hawaii.edu/Nov06/MoonGas.html

Ina has been imaged in LROC image M113921307L/R and was discussed in HIGH RESOLUTION IMAGING OF INA: MORPHOLOGY, RELATIVE AGES, FORMATION. M. S. Robinson. et al, 41st Lunar and Planetary Science Conference (2010)

http://www.lpi.usra.edu/meetings/lpsc2010/pdf/2592.pdf

--Bill

Here my last experiment with global map. I have used the LDEM 64 with Blender.
http://valter31.interfree.it/LRO_LOLA_DEM_64.jpg

Ciao
VB


ADMIN - DO NOT EMBED A 4000 x 4000 IMAGE STRAIGHT INTO A THREAD!!!

Edited to change it to a link

Sorry...

Ciao
VB

I said above that I had been looking for Ranger 6. Here it is:

Click to view attachment

The LROC team just put out a list of sites they have found so far. Turns out Ranger 6 was in the same image I was looking at earlier, I just didn't see it.

Phil

... and Ranger 8. Ejecta are not so obvious in this low sun view. The crater is right at the middle of this cropped image, with a bright 'arrow' of ejecta appearing to point at it. The 'arrow' is really a bit of bright ejecta fringed by two dark rays. This image was subsampled 2x for downlink so it has only 1 m/pixel resolution.

Phil

Click to view attachment

... and the Apollo 17 SIVB. Here, the pixel coordinates given in their table only work after the raw image is flipped.

EDIT: This does get confusing. Their pixel coordinates have to be flipped to get the right spot. But the image as presented is in the correct orientation. I had flipped the image to match their coordinates, but now I see they had already taken care of the image (but NOT the coordinates!). So my image shown here was originally reversed. I have now corrected it.

(PS - how do I know it's the right way round? - comparison with a Lunar Orbiter 4 image of the area)


Phil

Click to view attachment

Here you can see the video of the Moon made with LDEM 64.
I have used all the point from 71 to -71 of latitude.

Ciao
VB