[X] My Assistant

[peter59]

Finally, the data are here:
http://lroc.sese.asu.edu/data/LRO-L-LROC-2....0/LROLRC_0001/
Unfortunately, the server is running terribly slow.

[peter59]

Very strange images from WAC camera.

[djellison]

That's not strange - that's what they should look like. It's a pushframe camera. Unfortunately, as for MARCI, they appear to be only releasing the raw data.

[Phil Stooke]

Don't forget, though, that the THEMIS visible images were also comprised of multiple framelets like that, and a bit later the properly mosaicked versions were also available.

Phil

[remcook]

Looks like flipping each 'band' will make it look a lot nicer. Should be easy to script up for someone who has the ability (not me!).

[Phil Stooke]

Until I can do a search for specific images, this won't be very useful to me. Probably won't be long...

Phil

[djellison]

and a bit later the properly mosaicked versions were also available.

Yeah - but after 3 years of MARCI, they've not done it, and I doubt they'll do it for this either.

[Rick Sternbach]

LOLA. I want my LOLA. I've got rapid prototyping machines waiting to make moon models.

Rick

[S_Walker]

A bit off topic, but I was hoping someone can help-
I can't seem to get IMG2PNG to work on my computer- downloaded the latest version, and I was hoping to explore some of the LROC data release. However, the exe file gets this error "This application has failed to start because cftisio.dll was not found. Re-installing the application may fix this problem." I kept the cftisio.dll file in the same folder. Same result if I copy both the .exe and .dll files to the C drive... any suggestions? Running on an XP system.

[elakdawalla]

Just got this email:

The NASA Planetary Data System announces the first release of data from the Lunar Reconnaissance Orbiter (LRO) mission. This release includes raw and derived products for data acquired from the start of mapping on September 15, 2009, through December 14, 2009, along with data collected during the commissioning phase June 23 - September 14, 2009.

Data sets from the following experiments are included in this release:

· Cosmic Ray Telescope for Effects of Radiation (CRaTER)
· Diviner Lunar Radiometer Experiment (DLRE)
· Lyman-Alpha Mapping Project (LAMP)
· Lunar Exploration Neutron Detector (LEND)
· Lunar Orbiter Laser Altimeter (LOLA)
· Lunar Reconnaissance Orbiter Camera (LROC)
· Mini-Radio Frequency technology demonstration (Mini-RF)

LRO data are archived at the PDS Planetary Plasma Interactions (PPI), Geosciences, Imaging, and Navigation and Ancillary Information (NAIF) Nodes. The data may be accessed from these nodes' web sites and from the main PDS home page, http://pds.nasa.gov/ or http://pds.nasa.gov/subscription_service/SS-20100315.html.

PDS offers two services for searching the LRO archives:

The Planetary Image Atlas at the Imaging Node allows selection of LRO data by specific search criteria. The Image Atlas will be available shortly.
Please check the Imaging Node web site for information about its availability.
http://pds-imaging.jpl.nasa.gov/index_pdsimg_new.html.

The Lunar Orbital Data Explorer at the Geosciences Node allows searching and downloading of LRO data and other lunar orbital data sets (Clementine and Lunar Prospector). http://ode.rsl.wustl.edu/moon/.

To receive email announcements of future releases of LRO data, please use the PDS Subscription Service at http://pds.jpl.nasa.gov/tools/subscription_service/top.cfm.

[zeBeamer]

The LOLA data are now also available !
In addition to the RDR and GDR products, I would like to point you to some products which were made with users like you in mind!

First, the big binary GDR files (maps) were converted to GeoJPEG2000, much easier to import in software like ArcGIS. Projection information is included in the headers, so that should work transparently.
location: http://imbrium.mit.edu/DATA/LOLA_GDR/

Second, we are releasing ready-made textures for Celestia. Many of you know Celestia (shatters.net/celestia), and some of you produced normal maps from the Kaguya altimetry data. In addition to a LOLA normal map, a texture showing the topography in false-color was made.
location: http://imbrium.mit.edu/EXTRAS/CELESTIA/

Enjoy !

Erwan
for the LOLA Science Team

[Rick Sternbach]

Erwan,

Thanks for that news about the LOLA data. However, I'm a right-brained artist working on a Mac with an app like MacDEM, which was able to work with the MGS MOLA .img files *very* nicely, given the numbers of rows and columns. I suspect that I won't be able to use anything like ArcGIS. Any ideas on how I might be able to get 16-bit grayscale maps out of the files you cited? In the meantime, I'll forward the URL to my rapid prototype folks; perhaps they'll know what to do for the models. I'd really love to be able to put the grayscale maps into Terragen.

Rick

EDIT: Holy cow, I just downloaded one of the "smaller" 17MB JPEG2000 files, and it's already in 16-bit B&W. I see files in there that are 3+ GB. Yeeeoooowww. Many, many, many thanks! - Rick

[Phil Stooke]

Just a taste of the bounty to come:



Tracks of Lunokhod 2. I can tell at once that the old route map will need a total revision. This is only the browse image! To find it I downloaded CUMINDEX.CAT, a cumulative index file, comma delimited text file. In Excel I deleted all the columns I'm not interested in, sorted by longitude, and found the latitude i wanted, then found the image in the browse folder. The image number is in my file's name.

Phil

[zeBeamer]

EDIT: Holy cow, I just downloaded one of the "smaller" 17MB JPEG2000 files, and it's already in 16-bit B&W. I see files in there that are 3+ GB. Yeeeoooowww. Many, many, many thanks!

Rick,
glad the JP2s are working for you (they are all unsigned INT16). But the IMGs are there as well, just in case!

[nprev]

Whoa-ho-ho!!! Great eye, Phil!

[Phil Stooke]

I bet you say that to all the cartographers!

Phil

[Rick Sternbach]

Rick,
glad the JP2s are working for you (they are all unsigned INT16). But the IMGs are there as well, just in case!

I just kicked out a couple of Terragen pix of Copernicus; the LDEM64 in JP2000 seems to have some striping, but I've seen that in MOLA files as well and I suspect that will get cleared up in time. I'll try running the .img through MacDEM and see what happens. Exciting times; I'm already looking into an 8" to 12" physical sphere with full relief, as well as some selected regions for rapid prototyping. - Rick

[zeBeamer]

Nice rendering
Yes, orbit improvement is ongoing... Hopefully next release some of those orbital track artifacts will be gone!

[Phil Stooke]

The Lunokhod 2 tracks are also clearly visible pretty much all the way from the hills south of the landing area to the end of the route, but the landing area in the image I looked at is not very obvious.

I have looked at the area I have been promoting for Lunokhod 1. It seems I was wrong! But the true location has not appeared yet.

Phil

[Rick Sternbach]

Nice rendering
Yes, orbit improvement is ongoing... Hopefully next release some of those orbital track artifacts will be gone!

Thanks. Not meaning to hog the thread, but here's a quick view of Orientale with a generic moon-ish texture. *Much* more experimentation in the coming weeks. - Rick

[nprev]

Emily wrote up a nice blog post with Phil's discovery, along with pics of Lunas 20, 23 & 24.

[elakdawalla]

I had the most frustrating day imaginable today, shuffling five ongoing projects and an insomniac baby, completing nothing; one of the projects is a lengthy blog post attempting to explain to all you folks who are not Phil how to dive headfirst into PDS volumes -- I really really will try to finish that one tomorrow. Anyway, after finally getting the kids to bed after the long, frustrating day I sat down at my computer and I was like, "For God's sake, why did they have to release those images at 5 pm Pacific after a day like today!?" I was darned if I was going to be the last space blogger to write about the Lunas and Lunokhod, which is what would have happened if I hadn't sat down to write tonight! Phil, I hope it was OK to fold in to the blog post what I know is a preliminary browse view from something I know you are working very hard on doing in much better quality.

[volcanopele]

Second, we are releasing ready-made textures for Celestia. Many of you know Celestia (shatters.net/celestia), and some of you produced normal maps from the Kaguya altimetry data. In addition to a LOLA normal map, a texture showing the topography in false-color was made.
location: http://imbrium.mit.edu/EXTRAS/CELESTIA/

Thanks very much for doing this!

Here is a comparison between the LOLA normal map and the Kaguya map:




Already an improvement

[Stu]

Not meaning to hog the thread, but here's a quick view of Orientale with a generic moon-ish texture.

Hog away, Rick, lovely stuff!

Very Chesley Bonestellian that Orientale view...

[Explorer1]

Is there a thread somewhere about the new photos of the old Soviet landers/rovers? I don't see one, and am vary of making a new thread on them....

[djellison]

You didn't look very hard. Just two threads below this one, in the very same sub forum, a thread that explicitly mentions those missions in it's subheading.
http://www.unmannedspaceflight.com/index.php?showtopic=6192

[Rick Sternbach]

Hog away, Rick, lovely stuff!

Very Chesley Bonestellian that Orientale view...

Okay, here's a shot of the highlands. I grabbed some part of a 45 degree north file and rendered away; I'll get better at describing exact features later on. I've looked through the LOLA files over at imbrium.mit.edu, and now see how they're organized, I think.

They offer the whole moon unwrapped as a cylindrical map at 4, 16, and 64 pixels per degree, in JPEG2000, .IMG, .GRD formats. Personally, I have no idea how to use the .GRD, so I'm sticking to the JPEG2000 and .IMG files.

They have:
45 degrees north and south at (I believe) 100 meters/pixel, 200m/px, 400m/px in the same formats.
60 degrees north and south at 120m/px, 240m/px
75 degrees north and south at 30m/px, 60m/px, 120m/px
80 degrees north and south at 20m/px, 40m/px, 80m/px
85 degrees north and south at 10m/px, 20m/px, 40m/px
87.5 degrees north and south at 5m/px, 10m/px, 20m/px

5 meters per pixel must be pretty darned detailed, and the file size gets huge, like 3.4GB for the .GRD file. The 45N file that I opened seems to have the craters looking correctly circular; I'll try opening a higher latitude file to see if they correct the geometry all the way up.

I'm going to assume that with more orbits and more laser points recorded, the density of detail will just keep going up, as will the file size.

I need a new computer.

[S_Walker]

Nuts...
finally got IMG2PNG to work, and had thought this would be the calibrated NAC data... unfortunately it doesn't appear to be :-(

[volcanopele]

Most data submitted to the PDS for most missions will be uncalibrated, raw data. The best way to ingest LROC data, get them calibrated, reproject them, etc., is to use ISIS3. http://isis.astrogeology.usgs.gov/Applicat...issance_Orbiter lists the LROC specific programs in ISIS3, so it looks like the LROC folks use ISIS3 extensively like the HiRISE people do. If someone can post the links to the specific Luna mission images, I might be able to give them a try tomorrow, but I am not as familiar with ISIS3 as I am with ISIS2, which I use for Cassini ISS images (though I did use ISIS3 for MESSENGER).

[S_Walker]

Thanks Pele!

[Phil Stooke]

PDS has now implemented the Planetary Image Atlas search for LRO data, especially images. Go to the geometry tab, enter min and max lat and long (negative lat for south, longitudes measured to the east), and it will find LROC images for you. Best for browsing purposes, you can display and save a jpeg browse image.

http://pds-imaging.jpl.nasa.gov/search/sea...tml#QuickSearch

Phil

[zeBeamer]

They have:
45 degrees north and south at (I believe) 100 meters/pixel, 200m/px, 400m/px in the same formats.
60 degrees north and south at 120m/px, 240m/px
75 degrees north and south at 30m/px, 60m/px, 120m/px
80 degrees north and south at 20m/px, 40m/px, 80m/px
85 degrees north and south at 10m/px, 20m/px, 40m/px
87.5 degrees north and south at 5m/px, 10m/px, 20m/px

Correct. Polar maps are in stereographic projection (true scale at the pole, R=1737.4km).

They offer the whole moon unwrapped as a cylindrical map at 4, 16, and 64 pixels per degree, in JPEG2000, .IMG, .GRD formats. Personally, I have no idea how to use the .GRD, so I'm sticking to the JPEG2000 and .IMG files.

The GRD are netcdf-binaries, created with the GMT package (gmt.soest.hawaii.edu). They are double-precision, unlike the IMG and JP2 which are downconverted to 16bit. GMT can convert those to binary 3-column (with grd2xyz), but any netcdf-reader will do.

I'm going to assume that with more orbits and more laser points recorded, the density of detail will just keep going up, as will the file size.
I need a new computer.

With more orbits, the gaps between tracks will be reduced (density of detail), but the file sizes should not change.
If your computer can handle those, it will be fine with the future releases


Erwan

[Rick Sternbach]

Erwan,

I haven't a clue what netcdf-binaries are, so I'll stick to the .img and JP2 files. However, I have a question about the files other than the complete cylindrical maps. I downloaded one of the 45S JP2 files, and all I see is a single 7200x7200 pixel image. Is there more of 45S somewhere, or can I not see the rest of that latitude because Photoshop isn't made to do that? Or has the rest of that latitude not been released yet?

EDIT: Okay, I see what's going on; the north and south files are closer and more detailed views centered on the poles, so this isn't like the MOLA files going around in longitude for each latitude increment. This means I'm going to have to wait for 128 or 256 or higher pixels/degree for a feature like Copernicus. Hmmm.

Rick

[zeBeamer]

I haven't a clue what netcdf-binaries are, so I'll stick to the .img and JP2 files. However, I have a question about the files other than the complete cylindrical maps. I downloaded one of the 45S JP2 files, and all I see is a single 7200x7200 pixel image. Is there more of 45S somewhere, or can I not see the rest of that latitude because Photoshop isn't made to do that? Or has the rest of that latitude not been released yet?

netcdf : http://www.unidata.ucar.edu/software/netcdf/ ; libraries allow such files to be used in various programs/platforms

this is a stereographic projection, so the sphere was projected onto a plane. This particular grid you mention extends to +/- 1440km in both directions. The projection of a point at 45degS from the south pole is ~1440km away from the pole, hence the name. Such points are at the center of each side. However, when you are at a corner of the grid, at a distance of 1440*sqrt(2)~2037km, you are actually at 29.25degS. The 45deg latitude circle would be a circle that is nearly tangent to the top-center, right-center, bottom-center and left-center point.
(it's like http://www.colorado.edu/geography/gcraft/n.../mapproj_f.html, but we're putting out a square grid instead of a disc).

Erwan

[Rick Sternbach]

Erwan,

Okay, I get it now, as I attempted to convey in my edited comment. I'll still assume we have to wait for much higher-rez data on Copernicus. - Rick

[mhoward]

This is a great data release. The work that's been done to make the LOLA data accessible is much appreciated. What's even more exciting is that the data set should keep getting better. It's already better than I was expecting for this first release.

Below is a view from a possible future version of Moon Globe, after just a couple hours monkeying around.

I have one technical question for Erwan: Is the data in LDEM_64.IMG signed? From the header file LDEM_64.LBL.txt I would expect it to be a signed integer offset from 1,737,400m with a scaling factor of 0.5; however, the data appears to be unsigned integer, not signed. It makes me wonder about the noted offset and scaling factor.

Thanks!

Attached thumbnail(s)

 

[Stu]

In the news, Phil, congratulations!

http://www.canada.com/technology/Canadian+...0499/story.html

[Maquis]

Wow, excellent!
On which RAW was it sitting in?

[zeBeamer]

I have one technical question for Erwan: Is the data in LDEM_64.IMG signed? From the header file LDEM_64.LBL.txt I would expect it to be a signed integer offset from 1,737,400m with a scaling factor of 0.5; however, the data appears to be unsigned integer, not signed. It makes me wonder about the noted offset and scaling factor.

actually, thanks for finding that out (and reading the doc first ). The cylindrical IMGs had a problem. They should now be fine (signed int16), so please redownload... Alternatively, you could download the smaller JP2 and decompress it to a raw binary file. For example, with "kdu_expand" by Kakadu Software (http://www.kakadusoftware.com/index.php).

[djellison]

Just playing with the 64 ppd for now - but great stuff!!

Attached thumbnail(s)

 

[mhoward]

thanks for finding that out

Thanks for fixing it. It looks right to me now.

With that fixed, here's a direct comparison between a Moon Globe using the available LALT data, and the same view using the new LOLA data. The LOLA-based view wins. I'm really surprised that the LOLA data is this sharp this early.

Attached thumbnail(s)

 

[elakdawalla]

OK folks, I am stumped. I have downloaded a couple of LROC images but cannot manage to open and work with them. Photoshop CS3 chokes on them when I attempt to open as raw using the width and height specified in the header. IMG2PNG refuses to convert them to PNG format. NasaView can open the image but converts down to 8 bit mode as it does so, and the contrast is so low that all of the pixels are in like 7 of the DNs. I tried GIMP (I have the PDS import filter installed) but it just hangs. What else can I try on a Windows machine? Help!!

[djellison]

Emailing someone with ISIS is probably your best bet.

Alternatively, try ImageJ and importing a raw into that.

[Rick Sternbach]

I'm not terribly savvy about all of the data products that are coming, but are we going to see a full cylindrical "texture map" type of image, a la what we saw with Clementine? A giant WAC mosaic of some kind? - Rick

[JohnVV]

IMG2PNG might not work for them

i have found that not just the *.lbl BUT the .img files for the
LDEM_4.LBL
LDEM_4.IMG
LDEM_16.LBL
LDEM_16.IMG
LDEM_64.LBL
LDEM_64.IMG

all of the lbl's are F-'ed up ( this is NOT an exaggeration)

the headers state 3 different bit formats and as 16 bit
the IMG files ARE 32 bit
however ther really are 16 bit images saved as 32 bit ???
also the "SCALING_FACTOR" and "OFFSET" are off
yes this is messed up
this is the LBL for the LDEM_64.IMG
that i just made , and WORKS
this opens it as a 16 bit image

CODE

PDS_VERSION_ID            = "PDS3"
/*** FILE FORMAT ***/
FILE_RECORDS              = 11520
RECORD_TYPE               = FIXED_LENGTH
RECORD_BYTES              = 46080
^IMAGE                    = "LDEM_64.IMG"
/*** GENERAL DATA DESCRIPTION PARAMETERS ***/
PRODUCT_VERSION_ID        = "V1 revision F"                                        
DATA_SET_ID               = "LRO-L-LOLA-64-GDR-V1.0"
PRODUCT_ID                = "LDEM_64.IMG"
INSTRUMENT_HOST_NAME      = "LUNAR RECONNAISSANCE ORBITER"              
INSTRUMENT_NAME           = "LUNAR ORBITER LASER ALTIMETER"              
INSTRUMENT_ID             = "LOLA"
COORDINATE_SYSTEM_NAME    = "MEAN EARTH/POLAR AXIS OF DE421"
MISSION_PHASE_NAME        = {"COMMISSIONING","NOMINAL MISSION"}
TARGET_NAME               = MOON
START_TIME                = 2009-07-13T17:33:17.246
STOP_TIME                 = 2009-12-17T19:42:52.026                      
PRODUCT_CREATION_TIME     = 2010-03-01T00:00:00
PRODUCER_ID               = LRO_LOLA_TEAM
PRODUCER_FULL_NAME        = "DAVID E. SMITH"
PRODUCER_INSTITUTION_NAME = "GODDARD SPACE FLIGHT CENTER"
DESCRIPTION               = "This data product is a shape map (radius)
   of the Moon at a resolution of 64 pixels per degree"

OBJECT                    = IMAGE
  NAME                    = HEIGHT
  DESCRIPTION             = ""
  LINES                   = 11520
  LINE_SAMPLES            = 23040
  SAMPLE_TYPE             = LSB_UNSIGNED_INTEGER
  SAMPLE_BITS             = 16
  UNIT                    = METER
  SCALING_FACTOR          = 1.0
  OFFSET                  = 0
END_OBJECT                = IMAGE

OBJECT                    = IMAGE_MAP_PROJECTION
^DATA_SET_MAP_PROJECTION = "DSMAP.CAT"
MAP_PROJECTION_TYPE      = "SIMPLE CYLINDRICAL"
A_AXIS_RADIUS            = 1737.4 <KM>
B_AXIS_RADIUS            = 1737.4 <KM>
C_AXIS_RADIUS            = 1737.4 <KM>
FIRST_STANDARD_PARALLEL  = "N/A"
SECOND_STANDARD_PARALLEL = "N/A"
POSITIVE_LONGITUDE_DIRECTION = "EAST"
CENTER_LATITUDE          = 0.0 <DEGREE>
CENTER_LONGITUDE         = 180.0 <DEGREE>
REFERENCE_LATITUDE       = "N/A"
REFERENCE_LONGITUDE      = "N/A"
LINE_FIRST_PIXEL         = 1
LINE_LAST_PIXEL          = 11520
SAMPLE_FIRST_PIXEL       = 1
SAMPLE_LAST_PIXEL        = 23040
MAP_PROJECTION_ROTATION  = 0.0
MAP_RESOLUTION           = 64.0 <PIXEL/DEGREE>
MAP_SCALE                = 0.47375 <KM/PIXEL>
MAXIMUM_LATITUDE         = 90.0 <DEGREE>
MINIMUM_LATITUDE         = -90.0 <DEGREE>
WESTERNMOST_LONGITUDE    = 0.0 <DEGREE>
EASTERNMOST_LONGITUDE    = 360.0 <DEGREE>
LINE_PROJECTION_OFFSET   = 0.0
SAMPLE_PROJECTION_OFFSET = 0.0
COORDINATE_SYSTEM_TYPE   = "BODY-FIXED ROTATING"
COORDINATE_SYSTEM_NAME   = "MEAN EARTH/POLAR AXIS OF DE421"
END_OBJECT                = IMAGE_MAP_PROJECTION

END

however you will find that in isis the map projection is off .It is in sym cyl BUT the lat/long are way off
you will need to run maplab on it

[elakdawalla]

With such a short time between the spacecraft's arrival and the release of all these data, I'm not surprised that there are issues with metadata. There should be contact information for each data set, or, failing that, there is certainly a contact listed for the PDS Node(s) hosting each data set. If you notify them (politely) of issues, being specific about both problem and solution, I am sure you will get a response, and you'll help everyone out.

[JohnVV]

I'm not surprised ether for the LRO lola it is
http://imbrium.mit.edu/
http://imbrium.mit.edu/DATA/LOLA_GDR/
lolahelp{at}gmail{dot}com

[elakdawalla]

(Also I feel like I should point out that there is a very helpful member of the LOLA team who has been posting lots of useful info IN THIS THREAD. Scroll up.)

[Ittiz]

I've noticed some issues at the left and right edges of LDEM_64. When you rotate it 180 degrees you can see what I mean. Especially on the craters. Here is a pic of what I'm talking about:

[djellison]

Yup - I found that as well - it's missing a few degrees somehow.

[Ittiz]

Yup - I found that as well - it's missing a few degrees somehow.

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

[djellison]

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

Attached thumbnail(s)

 

[Ittiz]

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.

[zeBeamer]

all of the lbl's are F-'ed up ( this is NOT an exaggeration)

the headers state 3 different bit formats and as 16 bit
the IMG files ARE 32 bit
however ther really are 16 bit images saved as 32 bit ???
also the "SCALING_FACTOR" and "OFFSET" are off
yes this is messed 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?

however you will find that in isis the map projection is off .It is in sym cyl BUT the lat/long are way off
you will need to run maplab on it

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

[JohnVV]

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

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

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

[Jim Mosher]

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

[elakdawalla]

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?

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.

[JohnVV]

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 .

[zeBeamer]

John,

Nothing is 32bit except the GRDs.



Jim,

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

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.

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.

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?

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.

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?

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.

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?

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

[Jim Mosher]

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 node. PDS archives/mirrors it.

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

-- Jim

[JohnVV]

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 .

[Phil Stooke]

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

[zeBeamer]

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)

[Phil Stooke]

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

[Ittiz]

This is what I do with the data:

[Stu]

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

[Bjorn Jonsson]

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:

...This orientation requires that one of the NAC frames from a NAC-L and NAC-R paired observation must be transformed such that both images have the same ground orientation"

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

[JohnVV]

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

[elakdawalla]

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.

[Bjorn Jonsson]

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.

[elakdawalla]

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.

[kenny]

This is what I do with the data:

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

[ValterVB]

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

[JohnVV]

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

[ValterVB]

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

[JohnVV]

Are available high resolution dataset of the Apollo11 landing site?

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

[Zack Moratto]

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

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.

[Phil Stooke]

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

[Phil Stooke]

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

[S_Walker]

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

[Phil Stooke]

"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

[ElkGroveDan]

Awesome work, Phil.

[Bernard]

Superb Phil,
and very appreciated,.
Thanks

[Ittiz]

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

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

[Phil Stooke]

A nice high sun view of Apollo 15.

Phil

[Bill Harris]

"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

[JohnVV]

nice shot Phil
cool find
i will be having it here for a few days
[attachment=21312:Screenshot_6.jpg]

[Phil Stooke]

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

[charborob]

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.

[elakdawalla]

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

[djellison]

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

[Phil Stooke]

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

[elakdawalla]

Duh. Thanks.

[Bill Harris]

a new version of Ina in Mare Tranquillitatis

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

[ValterVB]

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

[ValterVB]

Sorry...

Ciao
VB

[Phil Stooke]

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



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

[Phil Stooke]

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

[Phil Stooke]

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

[ValterVB]

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