Jump to content


Having trouble reading the .img file

  • Please log in to reply
5 replies to this topic

#1 sestrell



  • Members
  • Pip
  • 3 posts

Posted 19 October 2016 - 10:41 AM



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, 

#2 Susie Slavney

Susie Slavney

    Geo Staff

  • Geo Staff
  • 161 posts

Posted 19 October 2016 - 01:28 PM



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-geoscienc.../checksums.html


Susie Slavney

#3 sestrell



  • Members
  • Pip
  • 3 posts

Posted 19 October 2016 - 01:55 PM



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



#4 Susie Slavney

Susie Slavney

    Geo Staff

  • Geo Staff
  • 161 posts

Posted 19 October 2016 - 02:26 PM

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.

#5 Guest_kathrynbottrell_*

  • Guests

Posted 13 March 2017 - 11:17 AM

Hello, I am facing same type of image file reading issue. This conversation is very useful for me to fix this error.

#6 sestrell



  • Members
  • Pip
  • 3 posts

Posted 13 March 2017 - 11:27 AM

Hi kathrynbottrell and future readers,


I found a solution to my problem. I downloaded NASAView from https://pds.nasa.gov...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,


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users