Voyagers to the Outer Planets 2: Uranus

home *** CD-ROM | disk | FTP | other *** search

/ Voyagers to the Outer Planets 2: Uranus / VoyagestotheOuterPlanetsVol2.cdr / document / volinfo.txt

Wrap

Text File | 1988-09-14 | 80KB | 1,677 lines

NJPL1I00PDS100000000 = SFDU_LABEL RECORD_TYPE = STREAM SPACECRAFT_NAME = {VOYAGER_1,VOYAGER_2} MISSION_PHASE_NAME = {JUPITER_ENCOUNTER, SATURN_ENCOUNTER, URANUS_ENCOUNTER, NEPTUNE_ENCOUNTER} INSTRUMENT_NAME = {NARROW_ANGLE_CAMERA, WIDE_ANGLE_CAMERA} FILE_TITLE = "Archive of Digital Images from NASA's Voyager 1 and 2 Missions" END Archive of Digital Images from NASA's Voyager 1 and 2 Missions -------------------------------------------------------------- July 15, 1988 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 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 CONTENTS 1 - Introduction .......................................... 1 2 - Voyager Images ........................................ 1 3 - Voyager Image Files ................................... 2 3.1 - Compressed Format ..................................... 2 3.2 - Browse Format ......................................... 2 3.3 - File Naming Conventions ............................... 3 4 - Disk Directory Structure .............................. 3 5 - Image Files in Compressed Format....................... 4 5.1 - First-Difference Huffman Encoding...................... 4 5.2 - Decompression Software................................. 5 6 - Compressed Image File Organization..................... 6 6.1 - Image Label Area....................................... 6 6.2 - Image Histogram Object................................. 8 6.3 - Encoding Histogram Object.............................. 9 6.4 - Engineering Table Object............................... 9 6.5 - Image Object........................................... 9 7 - Browse Image File Organization.......................... 10 7.1 - Image Label Area........................................ 10 7.2 - Image Histogram Object.................................. 11 7.3 - Image Object............................................ 12 8 - Image Index File........................................ 12 References.................................................... 13 Appendix A - ISO Volume and Directory Standard ............. 14 A.1 - Variable Length Records ....................... 14 A.2 - Direct Access Files ........................... 15 Appendix B - Syntactic Rules of Keyword Entries ............ 16 B.1 - Integer Numbers ............................... 16 B.2 - Real Numbers .................................. 17 B.3 - Time .......................................... 17 B.4 - Literal Values ................................ 17 B.5 - Text Character Strings ........................ 17 Appendix C - Keyword Assignments For Images ................ 18 Appendix D - Supplemental Line Engineering Data ............ 22 Appendix E - Engineering Table Object ...................... 23 Appendix F - Image Index File Format ....................... 29 page 1 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 (Voyager 1 and Voyager 2). This initial collection includes all of the images acquired by Voyager 2 as it passed by the planet Uranus (1), and selected near-encounter images of Jupiter, Saturn, and their satellites (2, 3, 4, 5) taken by both spacecraft. The images acquired during Voyager 2's encounter with Neptune will be included in the collection in 1990. The remaining Jupiter and Saturn encounter images will also be available on future disks. This archive of digital images is placed on compact read-only optical disk media (CD-ROM) for distribution to interested scientific research organizations and libraries. The current Voyager archive resides on eight CD-ROM volumes. Each volume contains approximately 2500 images stored in individual files. The Uranus volumes, (volumes one through three), store the entire image collection acquired during Voyager 2's encounter with Uranus. The Saturn volumes, (volumes four and five), and the Jupiter volumes, (volumes six through eight), contain the best nearest-encounter images for the respective planets and their moons. 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. 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 page 2 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). 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. 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 subsampled 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. Browse images are located on the last volume of each set of planet volumes. Browse images for the Uranus volumes exist on volume three, Volumes five and eight contain the Saturn and Jupiter browse files respectively. page 3 3.3 - File Naming Conventions ----------------------------- Each digital image file has a unique name constructed from the clock count of Voyager's Flight Data Sub-system (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 C2674999.IMQ is a full-resolution compressed image acquired when the FDS clock count was 2674999. 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 Uranus are contained under a directory named URANUS. If there are more than about 100 images associated with a target, the images are further divided into subdirectories within the target directory. 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 C2674XXX under the U_RINGS directory would contain all of the Uranus rings images which fall in the range C2674000.IMQ to C2674999.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 this directory. Included also are 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 also found in the directory. page 4 Image files having unknown or minor targets are found in the OTHER directory. Included in this directory are images with star targets and images of minor satellites in the planetary system. The browse image collection is stored on the last CD-ROM of each planet volume set and is 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 C2674XXX within the U_RINGS directory of the BROWSE directory contains all of the browse images of the Uranus rings which fall in the range C2674000.IBG to C2674999.IBG. 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 page 5 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. 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, different versions of the decompression software exist 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 describes the contents of the directory, and how to use the software in the directory. 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 page 6 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 directory 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 directory 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. 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. 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. page 7 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 ----------------------------------------- NJPL1I00PDS100000000 = SFDU_LABEL /* FILE FORMAT AND LENGTH RECORD_TYPE = VARIABLE_LENGTH RECORD_BYTES = 836 FILE_RECORDS = 860 LABEL_RECORDS = 54 page 8 /* 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 <SECONDS> 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 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 page 9 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. 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. 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. 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. page 10 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. 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. The sections which follow provide a description of the image labels and the data objects within the file. 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. page 11 Example label found on a BROWSE image ------------------------------------- NJPL1I00PDS100043180 = 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 <SECONDS> 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 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.) page 12 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. 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). 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 planet volumes. 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) under development by the PDS project (10). page 13 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) page 14 Appendix A ---------- 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. 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. page 15 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. 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 page 16 Appendix B ---------- 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 the end of the line on which it appears. 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. 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). 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 <SECONDS> indicates the measurement 1.234 seconds. page 17 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. 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. 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. page 18 Appendix C ---------- C - Keyword Assignments For Images ----------------------------------- NJPL1I00PDS100xxxxxx = PDS_SFDU_LABEL This keyword provides a mechanism for image files to conform to the SFDU (Standard Formatted Data Unit) convention. The first 20 bytes of a file are to contain a SFDU. The SFDU label associated with a PDS image file consists of the control authority identifier (characters 1-4), the version identifier (character 5), the class identifier (character 6), a spare field (characters 7-8), a format identifier (characters 9-12), and a length field indicator (characters 13-20). The keyword conforms to standard PDS keyword syntax and the value associated with this keyword will always be SFDU_LABEL. 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. page 19 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 BSIMAN - BOTSIM mode followed by NAONLY BODARK - shutter remained closed for narrow and wide angle camera NADARK - narrow angle read out without shuttering WADARK - wide angle read out without shuttering 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' page 20 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 <SECONDS> 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. page 21 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. page 22 Appendix D ---------- 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 zeros by MIPL processing. 835-836 INTEGER*2 - Element position of the last pixel in this line not artificially set to zeros by MIPL processing. page 23 Appendix E ---------- 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 -------- ------------------- ---------------------------------- 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 IPL Physical IPL Data for first line record of Recording Data file (ASCII text). page 24 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) page 25 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. page 26 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. page 27 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 page 28 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. page 29 Appendix F ---------- 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, BSIMAN, BODARK, NADARK, or WADARK) 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-342 Directory location and name of compressed image file 346-353 CD-ROM volume number of browse image file 357-394 Directory location and name of browse image file