Voyager ISS CDROM Volume Information
This is a hypertext version of the file VOLINFO.TXT from CDROM VG_0021. Minor changes and revisions to this file have appeared from time to time. If you are using another volume, you may wish to check its own VOLINFO.TXT file for possible differences.
Index
- Title page
- 1. Introduction
- 2. Voyager Images
- 3. Voyager Image Files
- 3.1 Compressed Format
- 3.2 Browse Format
- 3.3 File Naming Conventions
- 4. Disk Directory Structure
- 5. Image Files in Compressed Format
- 5.1 First-Difference Huffman Encoding
- 5.2 Decompression Software
- 6. Compressed Image File Organization
- 6.1 Image Label Area
- 6.2 Image Histogram Object
- 6.3 Encoding Histogram Object
- 6.4 Engineering Table Object
- 6.5 Image Object
- 7. Browse Image File Organization
- 7.1 Image Label Area
- 7.2 Image Histogram Object
- 7.3 Image Object
- 8. Image Index File
- References
- Appendix A - ISO Volume and Directory Standard
- A.1 - Variable Length Records
- A.2 - Direct Access Files
- Appendix B - Syntactic Rules of Keyword Entries
- B.1 - Integer Numbers
- B.2 - Real Numbers
- B.3 - Time
- B.4 - Literal Values
- B.5 - Text Character Strings
- Appendix C - Keyword Assignments For Images
- Appendix D - Supplemental Line Engineering Data
- Appendix E - Engineering Table Object
- Appendix F - Image Index File Format
Archive of Digital Images from NASA's Voyager 1 and 2 Missions - Version 2
--------------------------------------------------------------------------
October 1, 1992
Contributions by:
Eric Eliason
Branch of Astrogeology
United States Geological Survey
Flagstaff, Arizona
Randy Davis
Laboratory for Atmospheric and Space Physics
University of Colorado
Boulder, Colorado
Mike Martin, Charlie Avis, Jason Hyon
Jet Propulsion Laboratory
Pasadena, California
Bob Mehlman
Institute of Geophysics and
Planetary Physics
University of California
Los Angeles, California
Dennis McMacken
Information Systems Division
United States Geological Survey
Flagstaff, Arizona
- Back to the index.
1. Introduction
NASA’s Voyager Project and Planetary Data System (PDS) have created an archive of planetary digital images acquired by the twin Voyager spacecraft. Compact Disk Read-Only Memory (CD-ROM) is the archival medium used for distribution to interested scientific research organizations and libraries.
Each CD-ROM volume contains approximately 2500 images stored in individual compressed files. In addition to the images, supplemental information exists on the CD-ROMs. This includes documentation providing a user with information about the organization and contents of the disk. Software source code is included to provide programmers with tools to process the image files. There are Browse images, sub-sampled versions of the full-resolution images, which allow users to rapidly view the archive collection with their interactive display. Finally, there are Image Index Files containing information about all the images stored in the archive.
This document describes the organization of the archive. It provides information on how to access files stored on a CD-ROM, and gives details on the format and contents of the image files and their supporting supplemental files.
- Back to the index.
2. Voyager Images
There are two cameras onboard each Voyager spacecraft, one with a wide field of view and the other with a narrow field of view. Both cameras return data in a digital raster-format containing 800 scan lines and 800 samples per scan line. Each picture element (pixel) in the two dimensional image array is represented as an 8-bit value, and the value–in the range 0 to 255–is proportional to the amount of light detected at that point. The cameras are equipped with color filters so images taken through complementary filters can be combined during ground processing to produce color images.
The set of images on the CD-ROMs are raw; no processing has been performed other than organizing the original telemetry into raster-formatted files and compressing the image data using a Huffman encoding algorithm. The reason for the decision to distribute raw data rather than processed versions of the images is that the capabilities to process the raw images are continuing to improve. This is due to rapid improvements, not only in the techniques themselves, but also in calibration data and geometric information concerning spacecraft position and pointing. By providing the raw images which never change rather than processed versions, the continually improving image processing capabilities can be reapplied to the raw image collection.
To make full scientific use of the image collection, it is necessary to understand the radiometric and geometric properties of the camera system (6) and perform corrections to the data. A number of image processing systems are available which provide radiometric and geometric corrections, display capabilities, and analysis tools for Voyager images (7, 8).
- Back to the index.
3. Voyager Image Files
3.1 Compressed Format
Full-resolution Voyager images are stored in a compressed format using a Huffman encoding scheme. The great advantage of Huffman encoding is the significant reduction in disk space required to store an image while maintaining full data precision. The average Voyager image is compressed by a factor of more than three. Using this technique, more than 2400 compressed images can be stored on a single CD-ROM rather than 800 in an uncompressed format.
There is a price to pay when storing data in a compressed format. It takes computer time to decompress an image to its original uncompressed form. For example, on a VAX-750 it takes about one minute of CPU time to decompress an image. The one minute time delay for decompressing an image can be frustrating when a planetary scientist wants to browse an image collection.
- Back to the index.
3.2 Browse Format
A special set of image files were created to facilitate rapid browse of the collection. These files exist in an uncompressed format and have been reduced in size by sub-sampling the 800 line and 800 sample images. A Browse image, containing 200 lines and samples, has been sub-sampled by a factor of four in the line and sample directions. The data volume of a Browse image is 1/16th of the original image size. The small size of a Browse image in an uncompressed format allows images to be rapidly retrieved from a CD-ROM and displayed on a screen.
- Back to the index.
3.3 File Naming Conventions
Each digital image file has a unique name constructed from the clock count of Voyager’s Flight Data Subsystem (FDS). The FDS count indicates the time at which an image was shuttered. The general form of an image file name is Cxxxxxxx.yyy. The character ‘C’ at the beginning of the file name designates the ‘xxxxxxx’ as a clock count. The ‘xxxxxxx’ is the seven digit FDS count associated with the image. The file name extension, designated as ‘yyy’, specifies the type of image file. Full-resolution compressed files have the file name extension IMQ. Sub-sampled Browse images have the file name extension IBG. For example, the file name C1574959.IMQ is a full-resolution compressed image acquired when the FDS clock count was 1574959.
- Back to the index.
4. Disk Directory Structure
The volume and directory structure of the CD-ROM conforms to the level-1 standard specified by the International Standards Organization (ISO). The ISO standard was used so that the disks can be accessed on a wide variety of computer systems. Information on the ISO is provided in Appendix A.
The compressed and Browse image files, supplemental files, documentation, and software source code are separated into disk directories. Four directories are common to all Voyager image CD-ROMs: the DOCUMENT directory contains the documentation file associated with the archive; the SOFTWARE directory contains software for decompressing an image file; the INDEX directory contains an Image Index File; and the LABEL directory contains labels coded in the Object Description Language that describe the format and content of engineering data included with each image.
The full-resolution compressed image files are subdivided into directories based on the image’s target. Targets generally include the primary body (planet), satellites, and rings. There is a directory associated with each target for which there are images on a disk. For example, images of Io are contained under a directory named IO. These subdirectories have names of the form CnnnnXXX, where ‘nnnn’ is the first four digits of the FDS count (unique picture identifier) of the image files contained in the subdirectory. For example, the subdirectory C1574XXX under the JUPITER directory would contain all of the Jupiter images which fall in the range C1574000.IMQ to C1574959.IMQ.
Image files related to camera calibration sequences are stored in the CALIB directory. Dark current images, acquired when an image is taken with the camera shutter closed, are found in the DARK subdirectory. The PLAQUE subdirectory includes calibration plaque images, obtained when Voyager’s calibration plaque is positioned in front of a camera’s field of view. The internal calibration lamp data, acquired when the camera shutter is closed and the internal lamps are turned on, are found in the CALLAMPS subdirectory.
Included in the OTHER directory are images of stars and other non-planetary targets.
A special directory exists to hold frames which should not be confused with raw data. Frames in this RESTORED directory have been reconstructed from processed versions of the raw data because the raw data itself is lost. The reconstruction process attempts to recreate a dynamic range very close to that of the raw data, but the pixels do not contain raw data. The compressed reconstructed images are named with the extension .IRQ, whereas the Browse versions reside with the rest of the Browse images and have the standard .IBG extension.
The sub-sampled Browse versions of the image collection are located in the BROWSE directory area. This directory maintains the same tree structure associated with the full-resolution images. The subdirectories within the BROWSE directory separate the images by their target, and certain target directories containing numerous images are further subdivided. As an example, the subdirectory C1574XXX within the JUPITER subdirectory of the BROWSE directory contains all of the Browse images of Jupiter which fall in the range C1574000.IBG to C1574959.IBG.
- Back to the index.
5. Image Files in Compressed Format
5.1 First-Difference Huffman Encoding
The full-resolution images on the CD-ROMs are stored in a compressed format. The scheme is called a first-difference, Huffman code procedure. The first- difference technique subtracts each sample value from the previous sample along a line. The process, resulting in a set of values for each line which clusters around zero, eliminates the pixel-to-pixel correlation along an image line. The Huffman coding technique then creates varying length bit strings to represent each first-difference value. The most frequently occurring values will consist of very short bit strings, and the less frequently occurring values will consist of longer bit strings. The combined compression algorithm provides a technique which is simple, has minimum overhead, and allows exact restoration. References to Huffman coding can be found in most books dealing with data compression (9).
A Huffman coding tree is individually created for each image in order to produce the most efficient compression. In order to create an individual coding tree, a first-difference histogram is created for the image. This is done on a line by line basis. The first pixel of each line is left fixed (neither differenced nor compressed). Each succeeding pixel is subtracted from the true value of the preceding pixel. The count for each possible difference is kept in an encoding histogram table and stored in the image file. There can be a total of 511 first-difference values. The least first-difference value is 0 - 255 or -255, while the largest first-difference value is 255 - 0 or 255. The first-difference values are normalized for table use to the range 1 to 511 by adding 256 to each difference.
The Huffman code tree is generated from the first-difference histogram table. The first-difference values become the leaves of a tree. At each step in the generation of the tree the currently active tree nodes are ordered by frequency and the two nodes with smallest count are combined to form a new node. The new node is added to the active list while the combining nodes are dropped. The count of the new node is the sum of the counts of the combining nodes. This is continued until there is only one resulting active node. Each branch of a branching node is assigned a value of 0 or 1. The Huffman code corresponding to a leaf node value is determined by tracing the branches of the tree from the root to the leaf node. A brief example follows.
Example Huffman Encoding Tree
-----------------------------
code freq value
---- ---- -----
00 100 0 ----! 0
195 !----------------------------------! 0
01 95 -1 ----! 1 !
380 !---(root_node)
10 90 1 ---------------------------------! 0 !
185 !-----! 1
110 40 -2 ---------------------------! 0 !
95 !-----! 1
1110 30 2 --------------------! 0 !
55 !-----! 1
11110 10 -3 --------------! 0 !
25 !-----! 1
111110 5 3 ---------! 0 !
15 !-----! 1
1111110 5 -4 ---! 0 !
10 !-----! 1
1111111 5 4 ---! 1
There are essentially two steps in the decompression of an image. First, the first-difference histogram is extracted from the image file. The histogram is given to an initialization routine which sets up the Huffman coding tree for decompression. Second, the compressed lines are read from the image file and passed, one at a time, to the decompression routine for restoration to the original line.
In the restoration of a compressed line, the decompression routine takes each bit from the input stream and determines which branch to take in a path from the root to the leaf nodes. Once a leaf node is reached, the undifferenced value of the pixel can be computed from the leaf node value and the previous pixel. The search is reset to start from the root on the next input bit and the process continues for the whole line.
- Back to the index.
5.2 Decompression Software
Computer software, available as source code, resides on each CD-ROM for decompressing a compressed image. This software can be found in the SOFTWARE directory. In order to make the software useful to a wide community of users, versions of the decompression software are provided in FORTRAN, C-language, and VAX/VMS assembler language. Some modification of these routines may be required in order to adapt the software to a particular computer and operating system environment. The SOFTWARE directory contains a file named SOFTINFO.TXT which briefly describes the contents of the directory. The subdirectories MAC, PC, VAX and UNIX contain detailed software descriptions in text files.
The decompression subroutines are designed to be tools for an application program. Typically, an application program will open an image file, read the image data from the file, call the decompression routines to restore the image, and then transfer the image to the appropriate output media or display device. Because of differences between computer hardware, operating systems, and in-house image processing systems, no attempt has been made to provide generalized software for accessing an image from the CD-ROM and restoring it to a hardware display device or an in-house image file format. Example programs are however provided in the software directories which test and demonstrate the use of the decompression software.
The software has two top-level subroutines, DECMPINIT and DECOMPRESS. They provide a common data base from which to call the processing routines. DECMPINIT builds the Huffman tree from the first-difference histogram, also called the encoding histogram, and is called only once per image. DECOMPRESS processes one compressed input line per call and returns the line completely restored. These routines are fully documented. Consult the source code files in the software directories for a full explanation of their use.
A cautionary note is in order. The first-difference histogram stored in the image files consist of 32-bit VAX integers (11). Users of other computer hardware environments may need to swap integer byte pairs.
- Back to the index.
6. Compressed Image File Organization
A compressed image file is composed of variable-length records defined according to the ISO standard. Each variable-length record starts with a record length indicator, stored as a 16-bit integer, followed by the number of bytes indicated in the record length indicator. If the length indicator is odd, then a pad byte is appended to the end of the record so that all records contain an even number of bytes. Refer to the information on variable-length records in Appendix A. Variable-length record files were chosen because of the nature of the compressed images; compressed lines, represented as individual records, will vary in length from one to another.
Compressed image files begin with a label area. Following the label area are the file objects: Image Histogram, Encoding Histogram, Engineering Table, and Image. The sections which follow provide a description of the image labels and the data objects within the file.
- Back to the index.
6.1 Image Label Area
Descriptive information on the file and objects within the file is put into the label area. The label consists of keyword statements which conform to version 1.0 of the Object Description Language (ODL) under development by the PDS project (10). There are three types of ODL statements within a label: structural statements, keyword assignment statements, and pointer statements.
Structural statements provide a shell around value assignment statements that delineate which data object the assignment statements are describing.
The structural statements are:
1) OBJECT = object_name
2) END_OBJECT
3) END
The OBJECT statement begins a description of a particular data object and the END_OBJECT statement signals the end of the object’s description. All assignment statements between an OBJECT and its corresponding END_OBJECT statement describe the particular object named in the OBJECT statement. The END statement terminates a label. It must appear as a single line that contains only the word END.
A keyword assignment statement contains the name of an attribute and the value of that attribute for the object which the assignment statement is describing. Keyword assignment statements have the following format:
name = value [/* comment */]
Values of keyword assignment statements can be numeric values, literals, and text strings. Appendix B contains the syntactic rules for keyword assignments.
Pointer statements are a special class of keyword assignment statements. These pointers are expressed in the ODL using the following notation:
^object_name = location
In a file, the location is given as an integer representing the starting record number of the object, measured from the beginning of the file. The first record in a file is considered record 1. Pointers are also useful for describing the location of individual components of a data object and for pointing to a detached label. An example of the later is shown below:
^object_STRUCTURE = 'logical_file_name'
The ‘object’ is the name of the object being described and ‘logical_file_name’ is the name of the detached label file containing the description.
In a compressed image file, each keyword assignment in the label area is stored as a single variable-length record. An example of the keyword labels which exist on a compressed image is shown below. Appendix C provides a detailed description of each keyword found in the example.
Example label found on a COMPRESSED image
-----------------------------------------
CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL
/* FILE FORMAT AND LENGTH */
RECORD_TYPE = VARIABLE_LENGTH
RECORD_BYTES = 836
FILE_RECORDS = 860
LABEL_RECORDS = 54
/* POINTERS TO STARTING RECORDS OF MAJOR OBJECTS IN FILE */
^IMAGE_HISTOGRAM = 55
^ENCODING_HISTOGRAM = 57
^ENGINEERING_TABLE = 60
^IMAGE = 61
/* IMAGE DESCRIPTION */
SPACECRAFT_NAME = VOYAGER_1
MISSION_PHASE_NAME = SATURN_ENCOUNTER
TARGET_NAME = TITAN
IMAGE_ID = '1516S1-002'
IMAGE_NUMBER = 34909.12 /*FLIGHT DATA SUBSYSTEM (FDS) */
IMAGE_TIME = 1980-11-11T19:52:34Z
EARTH_RECEIVED_TIME = 1980-11-11T21:19:46Z
INSTRUMENT_NAME = WIDE_ANGLE_CAMERA
SCAN_MODE_ID = '3:1'
SHUTTER_MODE_ID = BOTSIM
GAIN_MODE_ID = LOW
EDIT_MODE_ID = '1:1' /*FULL RESOLUTION */
FILTER_NAME = CH4_JS
FILTER_NUMBER = 0
EXPOSURE_DURATION = 15.3600
NOTE = "MULTISPECTRAL LONGITUDE COVERAGE"
/* DESCRIPTION OF THE OBJECTS CONTAINED IN FILE */
OBJECT = IMAGE_HISTOGRAM
ITEMS = 256
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT
OBJECT = ENCODING_HISTOGRAM
ITEMS = 511
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT
OBJECT = ENGINEERING_TABLE
BYTES = 242
^STRUCTURE = 'ENGTAB.LBL'
END_OBJECT
OBJECT = IMAGE
ENCODING_TYPE = HUFFMAN_FIRST_DIFFERENCE
LINES = 800
LINE_SAMPLES = 800
LINE_SUFFIX_BYTES = 36
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
SAMPLE_BIT_MASK = 2#11111111#
^LINE_SUFFIX_STRUCTURE = 'LINESUFX.LBL'
END_OBJECT
END
- Back to the index.
6.2 Image Histogram Object
The first object in a compressed image file is the histogram of the image. The Histogram Object begins at the record specified by the ^IMAGE_HISTOGRAM keyword. The histogram is made up of two variable-length records. (The number of records found in an object is determined by differencing the value of the pointer keyword from the value of the next pointer. For example, the value of ^ENDCODING_HISTOGRAM minus the value of the ^IMAGE_HISTOGRAM equals the value 2.) These two records, when concatenated together, make up 256 items in the image histogram. Each item is a 32-bit VAX integer (11). The first element of the histogram contains the frequency of occurrences for the pixel value of 0, the last element contains the frequency for the pixel value 255.
- Back to the index.
6.3 Encoding Histogram Object
The second object in a compressed image file is the Encoding Histogram used to generate the Huffman coding table. The Encoding Histogram Object begins at the record specified by the ^ENCODING_HISTOGRAM keyword. The Encoding Histogram is made up of three variable-length records (^ENCODING_HISTOGRAM - ^ENGINEERING_TABLE). These three records, when concatenated together, make up 511 items with each item a 32-bit VAX integer (11). The first element of the histogram contains the frequency of occurrences for the first-difference value of -255. The last element contains the frequency for the value 255. Software will need to read the Encoding Histogram from the Encoding Histogram Object, and then pass it to the DECMPINIT subroutine for initialization.
- Back to the index.
6.4 Engineering Table Object
The third object in a compressed image file is the Engineering Table. The table starts at the record specified by the ^ENGINEERING_TABLE keyword. The table is made up of a single variable-length record. The table contains supplemental engineering data which typically will not be used by most image processing users. Information in this object includes the FDS counts at start and end of image acquisition, system noise levels, synchronization error counts, engineering status, subcommand loads, and other engineering information. A description of the Engineering Table Object can be found in Appendix E. The file ENGTAB.LBL in the LABEL directory provides an ODL label describing the engineering table.
- Back to the index.
6.5 Image Object
The fourth object in a compressed image file contains the image data. The image starts at the record specified by the ^IMAGE keyword. The image is made up of 800 variable-length records; each record represents a single line.
For Voyager images in an uncompressed form , there are 800 lines and 800 samples per line. Each record has 36 Suffix Bytes appended to the end of each line record. Each sample is an 8-bit unsigned integer. The keywords in the label area that describe the image are the LINES, LINE_SAMPLES, LINE_SUFFIX_BYTES, SAMPLE_BITS, and SAMPLE_TYPE keywords. For more information on these keywords see Appendix C.
The compressed lines are different lengths because the decompression factor for each line is different. The image samples and the Line Suffix Bytes are both in a compressed form. The first byte of a compressed line is the actual value of the first sample in the line. The rest of the record is the Huffman coded bits of the first-difference values. In order to reconstruct an image line, the compressed line must be passed to the DECOMPRESS subroutine.
The Suffix Bytes in the line record contain line engineering data. The format, after decompression, are described in Appendix D. The file LINESUFX.LBL in the LABEL directory provides an ODL label describing the line suffix after decompression.
- Back to the index.
7. Browse Image File Organization
The format of Browse image files differs from that of the compressed image files. The primary difference is the record structure of the files. Browse images are stored as direct-access files with fixed-length records as defined by the ISO CD-ROM standard (12). Refer to the information on fixed-length record files in Appendix A. Fixed-length record files are appropriate for Browse images because the image lines, represented as individual records, are fixed in size. The length of each fixed-length record, specified by the RECORD_BYTES keyword, is 200 bytes. Fixed-length record files have the added advantage of providing direct-access to any part of the file making it unnecessary to sequentially pass though a file to reach a particular record. This is the preferred data storage technique for many image processing systems (7, 8).
Browse image files, internally similar to the organization of compressed image files, begin with a label area followed by the file objects: Image Histogram, and Image. The Encoding Histogram Object, not required because the image is not compressed, and the Engineering Table object do not exist in Browse image files. Also, there are no Line Suffix Bytes present. The sections which follow provide a description of the image labels and the data objects within the file.
- Back to the index.
7.1 Image Label Area
Browse image labels are similar to those for compressed files; they contain the same keyword syntax and keyword assignment statements. The chief difference between the Browse image labels and the compressed labels are how they are stored in the records. Unlike compressed image files, keyword assignment statements are not stored in individual records. Instead, a file record will contain several keyword statements. The label records, when concatenated together, consist of a contiguous string of characters. The keywords are then extracted from this string. The keywords are separated from one another by a carriage-return and line-feed character sequence. An example of the keyword labels existing on a Browse image is shown below. Appendix C provides a detailed description of each keyword found in the example.
Example label found on a BROWSE image
-------------------------------------
CCSD3ZF0000100000001NJPL3IF0PDS200043160 = SFDU_LABEL
/* FILE FORMAT AND LENGTH */
RECORD_TYPE = FIXED_LENGTH
RECORD_BYTES = 200
FILE_RECORDS = 216
LABEL_RECORDS = 10
/* RECORD POINTERS OF MAJOR OBJECTS */
^IMAGE_HISTOGRAM = 11
^IMAGE = 17
/* IMAGE DESCRIPTION */
SPACECRAFT_NAME = VOYAGER_2
MISSION_PHASE_NAME = SATURN_ENCOUNTER
TARGET_NAME = DARK
IMAGE_ID = '1594S1-009'
IMAGE_NUMBER = 34700.41 /*FLIGHT DATA SUBSYSTEM(FDS) */
IMAGE_TIME = 1980-11-04T20:57:22Z
EARTH_RECEIVED_TIME = UNKNOWN
INSTRUMENT_NAME = WIDE_ANGLE_CAMERA
SCAN_MODE_ID = '1:1'
SHUTTER_MODE_ID = BODARK
GAIN_MODE_ID = LOW
EDIT_MODE_ID = '1:1' /*FULL RESOLUTION */
FILTER_NAME = CH4_JS
FILTER_NUMBER = 0
EXPOSURE_DURATION = 7.6800
NOTE = "DARK CURRENT CALIBRATION"
/* DESCRIPTION OF OBJECTS IN FILE */
OBJECT = IMAGE_HISTOGRAM
ITEMS = 256
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT
OBJECT = IMAGE
LINES = 200
LINE_SAMPLES = 200
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
SAMPLE_BIT_MASK = 2#11111111#
NOTE = "SUBSAMPLED FROM 800X800 EDR IMAGE"
END_OBJECT
END
- Back to the index.
7.2 Image Histogram Object
The first object in the file, the image histogram, begins at the record specified by the ^IMAGE_HISTOGRAM keyword. The histogram is make up of six fixed-length records and is otherwise constructed identically to the compressed file Image Histogram Object. (Remember, the length of an object, in records, is determined by differencing the value of the pointer keyword from the value of the next pointer. For example, the value of ^IMAGE_HISTOGRAM minus the value of the ^IMAGE equals the value 6.)
The six records, when concatenated together, contain the 256 elements of the image histogram. (The keyword ITEMS specifies the number of items in the object.) The image histogram will occupy the first 1024 bytes of the 1200 bytes which make up the six concatenated records. The remaining 176 bytes at the end of the Image Histogram Object are to be ignored.
- Back to the index.
7.3 Image Object
The Image Object starts at the record specified by the ^IMAGE keyword. The image is made up of 200 fixed-length records where each record represents a single image line.
The keywords found in the IMAGE object describe the image area. There are 200 lines (LINES keyword), and 200 samples in a line (LINE_SAMPLES keyword). Unlike standard image files, there are no Line Suffix Bytes so the LINE_SUFFIX_BYTES keyword is not found in the label. Each sample is an 8-bit unsigned integer (SAMPLE_BITS and SAMPLE_TYPE keywords).
- Back to the index.
8. Image Index File
The Image Index File, named IMGINDEX.TAB and located in the INDEX directory, contains basic information about the image files located on the volume. Included in the image index is information on the camera state, exposure time, image target, optical filter, and other camera parameters. A description of the record fields and format is found in Appendix F. The Image Index File consists of fixed-length records of length 512 bytes in ASCII character representation. Each record contains the information for one image.
There is a label file, IMGINDEX.LBL, located in the INDEX directory. which describes the contents of the index file. The label file consists of keyword statements in the Object Description Language (ODL) developed by the PDS project (10).
- Back to the index.
References
1) SCIENCE, Vol. 233, No. 4759, (1986); This issue of SCIENCE provides a detailed account of Voyager 2’s spectacular encounter with Uranus.
2) SCIENCE, Vol. 204, No. 4392, (1979); Voyager 1’s encounter with Jupiter
3) SCIENCE, Vol. 206, No. 4421, (1979); Voyager 2’s encounter with Jupiter
4) SCIENCE, Vol. 212, No. 4491, (1979); Voyager 1’s encounter with Saturn
5) SCIENCE, Vol. 215, No. 4532, (1982); Voyager 2’s encounter with Saturn
6) M. Benesh and P. Jepsen, “Voyager Imaging Science Subsystem Calibration report”, JPL Doc. No. 618-802, Jet Propulsion Laboratory, Pasadena, Ca. 91103, (1978); This report details the Voyager camera’s radiometric, geometric, and optical/mechanical properties.
7) “Planetary Image Cartography System (PICS)”, Unpublished Manual, Branch of Astrogeology, U. S. Geological Survey, Flagstaff, Az. 86001, (1987); PICS is an integrated computerized system for the systematic reduction, display, mapping, and analysis of planetary image data.
8) S. LaVoie, C. Avis, H. Mortensen, C. Stanley, L. Wainio, “VICAR - User’s Guide”, JPL Doc. No. D-4186, Jet Propulsion Laboratory, Pasadena, Ca. 91103, (1987); The MIPL facility at JPL has developed a system for the automatic processing of Voyager spacecraft data.
9) G. Held, “Data Compression, Techniques and Applications, Hardware and Software Considerations”, John Wiley and Sons, (1983).
10) T. Z. Martin, M. D. Martin, and, M. J. Braun, “Standards for the Preparation and Interchange of Data Sets”, JPL Doc. No. D-4683, Jet Propulsion Laboratory, Pasadena, Ca., 91109, (1988)
11) VAX integers, as storage units in data files, are configured in “least significant byte first” order. This is the order for integer values used by VAX and IBM PC computer systems. Users of other computer architectures (IBM Mainframes, Macintosh, SUN, and Apollo) will need to swap the high and low byte positions for 16-bit integer data. For 32-bit integer data, swap byte pairs 1 and 4, and 2 and 3. (Example, hexadecimal value AA BB CC DD becomes DD CC BB AA.)
12) “Information processing – Volume and file structure of CD-ROM for information interchange”, ISO/DIS document number 9660, International Organization for Standardization, 1 Rue de Varembe, Case Postale 56, CH-1121 Geneva 20, Switzerland, (April 15, 1987)
- Back to the index.
Appendix A - ISO Volume and Directory Standard
The volume and directory structure of the CD-ROM conforms to the standard specified by the International Organization for Standardization (ISO) (12). The ISO standard has three levels of interchange. The CD-ROM disk conforms to the first level of interchange, level-1. This level allows file attributes and characteristics to be specified in an extended attribute record.
For computer operating systems which support the capabilities of the full level-1 ISO standard, access to the CD-ROM volume will be straightforward; all of the operating system capabilities for I/O will operate on the disk. For example, it will be possible to obtain directory listings, copy files, and utilize high level I/O functions. For computer systems which do not support the ISO standard, access to the image files will be more difficult; special operating system input/output routines will need to be developed or obtained in order to access the files.
Because the disk is produced at the level-1 ISO standard, files will be prefixed with an extended attribute record. The extended attribute record contains information about a file’s record format, record attributes, and record length. This information is utilized by computer systems which support the full level-1 structure. The extended attribute record is not considered part of the file and is not seen by programs accessing a file with high-level I/O routines.
For computer systems that do not support extended attribute records of the ISO standard, the extended attribute record is considered part of a file. The extended attribute record will be located in the first 2048 bytes of the file and should be bypassed by the I/O routines which access the data.
- Back to the index.
A.1 Variable-Length Records
Variable-length record files contain records with any number of bytes, up to a specified maximum. These records are prefixed by a count field, indicating the number of bytes in the record. The count field comprises two bytes on a CD-ROM stored in a VAX integer format (11). The value stored in the count field indicates the number of data bytes in the record.
Variable-length record files can only be accessed sequentially. This means file I/O routines start reading a file with the first record; subsequent reads provide the next sequential record in the file.
In the ISO standard, an odd valued record length can be specified but the actual record length must be even. If an odd-length record is specified, the value stored in the count field will contain the odd length. However, the record will be padded at the end of the record with a zero-filled byte to make the actual record length even.
For computer systems supporting variable-length records there will be high- level I/O routines to access the file. For systems which do not support the level-1 ISO standard or do not support variable-length records, software will need to be developed for handling these files.
- Back to the index.
A.2 Direct Access Files
Direct-access files with fixed-length records have implied records; there is no information in the file designating the start or end of a record. Rather, the first byte of a record within a file starts at a fixed offset byte position from the start of the file. Direct-access files allow any part of a file to be accessed directly without the need to sequentially pass through a file. To determine the record byte-offset position, the following calculation can be made:
off = (rec-1)*len
where: off = offset byte position of record from start of file
rec = desired record to access
len = length of record in bytes
- Back to the index.
Appendix B - Syntactic Rules of Keyword Entries
A keyword/value assignment, made up of a string of ASCII characters, contains the name of one parameter and the value of that parameter. A keyword entry has the general form shown below:
name = value [/* comment */]
The layout of each keyword entry is essentially free-form; blanks and tabs are typically ignored by a parsing routine. A keyword parameter name is separated from the keyword value by the equal symbol (=). Each keyword entry may optionally be followed by a comment that more completely describes the entry. The comment begins with a slash character followed by an asterisk character (/), and terminates with an asterisk character followed by a slash character (/). Comments may exist on a line without a keyword entry.
Values associated with a keyword represent integers, real numbers, unitized real numbers, literals, time, or character text strings.
- Back to the index.
B.1 Integer Numbers
An integer value consists of a string of decimal digits preceded optionally by a sign (+ or -). Non-decimal based integers are expressed according to the Ada language convention: b#nnnnnnn#, where ‘b’ represents the base of the number, and ‘#’ delimits the number ‘nnnnnnnn’. As an example, the number expressed as 2#111# represents the binary number 111 (7 in base 10).
- Back to the index.
B.2 Real Numbers
A real number has the form: [s]f.d[En] where
s = optional sign (+ or -)
f = one or more decimal digits that specify the integral
portion of the number.
d = one or more decimal digits that specify the fraction
portion of the number.
n = an optional exponent expressed as a power of 10.
A unitized real number is a real number with a unit of measurement associated with the number. The units are enclosed in angle brackets (< >). As an example, 1.234 indicates the measurement 1.234 seconds.
- Back to the index.
B.3 Time
A special form of a numeric field is the TIME value, the following format of date/time representation is used:
yyyy-mm-ddThh:mm:ss.fffZ
where:
yyyy = year
mm = month
dd = day of month
hh = hour
mm = minute
ss = seconds
fff = fraction of a second
Z = The Z qualifier indicates the time is expressed
as universal time corrected.
- Back to the index.
B.4 Literal Values
A literal value is typically a member of a set of finite values. It is a string constructed from letters (A-Z), decimal digits (0-9), and the underscore character (_). The first character must be a letter. Optionally, a literal value may be delimited by single-quote (‘) characters. If a literal appears within single-quotes, the literal may contain any printable ASCII character. For example, the literal value ‘1:1’ is legal as long as the single-quoted format is used. A keyword construction using a literal value might look like the example shown below:
FILTER_NAME = BLUE
In this example the statement says the BLUE filter of the camera was used to acquire an image.
- Back to the index.
B.5 Text Character Strings
Text strings can be any length and can consist of any sequence of printable ASCII characters, tabs, blanks, carriage-control, or line-feed characters enclosed in double-quote characters. The string continues until a double-quote character is encountered.
- Back to the index.
Appendix C - Keyword Assignments For Images
CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL
This keyword provides a mechanism for image files to conform to the SFDU (Standard Formatted Data Unit) convention. The first 40 bytes of each file contain the SFDU. The SFDU label associated with a PDS image file consists of a 20 byte universal SFDU identifier indicating the type of SFDU and that end- of-file delimitation is being used. The second 20 bytes identifies the JPL control authority, and that the PDS2 data definition language is used to describe the data product. The value ‘SFDU_LABEL’ is added for compatibility with keyword/value parsers.
RECORD_TYPE = FIXED_LENGTH or VARIABLE_LENGTH
This keyword defines the record structure of the file. Compressed files have VARIABLE_LENGTH records and Browse image files have FIXED_LENGTH records.
RECORD_BYTES = xxxx
Record length in bytes for fixed-length records. For variable- length records, the value is the maximum size for a variable- length record.
FILE_RECORDS = xxxx
Total number of records contained in the file.
LABEL_RECORDS = xxxx
Number of records in the label area of the image file.
^IMAGE_HISTOGRAM = xxxx
The (^) character prefixing a keyword indicates the keyword is a pointer to the starting record of a major object in the file. In this case, the keyword is the pointer to the Image Histogram Object. The keyword value indicates the starting record in the file for the Image Histogram Object. The number of records found in an object is determined by differencing the value of the pointer keyword from the value of the next pointer.
^ENCODING_HISTOGRAM = xxxx
The keyword value points to the starting record in the file for the Encoding Histogram Object.
^ENGINEERING_TABLE = xxxxx
The keyword value points to the starting record in the file for the Engineering Table Object.
^IMAGE = xxxxx
The keyword value points to the starting record in the file for the Image Object.
SPACECRAFT_NAME = VOYAGER_1 or VOYAGER_2
Spacecraft associated with the image.
MISSION_PHASE_NAME = URANUS_ENCOUNTER, JUPITER_ENCOUNTER,
SATURN_ENCOUNTER, or NEPTUNE_ENCOUNTER
Central body of the mission encounter for this image.
TARGET_NAME = xxxxxx
Observational target body name of the image.
IMAGE_ID = 'nnnnes+ddd'
Image identification, takes the form: nnnnes+ddd, where ‘nnnn’ = picture sequence number for a given day, ‘e’ = planet of encounter (J=Jupiter, S=Saturn, U=Uranus, N=Neptune), ‘s’ = Voyager spacecraft (1 or 2), - sign indicates before and a + sign indicates after closest planetary approach. ‘ddd’ = number of days from closest approach.
IMAGE_NUMBER = xxxxx.xx
Flight Data Subsystem (FDS) clock count at time of image acquisition. There is a unique IMAGE_NUMBER for each image in a planetary encounter. The clock count is always a seven digit value, five digits to the left of the decimal point and two digits to the right of the decimal point.
IMAGE_TIME = yyyy-mm-ddThh:mm:ssZ
Time at which image was acquired, the time system is Universal Time Corrected. ‘yyyy’ = year, ‘mm’ = month, ‘dd’ = day of month, ‘hh’ = hour, ‘mm’ = minute, ‘ss’ = second.
EARTH_RECEIVED_TIME = yyyy-mm-ddThh:mm:ssZ
Time at which image was received on earth.
INSTRUMENT_NAME = NARROW_ANGLE_CAMERA or WIDE_ANGLE_CAMERA
Camera used to acquire the image.
SCAN_MODE_ID = 'n:1'
Scan rate of vidicon read out, values can be ‘1:1’, ‘2:1’, ‘3:1’, ‘5:1’, and ‘10:1’. The instrument scan rate affects the radiometric properties of the camera because of the dark current buildup on the vidicon.
SHUTTER_MODE_ID = xxxxxx
The instrument shutter mode affects the radiometric properties of the camera. Permitted values are;
NAONLY - narrow angle camera shuttered only
WAONLY - wide angle camera shuttered only
BOTSIM - both cameras shuttered simultaneously
BOTALT - both cameras shuttered alternately
BSIMAN - BOTSIM mode followed by NAONLY
BODARK - shutter remained closed for entire exposure time
GAIN_MODE_ID = LOW or HIGH
Gain state of the camera.
EDIT_MODE_ID = xxxx
Edit mode of the camera, indicates amount of data read from the vidicon. ‘1:1’ indicates the full-resolution of the vidicon. Other values include ‘3:4’, ‘1:2’, ‘1:3’, ‘1:5’, and ‘1:10’
FILTER_NAME = xxxxxx
Optical filter used for the image. Permitted values are CLEAR, CH4_U, CH4_JS, UV, VIOLET, BLUE, GREEN, ORANGE, and NAD.
FILTER_NUMBER = x
Optical filter identification number, contains the unique number associated with the optical filter for the image.
EXPOSURE_DURATION = x.xxxxx
Exposure duration of image in seconds.
DATA_ANOMALY_TYPE = xxxxxxxxxx
Data recording anomalies in the image. If keyword is missing, no anomalies were detected. DATA_ANOMALY_TYPE = RAM_DATA_CORRUPTION indicates that spurious values exist in the image data due to corruption of the random access memory onboard the spacecraft.
NOTE = " "
Observational intent of the image.
OBJECT = IMAGE_HISTOGRAM
ITEMS = 256
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT
This keyword sequence identifies the Image Histogram Object. The object contains 256 elements, stored in VAX integer format (11), and has 32 bits for each element. The records associated with an object are thought of as being concatenated together when making up the object. Some objects will not completely fill the records which make up the object. For example, in the Image Histogram Object for Browse images there are six fixed-length records of 200 bytes per record. The image histogram will occupy the first 1024 bytes of the 1200 bytes which make up the six records. The remaining 176 bytes at the end of the Image Histogram Object are to be ignored.
OBJECT = ENCODING_HISTOGRAM
ITEMS = 511
ITEM_TYPE = VAX_INTEGER
ITEM_BITS = 32
END_OBJECT
This keyword sequence identifies the Encoding Histogram Object. The encoding histogram is used to construct the Huffman coding tree for decompressing an image. The Encoding Histogram Object contains 511 elements, is stored in VAX integer format (11), and has 32 bits for each element. The ENCODING_HISTOGRAM object does not exist in Browse image files.
OBJECT = ENGINEERING_TABLE
BYTES = 242
^STRUCTURE = 'ENGTAB.LBL'
END_OBJECT
This keyword sequence identifies the Engineering Table object. The Engineering Table is described in Appendix E. The ^STRUCTURE keyword points to a logical file on the CD-ROM that contains keyword descriptors for the Engineering Table. The BYTES parameter indicates the number of bytes in the Engineering Table.
OBJECT = IMAGE
ENCODING_TYPE = HUFFMAN_FIRST_DIFFERENCE
LINES = xxxx
LINE_SAMPLES = xxxx
LINE_SUFFIX_BYTES = xxxx
SAMPLE_TYPE = UNSIGNED_INTEGER
SAMPLE_BITS = 8
SAMPLE_BIT_MASK = 2#11111110#
^LINE_SUFFIX_STRUCTURE = 'LINESUFX.LBL'
END_OBJECT
This keyword sequence identifies the Image Object.
ENCODING_TYPE = xxxx
Type of image compression encoding scheme, always HUFFMAN_FIRST_DIFFERENCE for full-resolution image. This keyword is not present in Browse images.
LINES = xxxx
Number of scan lines in the image, 800 lines in a full resolution image and 200 lines in a Browse image.
LINE_SAMPLES = xxxx
Number of samples in each image line, 800 samples in a full resolution image and 200 samples in a Browse image
LINE_SUFFIX_BYTES = xxxx
Number of Suffix Bytes in each image line record. There are 36 Suffix Bytes in a full-resolution image. Line Suffix Bytes contain supplementary line engineering data, described in Appendix D. This keyword is not present in Browse images.
SAMPLE_TYPE = UNSIGNED_INTEGER
Pixels are unsigned integers.
SAMPLE_BITS = 8
Pixels are 8-bit values in the range 0 to 255.
SAMPLE_BIT_MASK = 2#11111111# or 2#11111110#
Active bits in an image sample. The number is expressed as a base 2 value in the Ada language number base convention. The keyword value consists of a string of 1’s and 0’s. The value 1 indicates a bit is active and a 0 indicates a bit is not in use. For example, SAMPLE_BIT_MASK = 2#11111110# indicates all bits active except least significant bit
^LINE_SUFFIX_STRUCTURE = 'LINESUFX.LBL'
Pointer to the file on the CD-ROM that contains keyword descriptors for the Line Suffix Bytes. This keyword is not present in Browse image files because they do not contain Line Suffix Bytes.
END
The keyword entries terminate with a line that contains only the word END. Bytes in the label area after the END line are ignored.
- Back to the index.
Appendix D - Supplemental Line Engineering Data
The table shown below describes the information contained in an image line record for full-resolution images. The supplemental line engineering data is found in byte positions 801 through 836 of the line record. Both the image data and the supplemental line engineering data are in a compressed form in the file and are decompressed for restoration. The byte positions reference the line record after decompression. All integer values are stored in VAX integer format (11).
In the table the first byte in the record is designated byte 1. The bit positions of a byte are numbered as bit 0 for the least significant bit and bit 7 as the most significant bit.
Byte Data
Position Type Data Description
---------------------------------------------------
1-800 BYTE - Image scan line samples
801-802 INTEGER*2 - FDS clock count, Mod 16 count
803-804 INTEGER*2 - FDS clock count, Mod 60 count
805-806 INTEGER*2 - FDS Mod line count
807-808 INTEGER*2 - Image line number
809-810 INTEGER*2 - Number of missing minor frames not present in
line
811-830 INTEGER*2 - An array of 10 items, one for each frame of
the image. Number of telemetry frame bits retained
for processing
831 BYTE - Bits 0-7 identify input type as follows:
0 - S/C flight 2 data Mission Operations
Subsystem
1 - S/C flight 1 data Mission Operations
Subsystem.
2 - PTM data
3 - Not used
4 - External simulation (SC41)
5 - External simulation (SC42)
6 - S/C flight 2 data test
7 - S/C flight 1 data test
832 BYTE - Input Source/Input type, bits 1-7 shown below
0 - Not used
1 - R/T data
2 - SDR tape data
3 - IDR tape data
4 - EDR (reprocessed data)
5 - Not used
6 - Not used
7 - fill data
833-834 INTEGER*2 - First valid pixel ID, element position (1-800)
of the first pixel in this line not artificially
set to zeroed.
835-836 INTEGER*2 - Element position of the last pixel in this line
not artificially set to zeroed.
- Back to the index.
Appendix E - Engineering Table Object
The table shown below describes the information contained in the Engineering Table Object. The format and fields of the Engineering Table Object are identical to the data as stored on the original EDR magnetic tape files archived at the Jet Propulsion Laboratory. All integer values are stored in VAX integer format (11).
In the table the first byte in the record is designated byte 1. The bit positions of a byte are numbered as bit 0 for the least significant bit and bit 7 as the most significant bit.
Byte
Position Item Data Description
-------- ------------------- ----------------------------------
1 Record ID Always 0
2 Unused Unused
3-4 Unused Unused
5-6 Unused Unused
7-12 Earth Received Time Time of first line record in the
file containing valid data.
Bytes 7, 8 - year (7 bits),
day of year (9 bits)
Bytes 9,10 - minute (11 bits)
Bytes 11,12 - milliseconds
13-18 Earth Received Time Time of last line record of the
file containing valid data.
(see format above)
19-24 FDS Count Count of the first line record of
the file containing valid data.
Note that this may not correspond
to the FDS Count for line record #1.
Bytes 19,20 - FDS clock count Mod 16
Bytes 21,22 - FDS clock count Mod 60
Bytes 23,24 - FDS line count
25-30 FDS Count Count of the last line record of the file
containing valid data. (see format above)
31-36 Spacecraft Event Time Four binary fields corresponding to the
(predicted) shutter-close time for this image.
(see format for Earth Received Time above)
37-68 MTIS Recording Data MTIS/IPL Data for first line record of
Recording Data file (ASCII text).
69-88 GCF Data GCF for the first line record of the
file containing valid data.
Bytes 69-70 - GCF sync code (MSB)
Byte 71 - GCF sync code (LSB)
Byte 72 - Source code
Byte 73 - Destination code
Byte 74 - Block format code
Bytes 75-76 - GDD(3-bits),UDT code
(7-bits), DDT code
(6-bits)
Bytes 77-78 - Spacecraft number
(7-bits) time (MSB)
Byte 79-80 - time (LSB)
Bytes 81-82 - Unused (2-bits), day
of year (12-bits),
block serial number
MSB (2 bits)
Byte 83 - LSB of block serial
number
Byte 84 - Millisecond clock
Byte 85 - Serial number
Byte 86 - GCF configuration
status
Bytes 87-88 - Unused (13-bits),
esc (2-bits)
Unused (1 bit).
89-108 GCF Data GCF for of the last line record of
the file containing valid data.
(see format above)
109-114 Internal Four binary fields representing
Received Time approximate time of data receipt
from the DACS:
year of century = byte 109
day of year = byte 110
minute of day = bytes 111,112
millisecs in minute = bytes 113,114
115-118 Unused Unused
119-120 Format ID Telemetry format ID for this image.
bytes 119-120 represent a word with
Bits 8-15 = unused
Bits 6-7 = format (=2 for imaging)
Bits 1-5 = image format code. Note
that the code used by the GDS may
differ from the code down-linked by
the spacecraft:
0=I3G4 12=IM2c 24=IM15
2=IMS 15=GS4 26=IM6
4=IMO 17=GS2 27=IM5
6=IMG 18=IM14 28=IM4
8=IMK 20=IM12 29=IM3
9=IM7 21=IM11 30=IM2
11=IM9 22=IM10 31=IM13
Bit 0 = S/C ID (0=VGR-2, 1=VGR-1)
121-122 System Noise The minimum noise level found for
Temperature (Min) the scan-lines
123-124 System Noise The maximum noise level found for
Temperature (Max) the scan-lines
125-126 Symbol SNR (Min) Minimum signal/noise ratio found
for the scan-lines
127-128 Symbol SNR (Max) Maximum signal/noise ratio found
for the scan-lines
129-130 AGC (Min) The minimum automatic gain control
value used for the scan-lines
131-132 AGC (Max) The maximum automatic gain control
value used for the scan-lines
133-134 Sync Code Errors Sum of the line sync. code errors
for the scan lines
135-136 FDS Count Errors The sum of the FDS count errors for
the scan lines which contain valid
data
137-138 Sync Parameters Bits 8-15 contain the sync
parameter I as described in the
MTIS SDR. Bits 0-7 contain the
sync parameter P as described in
the MTIS SDR.
139-140 Sync Parameters 3 five-bit values representing the
sync parameters J, K, and L as
described in the MTIS SDR.
J = bits 10-14 (bit 15=zero)
K = bits 5-9
L = bits 0-4
141-142 Sync Parameters 3 five-bit values representing the
sync parameters M, N, and R as
described in the MTIS SDR.
M = bits 10-14 (bit 15=zero)
N = bits 5-9
R = bits 0-4
143-144 Number of Lines Total number of line records in the
file which contain some valid data.
145-146 Number of Full Lines Number of line records in the file
which are composed entirely of full
minor frames.
147-148 Number of Partial Total number of line records in the
Lines file which contain some valid data
but are not composed entirely of
full minor frames.
149-150 Number of Unreadable Total number of records from the IDR
Records and/or SDR which were unreadable and
which fell within a time period for
which data was required for this
file. Note: For SDR input this
does not necessarily result in
data loss.
151-152 Number of Logical Total number of gaps on the IDR
Breaks and/or SDR as indicated by a
discontinuity in the logical record
numbers which fell within a time
period for which data was required
for this file.
153-154 Sort Parameters TBD catalog information. Will
include target info from PIG file.
161-162 Number of Minor Total number of minor frames in this
Frames from IDR file which were derived from IDR
input.
163-164 Number of Minor Total number of minor frames in this
Frames from WBDL file derived from WBDL input.
165-166 Number of Minor Total number of minor frames in this
Frames from SDR file which were derived from SDR
input.
167-168 Number of Missing Total number of frames which were
Minor Frames missing from this file.
169-170 Not Used
171-180 Pic. No. Ten ASCII characters of the form:
NNNNES+DD, where:
NNNN = picture number within day.
E = planet of encounter (J=Jupiter,
S=Saturn,....)
- = indicates before closest
planetary approach
+ = indicates after closest
planetary approach.
DDD = Number of days from closest
approach.
181-190 Target Body Ten ASCII characters (e.g. MIRANDA).
191-192 Input Source/Input Logical sum (result of successive
Type inclusive or operations) of word
95 of all line records in the file.
ISS Status/Engineering Subcom Data
----------------------------------
193-194 Shuttered Picture Subcom position 1:
Indicator Bit 15 = Camera ID (O=WA, 1=NA)
Bits 0-14 = shuttered picture
indicator
= all ones for a
shuttered image
= zeroes for unshuttered
images.
195-196 Slow Scan Status Subcom position 2:
Bits 15-6 = Actual picture line
number being read out.
Bits 5-0 = Actual segment number
being read out.
Note: the slow scan status is
meaningless here since it
increments with line count.
197-198 Exp. Mode/Time/ Subcom position 3:
Filter/Elec. Cal Bits 11-15 = spares
Bit 10 = NA electronics cal status
(1=on, 0=off)
Bit 9 = WA electronics cal status
(1=on, 0=off)
Bits 4-8 = 5-bit exposure code. To
convert to exp time, see MJS
77-4-2036.
Bits 0-3 = Filter wheel position.
Bits 1-3 give the position and
Bit 0 is an odd parity bit.
199-200 Picture Count Subcom position 4.
201-202 Parameter A Word Subcom position 5.
Present Value
203-204 Parameter A Word Subcom position 6.
Indicator
205-206 Parameter A Word Subcom position 7.
Pointer
207-208 Parameter B Word Subcom position 8.
Present Value
209-210 Parameter B Word Subcom position 9.
Pointer
211-212 Parameter C word Subcom position 10.
Present Value
213-214 Parameter C word Subcom position 11.
Pointer
215-216 Parameter D word Subcom position 12.
Present Value
217-218 Parameter D word Subcom position 13.
Indicator
219-220 Parameter D Word Subcom position 14.
Pointer
221-220 Ten 8-bit Analogue Subcom positions 15-19.
Samples
231-232 Pixel Average/ Subcom position 20.
Command Status Bits 14-15 = spares
Bits 13 = Pixel Average Status
Bits 8-12 = Pixel Average is based
on the MSBs of all pixels exceeding
the programmed threshold of the
camera read-out in the previous
frame.
For data compression formats (IMO,
IMQ, IMK, and IM2c) this field is
replaced by Command Status Word
SC06QT:
Bits 15-3 = unused
Bit 2 = WA LSB Truncation Flag
(0=truncation)
Bit 1 = NA LSB Truncation Flag
(0=truncation)
Bit 0 = Secondary Memory Readout
(1=readout)
233-242 ISS Engineering 9 ISS engineering measurements from
ETAP.
- Back to the index.
Appendix F - Image Index File Format
The Image Index File contains information about the image files located on the CD-ROM volumes. Included in the image index is information on the camera state, exposure time, image target, optical filter, and other camera parameters. The Image Index File consists of fixed-length records of length 512 bytes in ASCII character representation. Each record contains the information for a single image.
The table shown below describes the contents of the Image Index File, named IMGINDEX.TAB. This file is located in the INDEX directory. All fields are in ASCII character format. The Image Index File was formatted to allow automatic data entry programs to access the data for entry into an existing data base system. The non-numeric fields in the image index will be enclosed by double- quote characters. All fields are separated by blank characters. The last two bytes in a record are a carriage-control and line-feed character. The table shown below gives the starting and ending byte positions of each field in the table. These byte positions specify the actual fields and do not include the double-quote marks and commas which separate the fields.
Byte
Positions Description
------------------------------------------------------------------
2- 10 Spacecraft Name
14- 30 Mission Phase
34- 41 Observational Target Body
45- 54 Image identification (example: 1522U2-004)
57- 64 Image number (Flight Data Subsystem clock count)
67- 86 Image time (Universal Time Corrected)
90-109 Earth Received time (also Universal Time Corrected)
113-131 Instrument name (WIDE_ANGLE_CAMERA or NARROW_ANGLE_CAMERA)
135-141 Instrument scan rate (1:1, 2:1, 3:1, 5:1, 10:1)
145-151 Shutter mode of camera (NAONLY, WAONLY, BOTSIM, BOTALT,
BSIMAN, BODARK)
155-161 Gain state of camera (always LOW on this volume)
165-171 Edit mode of camera (1:1, 1:2, 1:3, 1:5, 1:10, 3:4)
175-181 Filter name (CLEAR, CH4_U, CH4_JS, UV, VIOLET, BLUE,
GREEN, ORANGE, or NAD)
184-187 Filter identification number
189-195 Exposure duration (seconds)
198-277 Observational note
281-288 Sample Bit MASK (11111111 = all bits in 8-bit byte
are active, 11111110 = all bits active except least
significant)
292-297 Data Anomalies (NONE = no data anomaly detected,
RAMCOR=RAM data corruption anomaly)
301-308 CD-ROM volume number of compressed image file
312-351 Directory location and name of compressed image file
355-362 CD-ROM volume number of Browse image file
366-412 Directory location and name of Browse image file
- Back to the index.
