Jump to content
PDS Geosciences Node Community

Having trouble reading the .img file


Recommended Posts



Currently I'm working on a data analysis project using images from the Mars Opportunity Rover Pancam. I'm having trouble reading the .img files. I know the ascii detachable string contains all the information necessary. I'm trying to write a script to extract intensity of each pixel and place it into an array.

Right now I'm thinking LINES is height, LINE_SAMPLES is width and SAMPLE_BITS is bit per pixel. The checksum for this specific image is 7231232, but if I use the dimensions given in the lines, line_samples and sample_bits I get 65536 (for 64 x 64 x 16). Here is the data from the header. Am I interpreting the dimensions wrong?


OBJECT                           = IMAGE


  LINES                          = 64

  LINE_SAMPLES                   = 64

  SAMPLE_TYPE                    = MSB_INTEGER

  SAMPLE_BITS                    = 16

  BANDS                          = 1


  CHECKSUM                       = 7231232

  FIRST_LINE                     = 1

  FIRST_LINE_SAMPLE              = 1

  INVALID_CONSTANT               = 4095

  MAXIMUM                        = 2508

  MEAN                           = 1765.437500000000

  MEDIAN                         = 1767.000

  MINIMUM                        = 801

  MISSING_CONSTANT               = 0

  SAMPLE_BIT_MASK                = 2#0000111111111111#

  STANDARD_DEVIATION             = 199.9281

END_OBJECT                       = IMAGE


OBJECT                           = IMAGE_HEADER

  HEADER_TYPE                    = VICAR2


  BYTES                          = 12800

  ^DESCRIPTION                   = "VICAR2.TXT"

END_OBJECT                       = IMAGE_HEADER


Thank you, 

Link to comment
Share on other sites



You're right that LINES is the number of lines from top to bottom in the image (i.e. height), LINE_SAMPLES is the number of samples (pixels) in one line (i.e. width), and SAMPLE_BITS is the number of bits per pixel. The other important piece of information is SAMPLE_TYPE = MSB_INTEGER, which tells you each pixel is a signed integer stored in most-significant-byte-first order, which is the usual storage order on a Mac or a Unix-based system. For a Windows system, the usual storage order is LSB, least-significant-byte-first. That means when reading this image on a Windows system you will probably have to swap the two bytes in each pixel. If you display the image and it looks very strange, the first thing to try is swapping the bytes.


The checksum for the file is a digital signature unique to that file; the simplest type of checksum is the sum of the values of all the bytes in the file. It's not the number of bytes in the file. The checksum is used to make sure the file has been downloaded without corruption. See our page http://pds-geosciences.wustl.edu/dataserv/checksums.html


Susie Slavney

Link to comment
Share on other sites



Thank you so much! This is amazingly helpful. Two more questions: 


The last line of the ascii header is marked "END", correct? On the following line, there are some NUL then a long string that describes all the characteristics of the file and then some code that is unreadable (I assume the binary array.)


1. Does the image start on the unreadable code on that same line? If I skip to the next line, the image I get is incorrect.

2. When the binary array is read, does it read top left to bottom right (going across the top line of pixels first, and then the second, and so on)?



Link to comment
Share on other sites

Look near the beginning of the label for a line like ^IMAGE = some-number. That's the record number where the image starts. You also have to know how long a record is; that's in the line RECORD_BYTES = some-number. It's also possible that the offset to the start of the image is given in bytes instead of records; in that case it will look like ^IMAGE = some-number <BYTES>. So for example, if ^IMAGE = 21 and RECORD_BYTES = 128, then you skip the first 20*128=2560 bytes in the file to get to the first byte in the image. It will always start on a record boundary. It doesn't necessarily start right after the END statement in the label; there might be some padding of NUL bytes to fill out the record, or there might be some header records or history records before you get to the image.

Link to comment
Share on other sites

  • 4 months later...

Hi kathrynbottrell and future readers,


I found a solution to my problem. I downloaded NASAView from https://pds.nasa.gov/tools/nasa-view.shtml. This lets you open the pds image and then export it as a jpg, pdf or other file extension types.


Unfortunately, I was unable to code my own working binary reader for any general pds image file.


Hopefully this helps,


Link to comment
Share on other sites

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