Jump to content
PDS Geosciences Node Community

Recommended Posts

Posted

Hi!

I'm looking to utilize and manipulate Lunar Terrain data for a project I'm working on. For some quick background, I essentially want access to as much lunar terrain data as I can get for a project that takes a Latt/Long coordinate and returns a Map of that area with the chosen terrain data laid on top of it. I understand there are already some similar tools out there, but that is just a high level description of what I want to do. There's a lot more to it that necessitates me needing to develop my own custom app for it.

With that being said, I'm still relatively new to some realms of the software world. One of those realms being parsing binary IMG files into a format that I can manipulate with code.

I've figured out what data I want. I think starting with the LRO LOLA GDRDEM is probably what I want to do. I'm starting with the Data Product LDEM_4. Starting small in order to iron out this parsing stuff. I've also figured out how to view the data utilizing NASAView. The only thing I'm pretty unsure about is how to parse the data into a form that I can manipulate and utilize on my own. FYI, I'm currently doing all of my work in C#

From what I've learned thus far, it seems as though I'm going to need to learn a lot more about serialization and binary data. And I'm completely open to being told that I'm simply to inexperienced and need to go learn more, but I wanted to check here first to see if anyone had any pointers or resources to get me started.

With all that being said, my main question is:

Are there any resources or guides available to help me figure out how to parse the IMG files associated with the LRO LOLA GDRDEM LDEM_4 Data Product into data that I can manipulate and utilize how I see fit?

Also, am I heading down the completely wrong path or does it seem as though I'm moving in the right direction for what I'm looking to do?

Looking forward to seeing any responses. Thanks!

Posted

Jee,

The IMG files are just binary arrays, nothing complicated. The label file that accompanies each image file gives the information your software needs to read the file. For instance, in LDEM.LBL in the IMAGE object, you'll see these lines:

    LINES                 = 720
    LINE_SAMPLES          = 1440
    MAXIMUM               = 21008
    MINIMUM               = -17758
    SAMPLE_TYPE           = LSB_INTEGER
    SAMPLE_BITS           = 16
    UNIT                  = METER
    SCALING_FACTOR        = 0.5
    OFFSET                = 1737400.

This tells you the image array has 720 lines with 1440 samples (pixels) in each line. (The pixels should be displayed from left to right, top to bottom.) Each pixel is a 16-bit signed least-significant-byte-first (little-endian) integer. To go from pixel value to meters, multiply the pixel value by 0.5 and add 1737400. The range of values in the array is from -17758 to 21008 meters. 

See also Frequently Asked Questions About LOLA Data.

 

 

Posted
On 6/30/2020 at 10:31 AM, Susie Slavney said:

Jee,

The IMG files are just binary arrays, nothing complicated. The label file that accompanies each image file gives the information your software needs to read the file. For instance, in LDEM.LBL in the IMAGE object, you'll see these lines:


    LINES                 = 720
    LINE_SAMPLES          = 1440
    MAXIMUM               = 21008
    MINIMUM               = -17758
    SAMPLE_TYPE           = LSB_INTEGER
    SAMPLE_BITS           = 16
    UNIT                  = METER
    SCALING_FACTOR        = 0.5
    OFFSET                = 1737400.

This tells you the image array has 720 lines with 1440 samples (pixels) in each line. (The pixels should be displayed from left to right, top to bottom.) Each pixel is a 16-bit signed least-significant-byte-first (little-endian) integer. To go from pixel value to meters, multiply the pixel value by 0.5 and add 1737400. The range of values in the array is from -17758 to 21008 meters. 

See also Frequently Asked Questions About LOLA Data.

 

 

Thanks for the quick response! So that answers some questions but now I have a couple follow-up questions:

  1. I'm assuming the pixels are grayscale and that is why it is only one value per pixel. Is that correct?
  2. Are there any coordinates associated with the values? This is mainly what I'm looking for. I would love a way to associate each value with a coordinate (x, y or latt, long).
  3. Why 16 bit? Can't the pixels be represented with 8 bit ints? This is more of a curiosity question, so no worries if you can't answer it!

Looking forward to seeing your thoughts. Thanks again!

Posted
On 7/2/2020 at 11:34 AM, Jee said:

Thanks for the quick response! So that answers some questions but now I have a couple follow-up questions:

  1. I'm assuming the pixels are grayscale and that is why it is only one value per pixel. Is that correct?
  2. Are there any coordinates associated with the values? This is mainly what I'm looking for. I would love a way to associate each value with a coordinate (x, y or latt, long).
  3. Why 16 bit? Can't the pixels be represented with 8 bit ints? This is more of a curiosity question, so no worries if you can't answer it!

Looking forward to seeing your thoughts. Thanks again!

I think I might have the answer to number 2. I can just use the values for LINES, LINE_SAMPLES and the various LATITUDE/LONGITUDE limits. With these values I can just convert between the two. Correct me if I'm wrong.

Posted

Jee,

1. Yes.

2. To assign each pixel a latitude and longitude, you will need the information in the IMAGE_MAP_PROJECTION part of the label, and also the file DSMAP.CAT in the CATALOG directory of the archive (or DSMAP_POLAR.CAT if you are working with an image in polar stereographic projection). 

DSMAP.CAT is a text file that gives the details of the simple cylindrical map projection, including the equations to go between latitude-longitude and line-sample. The IMAGE_MAP_PROJECTION keywords in the label give you the values to plug in to those equations for that particular image. 

3. The data are in 16-bit signed integers because some of the values are negative. Even after applying the scale and offset there will be negative values, representing elevation below the defined planetary radius, as explained in the note in the label. 
 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...