CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL RECORD_TYPE = STREAM PRODUCT_CREATION_TIME = 2001-02-08 OBJECT = TEXT NOTE = "Introduction to the Mars Mosaicked Digital Image Model (MDIM) CD volumes." END_OBJECT = TEXT END Mars Mosaicked Digital Image Model (MDIM) Eric Eliason, Raymond Batson, Anthony Manley, Randolph Kirk Astrogeology Team United States Geological Survey 2255 North Gemini Drive Flagstaff, Arizona 86001 February 08, 2001 Version 2.0 CONTENTS 1 - INTRODUCTION 2 - VIKING MISSION 3 - VIKING ORBITER VISUAL IMAGING SUBSYSTEM 4 - CARTOGRAPHY AND DATA PRODUCTS 5 - DATA PREPARATION: PLANETARY DIGITAL MODELS 5.1 - PROJECTIONS 5.2 - PIXEL SIZES 6 - COMPILATION OF DIM'S 6.1 - LEVEL 1: RADIOMERIC CORRECTION 6.2 - LEVEL 2: GEOMETRIC CORRECTION 6.3 - LEVEL 3: PHOTOMETRIC CORRECTION 6.4 - LEVEL 4: CONTROLLED MOSAICKING 6.5 - DENSITY CONTRAST OF MDIM IMAGES 6.6 - MDIM IMAGE "ARTIFACTS" 7 - CONCEPT OF TILING SCHEME 8 - FILES, DIRECTORIES, AND DISK CONTENTS 8.1 - IMAGE FILE NAMING CONVENTION 8.2 - DIRECTORIES 9 - IMAGE FILE ORGANIZATION 9.1 - IMAGE LABEL AREA 9.2 - IMAGE HISTOGRAM OBJECT 9.3 - IMAGE OBJECT 10 - SOFTWARE 11 - IMAGE INDEX 12 - GAZETTEER 13 - ACKNOWLEDGEMENTS 14 - REFERENCES APPENDIX A - ISO VOLUME AND DIRECTORY STANDARD APPENDIX B - SYNTACTIC RULES OF KEYWORD ASSIGNMENT STATEMENTS APPENDIX C - KEYWORD ASSIGNMENTS FOR MDIM IMAGES APPENDIX D - GEOMETRIC DEFINITION OF A PIXEL APPENDIX E - SINUSODIAL EQUAL-AREA PROJECTION EQUATION 1 - INTRODUCTION These CD volumes contain a revised version of a global mosaic of Viking Orbiter images of Mars. An earlier mosaic produced from the same set of images was released on CD-ROM in 1991 as PDS volumes VO_2001 through VO_2006, Version 1. Version 2.0 of the mosaic, on the present disks, has been improved in both geodetic accuracy and photometric/cosmetic appearance. A further revision (Version 2.1) with further improvements in both areas is being created and will be released in the near future. The most significant change is geodetic: the present mosaic is based on a 1999 RAND global geodetic control network of Mars. This net is tied to the inertial- space position of the Mars Pathfinder spacecraft and incorporates elevation data from the Mars Orbiter Laser Altimeter (MOLA) for most control points. Its use thus eliminates a systematic error in longitude in the previous mosaic and reduces random positional errors that in some locations exceeded 20 km to typically less than 1 km. The details of the improved geodetic control process and of photometric/ cosmetic processing are described below in sections 4 and 6.3, respectively. To the maximum extent possible, the format of these disks has been kept the same as the earlier versions. Departures from the earlier standard are discussed in the file ERRATA.TXT located at the CD root directory. The global digital image map of Mars is a cartographic extension of an earlier set of CDROM volumes containing individual Viking Orbiter Images (PDS volumes VO_1001, VO_1002, etc.). The data in the latter are pristine, in the sense that they were processed only to the extent required to view them as images. They contain the artifacts and the radiometric, geometric, and photometric characteristics of the raw data transmitted by the spacecraft. This volume set, on the other hand, contains cartographic compilations made by processing the raw images to reduce radiometric and geometric distortions and to form geodetically controlled Mosaicked Digital Image Models (MDIMs). (Because the photometric processing used in this MDIM was oversimplified, quantitative radiometric analysis on this data is not possible.) It also contains digitized versions of an airbrushed map of Mars as well as a listing of IAU-approved feature names. The MDIM CD collection serves two purposes. First, the image collection serves as a database for interactive map browser applications, both for scientific analysis and for mission operations planning. Secondly, the CD volume set provides a dense delivery medium to build higher-derived cartographic image products such as special map series and planning charts. This set contains six volumes with the following contents: Volume 1. Vastitas Borealis Region of Mars (VO_2001): MDIMs in 373 image files covering the entire north polar region of Mars southward from the pole to a latitude of 42.5 deg. North. Polar Stereographic projection images of the north pole area from 80 to 90 degrees are located in the EXTRAS/POLAR directory on this disk Volume 2. Xanthe Terra Region of Mars (VO_2002): MDIMs in 412 image files covering the region of Mars from 47.5 deg. North latitude to 47.5 deg. South latitude, and 0 deg. longitude to 90 deg. West longitude. Volume 3. Amazonis Planitia Region of Mars (VO_2003): MDIMs in 412 image files covering the region of Mars from 47.5 deg. North latitude to 47.5 deg. South latitude, and 90 deg. West longitude to 180 deg. West longitude. Volume 4. Elysium Planitia Region of Mars (VO_2004): MDIMs in 412 image files covering the region of Mars from 47.5 deg. North latitude to 47.5 deg. South latitude, and 180 deg. West longitude to 270 deg. West longitude. Volume 5. Arabia Terra Region of Mars (VO_2005): MDIMs in 412 image files covering the region of Mars from 47.5 deg. North latitude to 47.5 deg. South latitude, and 270 deg. West longitude to 0 deg. West longitude. Volume 6. Planum Australe Region of Mars (VO_2006): MDIMs in 373 image files covering the entire South polar region of Mars northward from the pole to a latitude of 42.5 South latitude. Polar Stereographic projection images of the south pole area from 80 to 90 degrees are located in the EXTRAS/POLAR directory on this disk Version 1 of this CD set included a seventh volume containing a global digital terrain model (DTM) derived by stereogrammetric analysis of Viking Orbiter images. This DTM has been superseded by MOLA data and is not included in the revised set of CDs. Each of the six volumes contains MDIMs of the areas specified at resolutions of 1/256 deg./pixel (231m) and at 1/64 deg./pixel (943m). Volumes 1 and 6 also contain MDIM coverage of the entire planet at 1/16 deg./pixel (3.69 km). The six volumes also include a digitized airbrush map of the entire planet at 1/16 deg./pixel (3.69 km) and at 1/4 deg./pixel. The Sinusoidal Equal-Area Projection, is used as the map projection for this image collection. For a detailed description of the Sinusoidal projection and use of the cartographic keywords found in the image labels, refer to Appendix E of this document. The tiling layout of the 1/64 deg./pixel digital models is the same on all six volumes. All of the resolution compressions were done by averaging, not by subsampling. A gazetteer of IAU-approved feature names, referenced by latitude/longitude coordinates is included as a table file on each volume. 2 - VIKING MISSION The Viking Mission consisted of four spacecraft: two identical orbiters and two identical landers. During cruise from Earth to Mars the landers were attached to the orbiters. Thirteen science teams had experiments on these spacecraft. The major scientific objective of the mission was to search for life on Mars. Several experiments on the landers were designed to address this objective. In addition, some of the experiments on the orbiters and landers focused on the study of the composition and physical properties of the atmosphere, the distribution of water vapor, and global and local meteorology. Other experiments investigated the composition and physical properties of the surface and the geologic history of Mars. Data on the seismicity of Mars and its gravity field were also acquired to study the internal structure of Mars [1, 2]. One of the Orbiter experiments was the Visual Imaging Subsystem (VIS), which acquired the images that comprise the Mars MDIM. The imaging system is briefly described in the next section. The first objective of the VIS experiment was to characterize potential landing sites in support of site selection. Additional objectives were to study the photometric and colorimetric properties of the surface; to study various geological features that were discovered by Mariner 9 in order to better understand the geological history of Mars; to study the dynamics of the atmosphere; and to monitor the surface for changes. The Viking Orbiter spacecraft operated in orbit around Mars from 1976 until 1980. The overall Viking mission was divided into a number of mission phases with specific objectives. The time from orbital insertion in June 1974 until November 1976 is known as the Primary Mission. The main objective of the Orbiter instruments was to collect data in support of landing site selection. The spacecraft orbital characteristics were chosen so that the Orbiters could serve as relay stations for communications between the Landers and Earth. In addition, the Orbiter imaging systems imaged all of the terrains on Mars, collected some color and stereo images, and made observations of Phobos and Deimos. The Viking Extended Mission took place from November 1976 through May 1978, and the Viking Continuation Mission took place from May 1978 through February 1979. During these periods the Orbiters were not always required as relay stations with the Landers. Some of the image sequences acquired by the VIS experiment include systematic medium and high resolution coverage of large portions of the surface, stereo images, observations of Phobos and Deimos, color images of the equatorial regions, observations of the polar regions, and monitoring dust storm activity. The final phase of the Viking Mission was the Survey Mission from July 1979 until July 1980. During the Survey Mission only Viking Orbiter 1 operated since Viking Orbiter 2 had lost its attitude control gas through a series of leaks. The Orbiter 1 image coverage during the Survey Mission was designed to obtain contiguous high resolution coverage of the Martian cratered terrain. One reason for acquiring these data was to help select landing sites on Mars for future missions. 3 - VIKING ORBITER VISUAL IMAGING SUBSYSTEM Each Viking Orbiter was equipped with two identical vidicon cameras, called the Visual Imaging Subsystem (VIS) [3, 4, 5]. Each VIS camera consisted of a telescope, a slow scan vidicon, a filter wheel, and associated electronics. The angular field of view of the camera as defined by the reseau pattern was 1.51 by 1.69 degrees. The ground area covered by an image varies as a function of spacecraft altitude and emission angle. A digital image was generated by scanning the vidicon face plate. The signal at each location (pixel) was digitized as a 7-bit number (i.e., within the range of 0 to 127). The EDR image data were converted to 8-bit numbers by multiplying the original 7-bit numbers by 2. Thus, the least significant bit of each pixel in an EDR image is zero, except for interpolated pixels or pixels with corrupted values. A full resolution, Viking Orbiter image consists of an array of 1056 lines with 1204 samples per line. There are only 1182 valid samples in each line. The extra 22 samples in each line consist of dark bands on the left and right edges of each image, produced by an opaque mask located at the front of the vidicon. Each dark band is approximately 11 samples wide, although the exact width varies from image to image. Each VIS camera contained a filter wheel with five color filters (blue, minus blue, violet, green, and red) and a clear position, i.e., no filter. The filter half power bandwidths are approximately: blue from 0.35 to 0.53 micrometers; minus-blue from 0.48 to 0.70 micrometers; violet from 0.35 to 0.47 micrometers; clear from 0.35 to 0.70 micrometers; green from 0.50 to 0.60 micrometers; and red from 0.55 to 0.70 micrometers. Multiple images of the same areas were occasionally acquired using violet, green, and red filters to form color images after processing on Earth. Color image reconstruction from Viking imaging requires radiometric and geometric corrections, and co-registration of the images that make up the color set. 4 - CARTOGRAPHY AND DATA PRODUCTS The global MDIM of Viking Orbiter images of Mars was compiled according to the plan described by Batson [6, 7, 8, 9, 10]. The images have had improved radiometric and geometric enhancements over the images used both in the earlier version of the digital mosaic and in the 1:2,000,000- scale controlled photomosaic map series published by USGS. As previously noted, the most significant improvement of the present product over the earlier MDIM is its geodetic control. We therefore discuss the control solutions for the old and new mosaics in some detail. The previous MDIM was tied to a refined topographic control net for Mars [11] with a published standard error of this net of about 5 km, which represents 20 pixels at 1/256 deg./pixel in the MDIM. An ad-hoc adjustment process [10] was used to distribute errors in the mosaic so that discrepancies between neighboring images were much less than 20 pixels in most but not all places. This process could not, of course, improve the absolute positional accuracy of the mosaic. When the first MDIM was used in planning for the Mars Observer mission, it was found to disagree with a later control network [12] both in containing regional errors of the expected 5-km magnitude and in a systematic longitude difference of several tenths of a degree over the whole planet. Later comparison of the MDIM with data from the Mars Global Surveyor (MGS) mission confirmed these observations. A reanalysis [13] of the earlier control net [11] showed that, with improved supporting data (new spacecraft positions and timing data, use of supplementary elevation constraints from a reanalysis of occultation data [14], and elimination of apparently blundered image measurements) the random error was substantially reduced. Furthermore, at least part of the longitude error was attributed to the misidentification of the Viking 1 landing site in Viking Orbiter images. A revised location for the Viking 1 site was subsequently found [15] that is consistent with the control net [13] tied to the Mars Pathfinder landing site (which has been identified with great certainty [15]). The presence of substantial positional errors, both random and systematic, in the original MDIM made revision and correction of the mosaic highly desirable. In order to do so, it was necessary to decide which of the two independent, recent control networks to tie the new mosaic to: the revised control net [13] of the 1-km/pixel oblique images used in the control net [11] for the earlier mosaic, or the evolving net ([12] and subsequent revisions) based on higher- resolution but less oblique images. The latter was chosen for two reasons. First, with the increasing availability of accurate elevation data from the MGS Mars Orbiter Laser Altimeter (MOLA), image resolution seemed to outweigh stereo convergence as a determinant of network accuracy. Second, a substantial fraction of the MDIM images were already incorporated in the chosen control network [16]. The USGS supplied the complete set of image measurements linking the frames of the MDIM to coworkers at RAND, where they were incorporated in subsequent adjustments of the control network. The mosaic on these disks was based on a geodetic control solution obtained in November, 1999, that was similar but not identical to the one described in [17]. The elevations of approximately 2/3 of the points in the network were constrained with interpolated MOLA data. The rotation parameter W0 was adjusted to the value 176.7215 to insure that the prime meridian passes through the crater Airy-0 [18]. Camera pointing angles for construction of the mosaic were based on a secondary control calculation in which the latitude-longitude coordinates of all points were held at the results of the primary calculation just described and their radial coordinates were set to the local radius of the reference ellipsoid used in the calculation of the map projection. With all ground coordinates constrained, the camera pointing angles were updated to be consistent with them, as far as possible. The Viking images were then reprojected onto the ellipsoidal reference surface (rather than orthorectified based on a detailed topographic model) before mosaicking. Use of the camera angles from the secondary control calculation insured that the mosaic of non-rectified images had minimal discontinuities at image boundaries and was faithful (in a least-squares sense) to the latitude-longitude positions of the primary control calculation. This method of using a secondary least-squares control adjustment on the reference ellipsoid constitutes a significant advance over the process used to control the original MDIM. The adjustment involved in making the earlier mosaic was not a true simultaneous least- squares adjustment and the images were tied to an unrectified mosaic of the oblique images in the control network [11], resulting in substantial distortions near features of significant relief. Nevertheless, the use of a secondary adjustment to optimize the positioning of non-rectified images represents an approximation that will be eliminated in a planned future version of the mosaic. In essence, the secondary adjustment of the pointing of each image constitutes an image-by-image rectification of the mosaic. In the future, each image will be orthorectified based on a detailed topographic model rather than projected onto the ellipsoid; the camera angles from the primary control calculation will be used. A detailed investigation of the positional accuracy of the mosaic on these disks is still being carried out. The following, preliminary observations are relevant to the subject. First, whereas the original MDIM was described as having mismatches between adjacent images usually but not always less than 5 km (20 pixels) mismatches in the present mosaic are typically less than one pixel. Exceptions occur predominantly where the image boundaries cross high-relief features; for example, adjacent images may match well at the rim of Valles Marineris but the same images may show misregistration nearby on the canyon floor. This is an inevitable consequence of the lack of orthorectification of the images. Second, comparison of the mosaic with a high-resolution digital elevation model (based on MOLA data) of the region near zero latitude and longitude indicates that features in the two datasets align to on the order of one pixel, apart from a constant longitude difference of ~10 pixels (~2 km). (This discrepancy is a residual after differences in the W0 values used to prepare the two datasets are accounted for.) Finally, although additional MDIM-MOLA comparisons are needed to determine whether this 10-pixel disagreement is global or regional, a comparison of ground coordinates in the present mosaic with coordinates of the same features in a control solution calculated a year later with 100% of the ground-point elevations constrained by MOLA is suggestive. This comparison indicates that constraining the elevations of the remaining ground points resulted in a hemispheric- scale pattern of motion of the horizontal coordinates. The typical displacements are 1 to at most 3 km and the shift near zero latitude and longitude is ~2 km. Thus, it seems likely that the absolute positional accuracy of the present mosaic (measured against the standard provided by MOLA) is of the order of a few kilometers and that much of the remaining error is either hemispheric in scale or associated with unrectified topographic distortion within each image. Production of a further- revised mosaic with all elevations of 100% of the control points constrained by MOLA and with orthorectification of the images should greatly reduce these errors. Our plan is to improve the positional accuracy of the next revision of the mosaic even further by using the MOLA dataset as a source of horizontal as well as vertical control. This will be done by tying small, well defined features seen in high- resolution gridded elevation data to their counterparts in the Viking images and including these ties in the adjustment process used to calculate the control net. Detailed photometric corrections were also performed in order to normalize the contrast of topographic features based on solar illumination geometry. This processing greatly reduces tonal discrepancies between individual images even when illumination differences are extreme; residual variations were removed by a least- squares adjustment of the brightness and contrast of the images based on the statistics of their overlap regions. Because it is not possible in principle to simultaneously normalize both topographic and albedo contrast for the effects of varying illumination, the processing includes spatial filtration that results in the loss of regional albedo information. 5 - DATA PREPARATION: PLANETARY DIGITAL MODELS Digital mosaics have in the past been compiled primarily as elegant demonstrations of a costly alternative to manual compilations. They have generally been special products designed to serve specialized purposes and until recently were not affordable as primary standard products. The intent of the digital planetary mapping program is to develop a unified system, consisting of a single digital format for all planetary cartographic databases. The relations between digital map-storage formats and map projection and image resolution are therefore fundamental considerations in the design of the system. 5.1 - PROJECTIONS The simplest form of a digital model (DM) is one in which each image element's value is stored in a "bin" (pixel) labeled in terms of latitude and longitude. For computer work, it is only necessary that each bin be readily accessible. In compiling and describing DM's, however, it is useful to discuss a digital array in terms of map projections. The simplest projection is one in which each image line, or row of bins, is a parallel of latitude and each column of samples, or bins, is a meridian. This presentation was termed a "Simple Cylindrical" or "Square" projection by Clark [19]. Its simplicity is appealing, even though the higher latitudes are oversampled (e.g., the pole of a planet, in reality, is a point, but is represented digitally by an image line with as many samples as that for the equator, all with the same value). Several planetary consortia, consisting of geological, geochemical, and geophysical databases in this format, have used this format for several years for the Moon, Mars, Venus, and the Galilean satellites [20, 21, 22, 23]. The total storage required for this kind of array is only about 60% more than if each element represented the same size area on the planet, and is therefore not prohibitive. However, this projection does present an operational problem, in that a Simple Cylindrical projection of a single spacecraft image containing the north or south pole has too many pixels in an image line to manage easily during DM compilation. As a result, the Sinusoidal Equal-Area projection [24] was selected for compiling planetary DM's. The conversions between Simple Cylindrical and Sinusoidal Equal-Area geometry are so computationally trivial that the two formats are nearly twins. A Sinusoidal Equal-Area projection is one in which each parallel of latitude is an image line, and the length of each line is compressed by the cosine of its latitude. For a detailed description of the Sinusoidal projection and use of the cartographic keywords found in the image labels, refer to Appendix E of this document. The Sinusoidal projection has the simplicity of the Simple Cylindrical projection so far as indexing (rows and columns are still parallels along meridians), but compilation is much more efficient in the Sinusoidal Equal-Area because the projection does not have mathematical peculiarities at the poles. However, viewing distortion becomes severe with distance from the central meridian in the sinusoidal presentation. This is a problem only for visual examination of DIM images; it is not relevant to the integrity of the database. By simply sliding image lines parallel to one another, the central meridian can be rapidly shifted; this allows an undistorted view of a selected region without geometrically resampling the image. Segments of a DIM can therefore be displayed with a local central meridian, although the poles themselves must be transformed to a polar projection. 5.2 - PIXEL SIZES The resolution of digital images is often given in terms of pixel dimensions in meters or kilometers on the surface of a target. However, Mars DM's on this CDROM are encoded so that the number of lines (which are also parallels of latitude) in a global DM is an integer. It is therefore more convenient to specify DM resolution in terms of planetocentric degrees than in linear units. The size of pixels in DM's is therefore specified as some negative power of two (1/4, 1/8, 1/16 . . . 1/256, etc.) degrees per pixel. Resolutions intermediate to these values are not used, so that databases can be registered in scale simply by successively doubling or halving the pixel sizes by subsampling or averaging, but without resampling. Selected segments of DIMs may be written as photographic prints or published as maps in the traditional format. Table 1 shows metric equivalents of pixel sizes for each solar system body currently included in NASA's mapping plans [25, 26]. Table 1 shows equivalents of digital model resolutions, in kilometers per pixel. Mean radii are given for non-spherical bodies. TABLE 1. - METRIC EQUIVALENTS OF PIXEL SIZES FOR SOLAR SYSTEM BODIES ------------------------------------------------------------------ | |Radius| Digital scale (deg/pixel) | |Planet | (km) | 1/16| 1/32| 1/64| 1/128| 1/256| 1/512|1/1024| |_________|______|______|______|______|______|______|______|______| | | | | | | | | | | |Mercury | 2439| 2.660| 1.330| .665| .333| | | | | | | | | | | | | | |Venus | 6052| 6.602| 3.301| 1.650| .825| .413| .206| .103| | | | | | | | | | | |Moon | 1738| 1.896| .948| .474| .237| .118| .059| | | | | | | | | | | | |Mars |3393.4| 3.692| 1.846| .923| .462| .231| .115| .058| |Phobos | 11| .012| | | | | | | |Deimos | 6| .007| | | | | | | | | | | | | | | | | |Io | 1821| 1.986| .993| .497| .248| .124| .062| | |Europa | 1565| 1.707| .854| .427| .213| .107| .053| | |Ganymede | 2634| 2.873| 1.437| .718| .359| .180| .090| | |Callisto | 2403| 2.621| 1.311| .655| .328| .164| .082| | | | | | | | | | | | |Mimas | 199| .217| | | | | | | |Enceladus| 249| .272| | | | | | | |Tethys | 523| .571| | | | | | | |Dione | 560| .611| | | | | | | |Rhea | 764| .833| .417| | | | | | |Iapetus | 718| .783| | | | | | | | | | | | | | | | | |Miranda | 236| .257| | | | | | | |Ariel | 579| .632| | | | | | | |Umbriel | 585| .638| | | | | | | |Titania | 789| .861| | | | | | | |Oberon | 761| .830| | | | | | | | | | | | | | | | | |Triton | 1353| 1.476| .738| .369| .184| .092| | | |_________|______|______|______|______|______|______|______|______| 6 - COMPILATION OF DIM'S The Mars Digital image models on this CDROM are compiled and archived in four stages or "levels", beginning with raw images. All of the corrections made during these stages have some level of uncertainty, so the processing sequence is designed to progress from corrections with the highest probability of accuracy to the lowest, and intermediate stages are preserved for future analytical use. Image processing software exists to perform the various stages of image correction and enhancement [27, 28]. 6.1 - LEVEL 1: RADIOMETRIC CORRECTION Level 1 processing includes removal of electronic shading, which is inherent in the imaging system, and artifacts such as minute dust specks on the vidicon tube, microphonic noise introduced by operation of other instruments on the spacecraft during imaging sequences, and data drop-outs and spikes [23]. Reseau marks are also located and removed during this stage; their precise locations are recorded for use during later geometric processing. A digital image label is created, containing the reseau-mark locations, geodetic control point and image tie-point locations, and a computed camera orientation matrix that will project the frame to a best-fit shape and position in a mosaic. Level 1 images have better resolution than those produced at any subsequent processing level. This is because they have not been resampled for geometric correction and projection; some loss of information is inevitable in any resampling, because the density values of multiple pixels and/or fractional pixels must be averaged to form new pixels in the output array. Photographic copies of Level 1 images, with spatial filter enhancement, are therefore the more useful photographic materials for visual interpretation. 6.2 - LEVEL 2: GEOMETRIC CORRECTION Level 2 processing includes removal of camera distortions and transformation from image to map coordinates in DM format according to parameters derived at the end of the Level 1 processing phase [29]. The resolution of each frame is preserved to some extent by oversampling in the output array; that is, by selecting a resolution step that results in an image with more lines and samples than the original image. Distortion corrections are based on preflight calibration of the reseau. Image transformation is based on camera orientation matrices derived by photogrammetric triangulation [30] modified as required for a best fit with adjacent images. As described above in Section 4, the photogrammetric adjustment calculation for the present version of the global mosaic incorporated the vast majority (by intention, all) of the images used in the mosaic along with pass-point measurements in the overlap between all adjacent images. Ad-hoc adjustment of the positioning of the images was therefore not needed to produce a seamless mosaic. Only a small number of additional images that were added to the mosaic to fill gaps had their orientation matrices estimated separately from the main control calculation. 6.3 - LEVEL 3: PHOTOMETRIC CORRECTION At level 3 processing apparent inconsistencies in surface brightness caused by variation in illumination geometry and by atmospheric effects are treated. Atmospheric scattering is a significant consideration on Mars. Different materials on any planet have different light-reflecting properties, and the brightness of the surface is also modulated by the local orientation of the surface (i.e., topography) in relation to the position of the sun. These conditions are sufficiently complex that, in current practice, photometric correction of the images is necessarily approximate. For example, the effects of topographic shading can be disentangled from even the simplest variation of intrinsic properties (i.e., variation in overall reflectance or albedo) only by the use of a digital topographic model of the surface comparable in resolution to the image. Absent such a detailed topographic model, the best we can hope to do is to normalize the effective contrast of topographic features, which varies with the actual illumination, to reference conditions of fixed incidence angle. This approach involves a brightness and contrast (additive and multiplicative) adjustment of every image pixel, from which it is clear that differences in the direction of illumination, as between morning and afternoon images, are not addressed. Furthermore, since the fractional contrast due to a given topographic slope increases with incidence angle whereas the fractional contrast due to a given albedo variation remains the same, it is clear that we cannot normalize topographic shading and albedo variations to reference conditions simultaneously. The general approach to photometric normalization of the present mosaic is the same as was adopted for the earlier version of the MDIM: use of a photometric model to equalize the contrast of topographic shading to reference conditions, combined with spatial filtration to suppress the variations in albedo that are not correctly scaled in this process. The difference is in the details. In creating the earlier MDIM, images were first subjected to an additive highpass boxcar filter [31] that acted to remove both the light scattered from atmosphere to camera without reaching the surface (approximately constant across the frame) and broad spatial variations of albedo (a multiplicative effect but treated as additive). Each frame was then given a multiplicative contrast adjustment based on a zeroth-order model of atmospheric scattering combined with a Lambertian model of surface scattering. The photometric processing of the present mosaic [32] is both more complex in execution and based on more accurate assumptions. Atmospheric scattering in a slab atmosphere is modeled to second order in optical depth, according to the theory developed by Chandrasekhar [33]. The theory, derived for a Lambertian surface, is modified by appropriate correction terms for the influence of realistic, non-Lambertian surface reflectivity on the contrast of topographic features. The combined surface-atmosphere model is then used to determine the appropriate additive and multiplicative adjustments for each pixel, to be used in the following, four-step correction process: 1) The image is normalized to zero incidence angle and zero optical depth (i.e., the atmosphere is removed). Topographic shading is temporarily ignored so that this scaling normalizes albedo variations. 2) Images of the polar caps are subjected to a nonlinear brightness "stretch" chosen to reduce the brightness of the cap frosts to slightly greater than that of the brightest non-frost materials. The average brightness difference between soil and frost is in any case lost in the third step. The effect of this nonlinear stretch is to reduce the amount of "ringing" caused by the subsequent divide filter at the edges of the cap. 3) The albedo-normalized image is subjected to a highpass divide filter. This differs from the more common additive highpass filter [31] in that the results of a lowpass boxcar filter are divided into, rather than subtracted from, the image value. The result is to remove the multiplicative effects of broadly varying albedo variations. In contrast to the 251x251-pixel (~60x60 km) highpass filter used in processing the earlier mosaic, a 51x51-pixel divide filter was adopted. 4) A second photometric scaling is performed which undoes the first and then normalizes the image to constant topographic contrast under standard conditions of 30 degrees incidence and a "typical" optical depth of 0.5. The surface scattering model used is that of Hapke [34, 35]. Hapke parameters for the martian surface are based on an analysis of Mars Pathfinder images [36] The strong anisotropy of atmospheric scattering [37] is approximated as well as possible by the one-term, Legendre polynomial for the atmospheric single-scattering phase function permitted in the analytic theory [33]. In practice, this approximation is poor and leads to errors in the separation of surface and atmospheric scattering that cause high-phase and high- incidence-angle images to be over bright after normalization. In the present mosaic, the shortcomings of the photometric normalization were overcome by a final, empirical adjustment of brightness and contrast as described below. It is possible to modify the slab- atmosphere scattering model to account in an approximate way for an arbitrary single-scattering phase function, much as Hapke [34] modified the corresponding theory for a planetary surface. This modification to the theory has been added to the photometric software and will be utilized in processing of future mosaics. The most important parameter of the photometric model is the atmospheric optical depth. A constant value of 0.5 was used in the simple model applied to the older MDIM, but the photometric correction described here is extremely sensitive to the spatial and temporal variations of the optical depth. The intensities of (apparent) shadows were therefore measured throughout the mosaic, along with the intensity from a level surface patch near each shadow. The photometric model was used to estimate optical depth and surface albedo from each shadow/flat measurement pair, and the lowest optical depth from any image in a given orbit (rev) of the Viking spacecraft was used in correcting all images from that rev. The choice of the lowest optical depth result for each rev is based on the assumption that measurements in areas that are not truly in shadow will have higher intensities and hence yield model optical depths that exceed the true value. Finally, images were grouped according to revolution number and mosaicked. Statistical information collected from each of these revolutions mosaics was subsequently used in adjusting brightness levels between mosaics via a multiplicative and additive correction. 6.4 - LEVEL 4: CONTROLLED MOSAICKING Compilation of an accurate digital mosaic (MDIM) of the entire surface of a planet is the final stage in the construction of a DIM. The MDIM is a digital image of the planet, with uniform resolution throughout. The resolution of level 2 images used in the compilation is compressed or expanded to match that of the MDIM. 6.5 - DENSITY CONTRAST OF MDIM IMAGES In contrast to the earlier released mosaic, processing of this version of the MDIM was carried out on 32-bit, floating-point data up until the final step of formatting the mosaic as 8-bit data for distribution. The result was to avoid the losses of image detail that were caused by the limited dynamic range of the integer data formats used in processing the earlier version of the mosaic. Some loss of detail in the final conversion to 8-bit data was inevitable, however. MDIM's data number (DN) dynamic range is designed so that every image file will match in contrast with any of its neighboring files. This allows image files to be mosaicked together without having obvious contrast boundaries in the mosaic. The highest contrast on Mars is in areas of high relief and the image density histograms of these areas fill the full dynamic range 0 to 255. There are image files that cover low-contrast areas on the planet and the density histograms of these images will fill only a limited part of the full 0 to 255 range. When viewing low-contrast images on a display device, the image will look very bland unless a contrast stretch is applied to the image values. For convenience of image display applications, the MDIM files have an object containing the image histogram in order to facilitate the rapid display of an image with optimum contrast. An image display application could extract the image histogram from the file, use it to determine an optimum contrast stretch, and then load the display's DN look-up table to perform the contrast stretch. 6.6 - MDIM IMAGE "ARTIFACTS" "Perfect" cartographic products do not exist--all compilations are compromises at some level and the MDIM digital cartographic products are no exception. Various artifacts exist in the MDIM products which require some explanation. The original Viking EDR images were mapped to the Sinusoidal projection using bilinear interpolation of data values from the 4 pixels closest to the location where the output grid point falls in the input image. This process produces superior results to the nearest-neighbor interpolation scheme used in the production of the first version of the MDIM but it is not perfect. A comparison of resampling interpolation schemes are described in Bernstein [38]. An error in the design of the software used to map-project the images led to random errors in the alignment of each image-errors that would be present even if the process of geodetic control discussed in Sections 4 and 6.2 were perfect. In essence, each Viking EDR was map-projected to an output coordinate system with the correct scale and center longitude, but with a grid aligned to the northernmost and westernmost pixels in that reprojected EDR. When, in the mosaicking process, these map-projected images were assembled, they were transferred to a single global grid. This was done by nearest- neighbor interpolation. The result is that each individual EDR is misplaced in the global mosaic by an amount that varies randomly and uniformly between -0.5 and 0.5 pixel in both the line and sample directions. Random mismatches between -1 and 1 pixel occur at the junction of neighboring images. This class of artifact will be eliminated from future versions of the mosaic by forcing the individual images to be reprojected to a grid whose origin is aligned globally rather than to the bounding pixels of the given image. The minimum longitude limit of an image (keyword MINIMUM_LONGITUDE) does not always end on an even longitude boundary. This was intentional. When the original MDIM data products were produced the ISO/CDROM volume directory structure contained Extended Attribute Records (XAR) in order to support the VAX/VMS environment. Because the VAX/VMS environment required even length records, a minimum longitude limit was selected so that the image sample size would always have an even number of pixels. Although the use of XARs is not employed with the new MDIM version, the same longitude limits are used as the original MDIM in order to maintain consistency with the original products. Artifacts in the image data exist due to poorly interpolated reseau and improperly removed random noise and vidicon camera blemishes. 7 - CONCEPT OF THE TILING SCHEME Most MDIMs are far too large to be managed conveniently as single files. They must therefore be segmented by some scheme analogous to the segmentation of a map series into quadrangles. Mars has been segmented into 1964 quadrangles for high-resolution mapping at a scale of 1:500,000; this scheme has been selected for tiling the MDIM because it results in tiles of reasonably convenient size, and because it allows easy cross reference between the MDIM and published paper maps. The tiles have dimensions of 5 deg. latitude by 5 deg. longitude at the equator. The longitude dimension is modified to account for the convergence of meridians on a globe, beginning at 47.5 deg. latitude, so that each tile in the MDIM retains roughly the same area. Just as published maps are indexed by the latitude/longitude of their center points (truncated to the nearest integer degree to simplify the indexing), the labels of the files in the MDIM refer to the latitude/longitude of the center of the tile. Thus, the tile (MDIM file) labeled MI05N312 is centered on a point 5 deg. north of the equator and at a latitude of 312 deg. W. Each tile has its own central meridian in order to minimize the geometric distortion (shearing) of the data within the tile. Thus, each tile, with the exception of the tiles that make up the poles, can be independently displayed and its view will be quite reasonable with virtually no geometric distortion due to the nature of the projection. Thus, craters remain round rather than being oblong. With each tile having its own central meridian, simple display software can display a tile (or sub-area of a tile) with virtually no geometric distortion in the area of interest. One of the nice advantages of the Sinusoidal Equal-Area projection is the simple process for changing the central meridian of the projection. The central meridian is changed simply by sliding image lines parallel to one another (assuming nearest-neighbor interpolation). For a computer algorithm to convert an MDIM tile to a new central meridian, the algorithm need only calculate a starting offset (where to put the first sample of the input line) and simply move the pixels from the input buffer to the output buffer starting at the calculated offset. For example, if a feature of interest existed on a boundary between two tiles, it would be relatively simple to develop a program that would read the two tiles into memory, create an output memory array with a new central meridian equal to the boundary longitude between the two tiles, and then copy the input tile lines to the output tile lines with a calculated offset value for each line. 8 - FILES, DIRECTORIES, AND DISK CONTENTS 8.1 - IMAGE FILE NAMING CONVENTION Each image file has a unique name that is constructed according to the type of image file, resolution, and its central latitude and longitude. Because only eight characters are available as a file name, a highly compressed notation is used. The general form of an image file name is 'vwxxyzzz.IMG'. In this construct the 'v' field represents the type of image data in the file and it has three possible values: 'M' represents a MDIM image, 'T' represents a DTM image (included in the original CD-ROM series on volume 7 but not included in the present 6 CDs), and 'S' represents a shaded relief airbrush image. The 'w' field represents the resolution of the image file. In this field an alphabetic character is used to represent the scale: 'A' = 1/1 degrees/pixel, 'B' = 1/2, 'C' = 1/4, 'D' = 1/8, 'E'= 1/16, etc. For this volume set only the characters 'C' (1/4 degree/pixel), 'E' (1/16 degree/pixel), 'G' (1/64 degree/pixel), and 'I' (1/256 degree/pixel) are used. The 'xx' field is constructed from the central latitude of the image file. The central latitude is rounded down to the nearest whole integer of latitude. The 'y' field contains the value of 'N' for north latitude files, and 'S' for south latitude files. Finally, the 'zzz' field is constructed from the central longitude of the image file. The central longitude is rounded down to the nearest whole integer of longitude. The '.IMG' extension name is a PDS standard indicating the file is an image file. MI00N090.IMG is an example file name. It is an MDIM image, has a resolution of 1/256 degree/pixel, a center latitude at the equator, and a center longitude at 90 degrees. Table 2 summarizes the file naming convention for image files. TABLE 2. - IMAGE FILE NAME CONVENTION ------------------------------------- General Form of Image File Names - vwxxyzzz.IMG where: v = Type of image file M - Mars Digital Image Map S - Shaded Relief Airbrush Map w = Resolution code for image file C - 1/4 degrees/pixel E - 1/16 degrees/pixel G - 1/64 degrees/pixel I - 1/256 degrees/pixel xx = Central latitude value rounded down to nearest whole latitude y = North or South latitude N - North latitude S - South latitude zzz = Central longitude value rounded down to nearest whole longitude ------------------------------------------- 8.2 - DIRECTORIES The volume and directory structure of this CD-ROM conforms to the level-1 standard specified by the International Standards Organization (ISO). This standard is also known as the ISO-9660 standard. The ISO standard was used so that the disks can be accessed on a wide variety of computer systems. Information on the ISO-9660 CD-ROM standard is provided in Appendix A of this document. The Image files are subdivided into directories based on the type of image file (MDIM, shaded relief airbrush), the resolution of the image file, and for 1/256 and 1/64 degree/pixel image files the center latitude of the image. For 1/4 and 1/16 degree/pixel images the first two characters of a file name followed by six 'X' characters make up the directory name. For example, all of the 1/16 degree/pixel MDIM images are located in the directory MEXXXXXX (Volumes 1 and 6 only). For 1/256 and 1/64 degree/pixel images the first five characters of a file name followed by three 'X' characters make up the directory name. For example, all of the 1/256 degree/pixel images with center latitude 45 degrees north are located in the directory MI45NXXX. The MDIM images, Shaded relief airbrush images, supplemental files, documentation, and software are located in separate directories. Table 3 shows the contents of the 9 directories common to all six volumes: 1) the root directory is the primary directory on the disk; 2) the DOCUMENT directory contains documentation files; 3) the EXTRAS directory contains files that are not standard PDS products, including detached ISIS labels in the subdirectories of its ISIS subdirectory, and Polar Stereographic projection images from 80 to 90 degrees latitude in its POLAR subdirectory; 4) the GAZETTER directory contains the gazetteer table and supplemental files; 5) the INDEX directory contains the image index table; 6) the LABEL directory contains ancillary PDS label files; 7) the SCXXXXXX directory contains the 1/4 degree resolution shaded relief airbrush image; 8) the SEXXXXXX directory contains the shaded relief airbrush map at 1/16 degree resolution; and 9) the MEXXXXXX directory contains the 1/16 degree resolution MDIM images. Note that the subdirectories of the EXTRAS/ISIS directory have the same names as the directories in the root directory that contain MDIM data, and contain detached ISIS labels for the images in those corresponding directories. ISIS programs can be run by copying the detached label file and corresponding PDS image file to the SAME directory on hard disk and specifying the detached label as the value of the FROM parameter. The interpretation of paths to detached data in releases of ISIS after January 2001 is sufficiently flexible that ISIS programs can be run directly on the detached label file on CD when specified in the FROM parameter. Current and previous versions of ISIS do not have this capability. The EXTRAS/POLAR subdirectory with Polar Stereographic files is present only on Volumes 1 and 6. In the earlier version of this data product, the POLAR directory was located in the root directory. TABLE 3. - DIRECTORY CONTENTS OF COMMON DIRECTORIES --------------------------------------------------- root directory AAREADME.TXT - Introduction to this CDROM volume VOLDESC.SFD - Volume descriptor label ERRATA.TXT - Anomalies and discrepancies described DOCUMENT directory VOLINFO.TXT - Documentation for the MDIM volumes EXTRAS directory POLAR subdirectory - files in polar projection (volumes 1, 6) ISIS subdirectory M* subdirectories corresponding to directories in root *.LAB - detached ISIS labels for image files GAZETTER directory GAZETTER.TXT - Gazetteer documentation GAZETTER.LBL - PDS labels for the Gazetteer table GAZETTER.TAB - Gazetteer table for Mars GAZINFO.TXT - Information on Gazetter table WPMACRO.TXT - How do use the Word Perfect Macros *.WPM - Word Perfect macros for conversion of diacritical marks to Word Perfect format INDEX directory IMGINDEX.LBL - PDS labels for the image index table IMGINDEX.TAB - Image index table INDXINFO.TXT - Information on index table LABEL directory DSMAPDIM.LBL - Ancillary label for the data set map projection object. SCXXXXXX directory SC00N000.IMG - Shaded Relief Airbrush image file at 1/4 degrees per pixel containing 1440 samples and 720 lines. SEXXXXXX directory *.IMG - Shaded Relief Airbrush image files at 1/16 MEXXXXXX directory *.IMG - MDIM image files at 1/16 degrees per pixel 9 - IMAGE FILE ORGANIZATION The record structure of the MDIM and Shaded Relief Airbrush image files is a fixed-length format (see Appendix A for a description of fixed-length record files). There are three areas that make up the image file: the image label, the image histogram object, and the image object. 9.1 - IMAGE LABEL AREA The label area of an image file contains descriptive information about the image. The label consists of keyword statements that conform to version 2 of the Object Description Language (ODL) developed by NASA's PDS project [39, 40]. There are three types of ODL statements within a label: structural statements, keyword assignment statements, and pointer statements. Structural statements provide a shell around keyword assignment statements to 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 the description of a particular data object and the END_OBJECT statement signals the end of the object's description. All keyword 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. A keyword assignment statement contains the name of an attribute and the value of that attribute. Keyword assignment statements are described in more detail in Appendix B of this document. These statements have the following format: name = value Values of keyword assignment statements can be numeric values, literals, and text strings. Pointer statements are a special class of keyword assignment statements. These pointers are expressed in the ODL using the following notation: ^object_name = location If the object is in the same file as the label, the location of the object is given as an integer representing the starting record number of the object, measured from the beginning of the file. The first label record in a file is record 1. Pointers are useful for describing the location of individual components of a data object. Pointer statements are also used for pointing to data or label information stored in separate files. An example of a detached label (i.e., label information stored in a separate file) is shown below: By convention, detached labels are found in the LABEL directory. ^STRUCTURE = 'logical_file_name' The value of 'logical_file_name' is the name of the detached label file containing the description. The keyword statements in the label are packed into the fixed-length records that make up the keyword label area. Each keyword statement is terminated by a carriage-return and line-feed character sequence. An example of a MDIM image label is shown in table 5. Descriptions of the keywords used in the MDIM label are found in Appendix C. TABLE 5. - EXAMPLE OF MDIM IMAGE LABEL -------------------------------------- CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL /* FILE FORMAT AND LENGTH */ RECORD_TYPE = FIXED_LENGTH RECORD_BYTES = 1184 FILE_RECORDS = 1283 LABEL_RECORDS = 2 /* POINTERS TO START RECORDS OF OBJECTS IN FILE */ ^IMAGE_HISTOGRAM = 3 ^IMAGE = 4 /* IMAGE DESCRIPTION */ DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V2.0" SPACECRAFT_NAME = {VIKING_ORBITER_1, VIKING_ORBITER_2} TARGET_NAME = MARS IMAGE_ID = MI65N005 SOURCE_IMAGE_ID = {"793A03", "823A12", "669B17", "672B32", "672B55", "672B57", "672B58", "672B60", "672B61", "672B62", "672B83"} INSTRUMENT_NAME = {VISUAL_IMAGING_SUBSYSTEM_CAMERA_A, VISUAL_IMAGING_SUBSYSTEM_CAMERA_B} NOTE = "MARS DIGITAL IMAGE MAP, 1/256 DEG./PIXEL, CENTER LAT,LON 65.00, 5.000 " /* DESCRIPTION OF OBJECTS CONTAINED IN FILE */ OBJECT = IMAGE_HISTOGRAM ITEMS = 256 ITEM_TYPE = VAX_INTEGER ITEM_BITS = 32 END_OBJECT = IMAGE_HISTOGRAM OBJECT = IMAGE LINES = 1280 LINE_SAMPLES = 1184 SAMPLE_TYPE = UNSIGNED_INTEGER SAMPLE_BITS = 8 SAMPLE_BIT_MASK = 2#11111111# CHECKSUM = 123456789 END_OBJECT = IMAGE OBJECT = IMAGE_MAP_PROJECTION_CATALOG ^DATA_SET_MAP_PROJECTION_CATALOG = "DSMAPDIM.LBL" MAP_PROJECTION_TYPE = SINUSOIDAL MAP_RESOLUTION = 256 MAP_SCALE = 0.2315290 MAXIMUM_LATITUDE = 67.50000 MINIMUM_LATITUDE = 62.50000 MAXIMUM_LONGITUDE = 10.00000 MINIMUM_LONGITUDE = 359.9837300 X_AXIS_PROJECTION_OFFSET = 17280.000 Y_AXIS_PROJECTION_OFFSET = 591.0382080 A_AXIS_RADIUS = 3396.0000000 B_AXIS_RADIUS = 3396.0000000 C_AXIS_RADIUS = 3376.8000488 FIRST_STANDARD_PARALLEL = "N/A" SECOND_STANDARD_PARALLEL = "N/A" POSITIVE_LONGITUDE_DIRECTION = WEST CENTER_LATITUDE = 0.00000 CENTER_LONGITUDE = 5.00000 REFERENCE_LATITUDE = "N/A" REFERENCE_LONGITUDE = "N/A" X_AXIS_FIRST_PIXEL = 1 Y_AXIS_FIRST_PIXEL = 1 X_AXIS_LAST_PIXEL = 1280 Y_AXIS_LAST_PIXEL = 1184 MAP_PROJECTION_ROTATION = "N/A" END_OBJECT = IMAGE_MAP_PROJECTION_CATALOG END 9.2 - IMAGE HISTOGRAM OBJECT The first object after the label in an MDIM image file is the histogram of the image. The Image Histogram Object begins at the record specified by the ^IMAGE_HISTOGRAM pointer keyword. (Note, the first record in the file is defined as record 6.) The number of fixed-length records that make up the image histogram object can be determined by subtracting the value of the ^IMAGE pointer keyword from the ^IMAGE_HISTOGRAM pointer keyword value. These records, when concatenated together, contain the 256 elements of the image histogram with each element occupying four bytes. Each element is a 32-bit VAX integer [41]. The first element of the histogram contains the count of pixels in the image with the brightness value 0. The last element contains the count of pixels in the image with brightness value 255. 9.3 - IMAGE OBJECT The second object in the MDIM image file contains the image data. The image starts at the record specified by the ^IMAGE keyword. The number of records that make up the image is specified by the LINES keyword value. Each image line is stored in a separate fixed-length record. Each sample is an 8-bit unsigned integer as described by the SAMPLE_BITS and the SAMPLE_TYPE keywords in the label. 10 - SOFTWARE Software for Apple Macintosh, IBM/PC (DOS), SUN Sparcstation, and VAX/VMS environments, included on Version 1 of these disks, is omitted from the present version. Users are directed to the PDS web pages at http://pds.jpl.nasa.gov/pds-cn-homepage.html where they may find the software inventory pages where NASAView display software can be obtained. 11 - IMAGE INDEX Each CDROM in the MDIM volume set contains an image index file (IMGINDEX.TAB) with catalog information about all MDIM image files in the collection. The image index file and its associated PDS label file (IMGINDEX.LAB) are located in the INDEX directory. The catalog information in the index table includes the file names, CDROM volumes containing the MDIM image files, and mapping parameter information. The image index file has fixed-length records of length 512 bytes in ASCII character representation. Each record (row in the table) contains the information for a single MDIM image file. Table 6 describes the contents of the image index file located in the INDEX directory. All fields are in ASCII character format. The image index files are formatted to allow automatic data entry programs to access the data for entry into an existing data base system. The non-numeric fields are enclosed by double-quote characters. All fields are delimited by commas. The last two bytes in a record are carriage-control and line-feed characters. Table 6 gives the starting and ending byte positions of each field in the image index. These byte positions specify the actual fields and do not include the double-quote marks and commas that separate the fields. TABLE 6 - FORMAT OF IMAGE INDEX FILE ------------------------------------ Byte Positions Description -------------------------------------------------------------------- 2 - 23 FILE_NAME: the fully qualified CD file name for the image file. The format of the directory name specification is the VAX/VMS directory format, with brackets indicating the directory hierarchy. Users on other systems will need to convert the directory names to the operating system formats. 26 - 35 MAXIMUM_LATITUDE: the Maximum latitude in the image file. Latitude ranges from +90.0 degrees for the north pole to -90.0 degrees for the south pole. 37 - 46 MINIMUM_LATITUDE: the minimum latitude in the image file. 48 - 58 MAXIMUM_LONGITUDE: the maximum longitude in the image file. Longitude ranges from 0.0 to 360.0 degrees. 60 - 70 MINIMUM_LONGITUDE: the minimum longitude in the image file. 72 - 82 CENTER_LONGITUDE: the center longitude of the Sinusoidal Equal-Area projection. 84 - 88 LINES: the number of lines in the image file. This parameter specifies the number of elements of the slowest varying dimension of the two dimensional image array. 90 - 94 LINE_SAMPLES: the number of samples in the image file. This parameter specifies the number of elements of the fastest varying dimension of the two dimensional image array. 96 - 99 MAP_RESOLUTION: the map resolution of the image file expressed as number of pixels per degree at the equator. 102 - 108 VOLUME_ID 1: list of CDROM volume ID's on which the 112 - 118 VOLUME_ID 2: image file is stored (VO_2001, VO_2002, 122 - 128 VOLUME_ID 3: etc.). There are seven fields in this 132 - 138 VOLUME_ID 4: list. Some image files at 1/256 and 1/64 142 - 148 VOLUME_ID 5: degrees per pixel exist on more than one 152 - 158 VOLUME_ID 6: volume. The 1/4 and 1/16 degree per pixel 162 - 168 VOLUME_ID 7: MDIM image files exist on all seven volumes. 171 - 181 X_AXIS_PROJECTION_OFFSET: the line position of line 1.0 and sample 1.0 in the x,y coordinates relative to the origin of the map projection. 183 - 193 Y_AXIS_PROJECTION_OFFSET: the sample position of line 1.0, sample 1.0 in the x,y coordinates relative to the origin of the map projection. 196 - 271 NOTE: contains a brief description of the image file. The field indicates the number of degrees/pixel of the file and specifies the center latitude and longitude coordinate of the image file. 275 - 282 IMAGE_ID: this field contains a six-character string to identify the image file. The field matches the name of the input file. 285 - 295 MAP_SCALE: this field gives the number of kilometers per pixel at the equator. 298 - 303 SOURCE_IMAGE_ID 1: List of up to 20 source images. This 307 - 312 SOURCE_IMAGE_ID 2: list contains the image identifiers 316 - 321 SOURCE_IMAGE_ID 3: of Viking Orbiter images that 325 - 330 SOURCE_IMAGE_ID 4: were used to create the MDIM image 334 - 339 SOURCE_IMAGE_ID 5: file. Blank fields indicate no 343 - 348 SOURCE_IMAGE_ID 6: SOURCE_IMAGE_ID. There are never 352 - 357 SOURCE_IMAGE_ID 7: more than 20 images that make up 361 - 366 SOURCE_IMAGE_ID 8: an MDIM image file. 370 - 375 SOURCE_IMAGE_ID 9: 379 - 384 SOURCE_IMAGE_ID 10: 388 - 393 SOURCE_IMAGE_ID 11: 397 - 402 SOURCE_IMAGE_ID 12: 406 - 411 SOURCE_IMAGE_ID 13: 415 - 420 SOURCE_IMAGE_ID 14: 424 - 429 SOURCE_IMAGE_ID 15: 433 - 438 SOURCE_IMAGE_ID 16: 442 - 447 SOURCE_IMAGE_ID 17: 451 - 456 SOURCE_IMAGE_ID 18: 460 - 465 SOURCE_IMAGE_ID 19: 469 - 474 SOURCE_IMAGE_ID 20: Note that the SOURCE_IMAGE_ID fields have not been updated from the first version of the mosaic. The contents of these fields are correct but not entirely complete, because a small number of additional Viking images were added to this mosaic to fill gaps. A list of these additional images may be found in the file ERRATA.TXT found at the root level directory. 12 - GAZETTEER Planetary nomenclature, like terrestrial nomenclature, is used to uniquely identify a feature on the surface of a planet or satellite so that the feature can be easily located, described, or discussed. The gazetteer on the MDIM CD volume set contains detailed information about all named features on Mars that the International Astronomical Union (IAU) has named and approved from its founding in 1919 through its triennial meeting in 1991. The gazetteer dataset will be updated to reflect both names approved since 1991 and positional changes as a result of refined geodetic control in a future version of this product. The gazetteer is located on each CD volume of the seven volume set. The information pertinent to the gazetteer is located in the GAZETTER directory (a letter 'E' has been intentionally dropped from the spelling of gazetteer because of the eight character limit on file names on IBM/PC systems). In this directory, a detailed documentation of the gazetteer can be found in the GAZETTER.TXT file. The file GAZETTER.TAB is the gazetteer table. Each row in the table contains the description of a single Martian feature. Finally, the GAZETTER.LBL file is the PDS detached label that describes the file contents and format. Ancillary files exist in the GAZETTER directory for users of the Word Perfect text editor. The diacritical marks located in the gazetteer can be converted to the Work Perfect format with the macros included in this directory. Files which end in the extension *.WPM contain the Word Perfect Macros. The document file WPMACRO.TXT describes the use of these macros. 13 - ACKNOWLEDGEMENTS The National Aeronautics and Space Administration is charged with the responsibility for coordination of a program of systematic exploration of the planets by U.S. spacecraft. To this end, it finances spaceflight missions and data analysis and research programs administered and performed by numerous institutions. The Geological Survey of the U.S. Department of the Interior is the agency that performs most of the mapping in support of NASA's program of planetary exploration and scientific research. The digital Mars maps contained in these volumes were compiled by the U.S. Geological Survey (USGS) under funding provided by NASA through its Mars Data Analysis Program at NASA headquarters, Washington, DC, and through the Mars Exploration Directorate administered by the Jet Propulsion Laboratory, Pasadena, California. NASA's Planetary Data System provided the guidance and standards for the design of the disks. Compilation of the Mars digital models was performed at USGS under the direction of R.L. Kirk and L.A. Soderblom, Principal Investigator and Co-Investigator, respectively. E.M Lee provided the technical management and supervision of a team of technicians consisting of B. Sucharski, A. Grecu, J. Richie, L. Weller, A. Gitlin, and S. Castro that compiled the MDIM. Software support was provided by K.T. Thompson and D. Cook for photometric/cosmetic processing of the images, and by L. Weller and K. Becker for formatting of the data for distribution. Geodetic control for the mosaics was computed by M.E. Davies and T. Colvin at RAND, based on image measurement data supplied by the USGS. The original CD-ROM series released in 1991 was designed by E.M. Eliason and A. Manley at the USGS, and M. Martin and J. Hyon at the Jet Propulsion Laboratory. The design of the current series was based on the earlier design, with minor modifications. E.M. Eliason and C. Isbell provided information and assistance regarding PDS archive and standards issues. Creation and duplication of the CDs were carried out by L. Weller and C. Isbell of USGS, respectively. 14 - REFERENCES 1. Snyder, C. W., 1977. The Missions of the Viking Orbiters, J. Geophys. Res., 82, p. 3971-3983. 2. Snyder, C. W., 1979. The Extended Mission of Viking, J. Geophys. Res., 84, p. 7917-7933. 3. Benesh, M., and T. Thorpe, 1976. Viking Orbiter 1975 visual imaging subsystem calibration report, JPL Document 611-125, Jet Propulsion Laboratory, Pasadena, Ca. 4. Klaasen, K. P., T. E. Thorpe, and L. A. Morabito, 1977. Inflight performance of the Viking visual imaging subsystem, Applied Optics, 16, p. 3158-3170. 5. Wellman, J. B., F. P. Landauer, D. D. Norris, and T. E. Thorpe, The Viking Orbiter visual imaging subsystem, J. Spacecr. Rockets, 13, p. 660-666, 1976. 6. Batson, R.M., 1987, Digital cartography of the planets: new methods, its status, and its future: Photogrammetric Engineering and Remote Sensing, vol. 53, no. 9, p. 1211-1218. 7. Batson, R.M., 1990, Cartography, in Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New York, Cambridge University Press, p. 60-95. 8. Batson, R.M., 1990, Appendix I: Map formats and projections used in planetary cartography, in Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New York, Cambridge University Press, p. 261-276. 9. Batson, R.M., 1990, Appendix III: Digital planetary cartography, in Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New York, Cambridge University Press, p. 289-287. 10. Batson, R. M., and E. M. Eliason, 1991, Digital Maps of Mars, Photogrammetric Engineering and Remote Sensing, vol.61, p. 1499-1507. 11. Wu, S.S.C., and Schafer, F.J., 1984, Mars control network: American Society of Photogrammetry, in Technical papers of the 50th annual meeting of the American Society of Photogrammetry, vol. 2, Washington, D.C., March 11 - 16, 1984, p. 456-463. 12. Davies, M. E., Batson, R. M., and S. S. C. Wu., 1992, Geodesy and Cartography, in Mars, University of Arizona Press, p. 321-342. 13. Zeitler, W., and Oberst, J., 1999, The Mars Pathfinder landing site and the Viking control point network, J. Geophys. Res., vol. 104 (E4), 8935-8942 14. Smith, D. E., and Zuber, M. T., 1996, The shape of Mars and the topographic signature of the hemispheric dichotomy, Science, vol. 271, p. 184-188. 15. Parker, T. J., and Kirk, R. L., 1999, Location and Geologic Setting for the 3 US Mars Landers, 5th International Conference on Mars, Abstract #6124, LPI Contribution No. 972, Lunar and Planetary Institute, Houston (CD-ROM). 16. Kirk, R., Becker, K., Cook, D., Hare, T., Howington-Kraus, E., Isbell, C., Lee, E., Rosanova, T., Soderblom, L., Sucharski, T., Thompson, K., Davies, M., Colvin, T., and Parker, T., 1999, Mars DIM: The next Generation, Lunar Planet. Sci., XXX, Abstract #1849, LPI Contribution No. 964, Lunar and Planetary Institute, Houston (CD-ROM). 17. Davies M. E., Colvin, T. R., Kirk, R., Lee, E., Sucharski, R., and Duxbury, T., 1999, The RAND-USGS control network of Mars and the martian prime meridian, Eos Trns AGU (Supplement), vol. 80, p. F615. 18. Davies, M. E., 1990, Geodetic control, in Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New York, Cambridge University Press, p. 141-168. 19. Clark, David, 1923. Plane and geodetic surveying for engineers, vol. 2, higher surveying [5th Ed., 1963, Revised by Clendinning, James]. Constable & Co. Ltd., London, p. 599-600. 20. Johnson, T.V., L.A. Soderblom, J.A. Mosher, G.E. Danielson, A.F. Cook, and P. Kupferman, 1983. Global multispectral mosaics of the icy Galilean satellites. Journal of Geophysical Research, vol. 88, no. B-7, p. 5789-5805. 21. Kieffer, H.H., P.A. Davis, and L.A. Soderblom, 1981. Mars' global properties: Maps and applications. Proceedings of Lunar and Planetary Science Conference XII, Houston, Texas, March 16-20, 1981, p. 1395-1417. 22. Pettengill, Gordon H., Donald B. Campbell, and Harold Masursky, 1980. The surface of Venus. Scientific American, vol. 243, no. 2, p. 54-65. 23. Soderblom, L.A., Kathleen Edwards, E.M. Eliason, E.M. Sanchez, and M.P. Charette, 1978. Global color variations on the Martian surface. Icarus, vol. 34, p. 446-464. 24. Snyder, J. P., 1982. Map projections used by the U.S. Geological Survey. Geological Survey Bulletin 1532, U.S. Government Printing Office, Washington D.C., 313 p. 25. Planetary Cartography Working Group, 1984. Planetary cartography in the next decade (1984-1994). National Aeronautics and Space Administration Special Publication 475, 71 p. 26. Planetary Cartography Working Group, 1993. Planetary cartography 1993-2003. National Aeronautics and Space Administration Special Publication (no mumber), 50 p. 27. LaVoie, S., C. Avis, H. Mortensen, C. Stanley, and L. Wainio, 1987. VICAR - User's Guide, JPL Document D-4186, Jet Propulsion Laboratory, Pasadena, Ca. 28. Planetary Image Cartography System (PICS), Unpublished Manual, Branch of Astrogeology, U. S. Geological Survey, Flagstaff, Az., 1987. PICS is an integrated computerized system for the systematic reduction, display, mapping, and analysis of planetary image data. 29. Edwards, Kathleen, 1987, Geometric processing of digital images of the planets: Photogrammetric Engineering and Remote Sensing, vol. 53, no. 9, p. 1219-1222. 30. Wu, S.S.C., and Doyle, F.J., 1990, Topographic mapping, in Greeley, Ronald, and Batson, R.M., eds, Planetary Mapping: New York, Cambridge University Press, p. 169-207. 31. McDonnell, M. J., 1981. Box-filtering Techniques: Computer Graphics and Image Processing, Vol. 17, pp 65-70. 32. Kirk, R. L., Thompson, K. T., Becker, T. L., and Lee, E. M., 2000, Photometric modelling for planetary cartography, Lunar Planet. Sci., XXXI, Abstract #2025, Contribution No. 1000, Lunar and Planetary Institute, Houston (CD-ROM). 33. Chandrasekhar, S., 1960, Radiative Transfer, Dover, 393 pp. 34. Hapke B., 1981, Bidirectional reflectance specroscopy 1. Theory, J. Geophys. Res., vol. 86, p. 3039. 35. Hapke, B., 1984, Bidirectional reflectance spectroscopy 3. Correction for macroscopic roughess, Icarus, vol. 59, p. 41. 36. Johnson, J. R., et al., 1999, Preliminary results on photometric properties of materials at the Sagan Memorial Station, Mars, J. Geophys. Res., vol. 104, p. 8809. 37. Tomasko, M. G., et al., 1999, Properties of dust in the martian atmosphere from the Imager on Mars Pathfinder, J. Geophys. Res., vol. 104, p. 8987; Markiewicz, W. J., et al., 1999, Optical properties of Mars aerosols as derived from Imager for Mars Pathfinder Midday Sky Brightness Data, J. Geophys. Res., vol. 104, p. 9009. 38. Bernstein, R., Branning, H., 2nd Ferneyhough, D.G., 1971, Geometric and radiometric correction of high resolution images by digital image processing techniques; IEEE Intl. Geosci. Electronics Symp., Washington, D.C. 39. Davis, R. L., June 1990. Specification for the Object Description Language, Version 2.0; Available from the PDS, Jet Propulsion Laboratory, Pasadena, Ca. 40. Cribbs, M., and Wagner, D., May, 1991. Planetary Data System Data Preparation Workbook; vols. 1 and 2, JPL Document 7669, Jet Propulsion Laboratory, Pasadena, Ca. 41. 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) may 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. For example, hexadecimal value AA BB CC DD becomes DD CC BB AA. 42. Information processing -- Volume and file structure of CDROM for information interchange, ISO/DIS document number 9660, International Organization for Standardization, 1 Rue de Varembe, Case Postale 56, CH-1121 Geneva 20, Switzerland, 1987. APPENDIX A - ISO VOLUME AND DIRECTORY STANDARD A.1 - VOLUME AND DIRECTORY STRUCTURES The volume and directory structure of the CDROM conforms to the standard specified by the International Organization for Standardization (ISO) [42]. This standard is known as the ISO-9660 standard. This CDROM disk conforms to the first level of interchange, level-1. A.2 - FILE STRUCTURE The files on this CDROM are of two types: fixed-length record files, and stream format files. The characteristics of each record type are described in the following sections. A.2.1 - FIXED LENGTH RECORDS Records in a file with fixed-length records are all the same length, and there is no embedded information to indicate the beginning or end of a record. Fixed-length records allow any part of a file to be accessed directly without the need to pass through the file sequentially. Image files with the file name extension '.IMG' and table files with the file name extension '.TAB' are fixed-length record files. The starting byte of any record can be calculated as follows: offset = (record-1)*length where: offset = offset byte position of record from start of file record = desired record to access length = length of record in bytes A.2.3 - STREAM FILES Stream files typically are used to store ASCII text such as documentation and program source code. A stream file may have records of varying lengths. The end of a record is marked by two bytes containing the ASCII carriage return and line feed characters (hex 0D and 0A). Stream files are different from variable-length record files, which store the record size in the first two bytes of each record. On this CDROM, the documentation files, detached label files, and software source code files are in stream format. They may be printed or displayed on a terminal. Their file names have the extensions '.TXT', '.LBL', '.C', or '.FOR'. A.2.4 - EXTENDED ATTRIBUTE RECORD An extended attribute record (XAR) contains information about a file's record format, record attributes, and record length. 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. Not all computer operating systems support extended attribute records. Those that do not will simply bypass the XAR when accessing a file. APPENDIX B - SYNTACTIC RULES OF KEYWORD ASSIGNMENT STATEMENTS The label area of the image files use the syntactic rules of the Object Definition Language (ODL) adopted by the PDS. This appendix provides only a very brief description of the syntax of the ODL language. For a complete description of the ODL language see Davis [39], and the Planetary Data System Data Preparation Workbook - Volume 1 [40]. A keyword assignment statement, made up of a string of ASCII characters, contains the name of an attribute and the value of that attribute. A keyword assignment statement has the general form shown below: name = value [/* comment */] The format of each keyword assignment statement is essentially free- form; blanks and tabs are typically ignored by a parsing routine. An attribute name is separated from its value by the equal symbol (=). Each keyword assignment statement 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 also exist on a line without a keyword assignment statement. Note that the brackets indicate that the comment and its delimiter are optional. The MDIM labels have carriage-return and line-feed characters following the "name = value" sequence. The ODL language does not require a cr/lf sequence at the end of each keyword assignment statement but are optional in order to facilitate printing of keywords. Values associated with an attribute can be integers, real numbers, unitized real numbers, literals, times, or text strings. B.1 - INTEGER NUMBERS An integer value consists of a string of 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'. For example, the number expressed as 2#111# represents the binary number 111, which is 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 digits that specify the integral portion of the number. d = one or more 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 an associated unit of measurement. The units for a real number value are enclosed in angle brackets (< >). For example, 1.234 indicates a value of 1.234 seconds. B.3 - DATES AND TIMES A special form of a numeric field is a time value. The following format of date/time representations 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 (UTC). B.4 - LITERAL VALUES A literal value is an alphanumeric string that is a member of a set of finite values. It can also contain underscore character (_). A literal value must be delimited by double or single quote characters (" or ') if it does not begin with a letter (A-Z). If the literal begins with a letter, it does not have to be enclosed in single quotes. If a literal appears within quotes, the literal may contain any printable ASCII character. For example, the literal value "1:1" is legal as long as the single or double quoted format is used. A keyword assignment statement using a literal value might look like the examples shown below: DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V2.0" TARGET_NAME = MARS B.5 - TEXT CHARACTER STRINGS Text strings can be any length and can consist of any sequence of printable ASCII characters including tabs, blanks, carriage-control, or line-feed characters. Text strings are enclosed in double quote characters. If the text string comprises several lines, it continues until a double quote character is encountered and includes the carriage- control and line-feed characters. APPENDIX C - KEYWORD ASSIGNMENTS FOR MDIM IMAGES CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL This keyword provides a mechanism for image files on this CDROM to conform to the SFDU (Standard Formatted Data Unit) convention. The first 20 bytes identify the file as a CCSDS SFDU entity. The next 20 bytes identify the file as a registered product of the JPL SFDU control authority. The components of both SFDU labels are 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 version identifier indicates a "Version-3" label, which allows files to be delimited by an end-of-file marker, rather than requiring a byte count to be embedded in the label. The keyword conforms to standard PDS keyword syntax and the value associated with this keyword will always be SFDU_LABEL. RECORD_TYPE = FIXED_LENGTH This keyword defines the record structure of the file. The MDIM image files are always fixed-length record files. This keyword always contains the value FIXED_LENGTH. RECORD_BYTES = xxxx Record length in bytes for fixed length records. 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 = xx The (^) character prefixing a keyword indicates that the keyword is a pointer to the starting record of a data 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. ^IMAGE = xx The keyword value points to the starting fixed-length record in the file for the Image Object. DATA_SET_ID = "VO1/VO2-M-VIS-5-DIM-V2.0" The PDS defined data set identifier for the MDIM image data products produced from the Viking Orbiter Imaging System. SPACECRAFT_NAME = {VIKING_ORBITER_1, VIKING_ORBITER_2} The spacecraft name identifies the spacecrafts that acquired the image data. For the MDIM images, this keyword always contains the values VIKING_ORBITER_1 and VIKING_ORBITER_2 to indicate that images that make up the mosaics are a composite of data acquired from these two spacecraft. TARGET_NAME = MARS Observation target of the image. This value is always MARS for the MDIM digital image products. IMAGE_ID = vwxxyzzz This is the unique image identification code for the MDIM image. The IMAGE_ID is the same as the name given to the file. v = Type of image file M - Mars Digital Image Map T - Mars Digital Topographic Model S - Shaded Relief Airbrush Map w = Resolution code for image file C - 1/4 degrees/pixel E - 1/16 degrees/pixel G - 1/64 degrees/pixel I - 1/256 degrees/pixel xx = Central latitude value rounded down to nearest whole latitude y = North or South latitude N - North latitude S - South latitude zzz = Central longitude value rounded down to nearest whole longitude SOURCE_IMAGE_ID = {"316A27","427A33"} The MDIM images are a mosaic of Viking Orbiter images. This keyword lists the IMAGE_ID's of those Viking Orbiter images that were used in the mosaic for this image. This keyword is a set of literal values. INSTRUMENT_NAME = {VISUAL_IMAGING_SUBSYSTEM_CAMERA_A, VISUAL_IMAGING_SUBSYSTEM_CAMERA_B} The name of the cameras used to acquire the image. This keyword will always contain the values VISUAL_IMAGING_SUBSYSTEM_CAMERA_A and _B. NOTE = "description" This field provides the product name, scale, and latitude and longitude of the center of the image. OBJECT = IMAGE_HISTOGRAM ITEMS = 256 ITEM_TYPE = VAX_INTEGER ITEM_BITS = 32 END_OBJECT = IMAGE_HISTOGRAM This keyword sequence identifies the Image Histogram Object. The object contains 256 elements, stored in VAX integer format [38]. Each element has 32 bits. The records associated with an object are concatenated together to make the object. Some objects do not completely fill the records that make up the object. OBJECT = IMAGE LINES = xxxx LINE_SAMPLES = xxxx SAMPLE_TYPE = UNSIGNED_INTEGER SAMPLE_BITS = 8 SAMPLE_BIT_MASK = 2#11111111# CHECKSUM = xxxxxxxxx END_OBJECT = IMAGE This keyword sequence describes the image object. The meaning of the keywords with this sequence area as follows: LINES = xxxx Number of image lines in the image object. LINE_SAMPLES = xxxx Number of samples in each image line. SAMPLE_TYPE = UNSIGNED_INTEGER Data type for pixels values, should always be unsigned integers. For DTM images the value is SIGNED_INTEGER SAMPLE_BITS = 8 Number of bits in a pixel, which are 8-bit values in the range 0 to 255. For DTM images the value is 16 SAMPLE_BIT_MASK = 2#11111111# 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 or 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#11111111# indicates all bits active. CHECKSUM = xxxxxxxxxx The sum of all the pixel values within the image. This parameter can be used to verify the reading of an image file. OBJECT = IMAGE_MAP_PROJECTION_CATALOG ^DATA_SET_MAP_PROJECTION_CATALOG = "DSMAPDIM.LBL" MAP_PROJECTION_TYPE = SINUSOIDAL MAP_RESOLUTION = x MAP_SCALE = x.xxxxx MAXIMUM_LATITUDE = x.xxxxx MINIMUM_LATITUDE = x.xxxxx MAXIMUM_LONGITUDE = x.xxxxx MINIMUM_LONGITUDE = x.xxxxx X_AXIS_PROJECTION_OFFSET = x.xxxxx Y_AXIS_PROJECTION_OFFSET = x.xxxxx A_AXIS_RADIUS = 3396.0000000 B_AXIS_RADIUS = 3396.0000000 C_AXIS_RADIUS = 3376.8000488 FIRST_STANDARD_PARALLEL = "N/A" SECOND_STANDARD_PARALLEL = "N/A" POSITIVE_LONGITUDE_DIRECTION = WEST CENTER_LATITUDE = 0.00000 CENTER_LONGITUDE = x.xxxxx REFERENCE_LATITUDE = "N/A" REFERENCE_LONGITUDE = "N/A" X_AXIS_FIRST_PIXEL = 1 Y_AXIS_FIRST_PIXEL = 1 X_AXIS_LAST_PIXEL = xxxx Y_AXIS_LAST_PIXEL = xxxx MAP_PROJECTION_ROTATION = "N/A" END_OBJECT = IMAGE_MAP_PROJECTION_CATALOG This keyword sequence describes the cartographic keywords that define the mapping parameters of the image. ^DATA_SET_MAP_PROJECTION_CATALOG = "DSMAPDIM.LBL" This keyword points to a separate file (DSMAPDIM.LBL) on the CDROM that contains supplemental and nonessential keyword descriptors for map projection parameters. By convention, supplemental labels are found in the LABEL directory. MAP_PROJECTION_TYPE = SINUSOIDAL This element identifies the type of projection used in the map. This value is always SINUSOIDAL for the MDIM products and signifies a Sinusoidal Equal-Area projection. MAP_RESOLUTION = x This element identifies the scale of the MDIM image file. The resolution is defined in pixels per degree. Please note the omission of units which had previously been included in the MDIM 1.0 image label. MAP_SCALE = x.xxxxx This element identifies the scale of the MDIM image file and is defined in kilometers per pixel. Please note the omission of units which had previously been included in the MDIM 1.0 image label. MAXIMUM_LATITUDE = x.xxxxx This element specifies the northern most latitude in the MDIM image file. MINIMUM_LATITUDE = x.xxxxx This element specifies the southern most latitude in the MDIM image file. MAXIMUM_LONGITUDE = x.xxxxx This element specifies the left-most longitude of the image file. MINIMUM_LONGITUDE = x.xxxxx This element specifies the right-most longitude of the image file. X_AXIS_PROJECTION_OFFSET = x.xxxxx This element provides the line offset value of the map projection origin position from line and sample 1,1. Note that the positive direction is to the right and down. See Appendix E for the use of this element. Y_AXIS_PROJECTION_OFFSET = x.xxxxx This element provides the sample offset value of the map projection origin position from line and sample 1,1. Note that the positive direction is to the right and down. See Appendix E for the use of this element. A_AXIS_RADIUS = 3396.0000000 B_AXIS_RADIUS = 3396.0000000 C_AXIS_RADIUS = 3376.8000488 These elements provide the semi-major axis (A), Intermediate axis (B), and semi-minor axis of the ellipsoid that defines the shape of the body defined in kilometers. These values are always 3396.00, 3396.00, and 3376.8000488 respectively. FIRST_STANDARD_PARALLEL = "N/A" This element is a mapping transformation parameter. The Sinusoidal Equal-Area projection does not used this element. SECOND_STANDARD_PARALLEL = "N/A" This element is a mapping transformation parameter. The Sinusoidal Equal-Area projection does not used this element. POSITIVE_LONGITUDE_DIRECTION = WEST This element identifies the direction of longitude (EAST,WEST) for a planet. The IAU definition for direction of positive longitude is adopted. For MARS this direction is WEST. CENTER_LATITUDE = 0.00000 This element identifies the center latitude of the projection. For Sinusoidal Equal-Area projections, this value is zero. CENTER_LONGITUDE = x.xxxxx This element identifies the center longitude of the projection. Each MDIM image file has its own center longitude. See Appendix E for the use of this mapping parameter. REFERENCE_LATITUDE = "N/A" This element is a mapping transformation parameter. The Sinusoidal Equal-Area projection does not used this element. REFERENCE_LONGITUDE = "N/A" This element is a mapping transformation parameter. The Sinusoidal Equal-Area projection does not used this element. X_AXIS_FIRST_PIXEL = 1 This element provides the x-dimension index to be assigned the first pixel that was physically recorded at the beginning of the image array. This value always 1 for MDIM image files. Y_AXIS_FIRST_PIXEL = 1 This element provides the y-dimension index to be assigned the first pixel that was physically recorded at the beginning of the image array. This value always 1 for MDIM image files. X_AXIS_LAST_PIXEL = xxxx This element provides the x-dimension index to be assigned the last pixel that was physically recorded at the end of the image array. For MDIM image files, this element equals the number of lines in the image. Y_AXIS_LAST_PIXEL = xxxx This element provides the y-dimension index to be assigned the last pixel that is physically recorded at the end of the image array. For MDIM image files, this element equals the number of samples in the image. MAP_PROJECTION_ROTATION = "N/A" This element is a mapping transformation parameter. The Sinusoidal Equal-Area projection does not used this element. END The keyword entries with a line that contains only the word END. Bytes in the label area after the END statement are ignored. APPENDIX D - GEOMETRIC DEFINITION OF A PIXEL The purpose here is to describe the spatial or geometric definition of a pixel used in the generation and utilization of the MDIM digital image products. A broad range of factors enters into this question. For example, is a pixel to be conceived of as a point or as an area? The point definition would be most convenient, for instance, when dealing with coordinate grid overlays. This results in an odd number of pixels across a map that has an even number of spatial increments. For changing scales (for instance by even powers of 2) this definition becomes a problem. In this case it makes more sense to treat a pixel as a finite area. Then an even number of pixels covers an even number of spatial increments and decreasing/increasing scales by a power of 2 becomes trivial. However, grids now fall between pixels, at least in a mathematical sense. Their treatment in the generation of hardcopy therefore becomes an issue. It was decided that the area concept of a pixel was the better choice; we would have to live with the asymmetries introduced in things like cartographic grids. There are various solutions: (1) use two pixels for the width of a grid line, (2) stagger grid pixels back-and-forth across the mathematical position, (3) use a convention whereby grid lines are systematically drawn offset from their mathematical position. The next issue is the conversion between integer coordinates and real coordinates of the pixel mesh. We adopt the convention that pixels are numbered (or named if you like) beginning in the upper left corner with line 1, sample 1 (pixel 1,1); lines increase downward; samples increase to the right. (Even this is not a universal standard; some astronomical systems begin, perhaps more logically, in the lower left corner.) There are three reasonable possibilities for aligning a real, or floating point, coordinate system with the pixel mesh: the coordinate 1.0, 1.0 could be the upper left, the center, or the lower right of pixel 1,1. The convention historically used for geometric calibration files (reseau positions) and also used in the Multimission Image Processing Laboratory at the Jet Propulsion Laboratory, is that the center of the pixel is defined as its location in real coordinates. In other words, the real coordinates of the center of pixel 1,1 are 1.0, 1.0. The top left corner of the pixel is .5, .5 and the bottom right corner is 1.49999, 1.499999. The bottom and right edge of a pixel is the mathematically open boundary. This is the standard adopted in the MDIM image products. Cartographic conventions must also be defined. The map projection representation of a pixel is mathematically open at the increasing (right and lower) boundaries, and mathematically closed at its left and upper boundaries. An exception occurs at the physical limits of the projection; the lower boundary of the lowest pixel is closed to include the limit of the projection (e. g. the south pole). Figure D.1 shows the coordinates of Pixel 1,1. Figure D.1 - Coordinates of Pixel 1,1 longitude 180.0 179.00001 | | latitude | | line 90.0 -- ----------------- -- .5 | | | | | | | | | + | | (1.0,1.0) | | | | | | | 89.00001 -- ----------------- -- 1.49999 | | | | sample .5 1.49999 Finally, we must select a convention for drawing grid lines for various cartographic coordinates on planetary images and maps. The convention used for MDIM image products is that a grid line is drawn in the pixels that contain its floating point value until the open boundary is reached and then an exception is made so that the outer range of latitude and longitude will always appear on the image. This means, in the example given above, a 10 degree grid would start on pixel 1 and be drawn on every tenth pixel (11,21,31,...) until the open boundary is reached. Then the line would be drawn on the pixel previous to the open boundary (line 180 instead of line 181, or sample 360 instead of 361). To summarize, the MDIM conventions are: 1) Pixels are treated as areas, not as points. 2) The integer coordinates begin with 1,1 (read "line 1, sample 1") for the upper-left-most pixel; lines increase downward; samples increase to the right. 3) Integer and floating point image coordinates are the same at the center of a pixel. 4) Grids will be drawn in the pixels that contain the floating point location of the grid lines except for open boundaries, which will be drawn to the left or above the open boundary. APPENDIX E - SINUSOIDAL EQUAL-AREA PROJECTION EQUATION MDIM's are presented in a Sinusoidal Equal-area map projection. In this projection, parallels of latitude are straight lines, with constant distances between equal latitude intervals. Lines of constant longitude on either side of the projection meridian are curved since longitude intervals decrease with the cosine of latitude to account for their convergence toward the poles. This projection offers a number of advantages for storing and managing global digital data; in particular, it is computationally simple, and data are stored in a compact form. The Sinusoidal Equal-area projection is characterized by a projection longitude, which is the center meridian of the projection, and a scale, which is given in units of pixels/degree. The center latitude for all MDIM's is the equator. Each MDIM file contains its own central meridian. The transformation from latitude and longitude to line and sample for planets with a direction of positive longitude of WEST is given by the following equations: NOTE: Version 2 author addition: The following equations do not apply to the Version 2 release of the MDIM. Please see ERRATA.TXT file in the CD root directory for updated equations and discussion. line = INT(X_AXIS_PROJECTION_OFFSET - lat*MAP_RESOLUTION + 1.0) sample = INT(Y_AXIS_PROJECTION_OFFSET - (lon - CENTER_LONGITUDE)* MAP_RESOLUTION*cos(lat) + 1.0) Note that integral values of line and sample correspond to center of a pixel. Lat and lon are the latitude and longitude of a given spot on the surface. INT is the fortran equivalent floating point to integer function. This function converts floating point values to integer by truncation of the fractional part of the floating point value. X_AXIS_PROJECTION_OFFSET is the line number minus one on which the map projection origin occurs. The map projection origin is the intersection of the equator and the projection longitude. The value of X_AXIS_PROJECTION_OFFSET is positive for images starting north of the equator and is negative for images starting south of the equator. The X_AXIS_PROJECTION_OFFSET is found in the labels of each image file. Y_AXIS_PROJECTION_OFFSET is the nearest sample number to the left of the projection longitude. The value of Y_AXIS_PROJECTION_OFFSET is positive for images starting to the west of the projection longitude and is negative for images starting to the east of the projection longitude. The Y_AXIS_PROJECTION_OFFSET is found in the labels of each image file. CENTER_LONGITUDE is the value of the projection longitude, which is the longitude that passes through the center of the projection. The CENTER_LONGITUDE is found in the labels of each image file. MAP_RESOLUTION is the number of pixels per degree on the planet. The values for MDIM products will be 256, 64, 16, and 4. The MAP_RESOLUTION is found in the labels of each image file. There are four PDS parameters that specify the latitude and longitude boundaries of an image. MAXIMUM_LATITUDE and MINIMUM_LATITUDE specify the latitude boundaries of the image, and MAXIMUM_LONGITUDE and MINIMUM_LONGITUDE specify the longitudinal boundaries of the map. A special note is required for the MAXIMUM_LONGITUDE and MINIMUM_LONGITUDE parameters that define the boundaries of an image. The MAXIMUM_LONGITUDE will be greater than the MINIMUM_LONGITUDE except when the image map crosses the zero meridian. When the zero meridian is contained in the image area, then the MINIMUM_LONGITUDE will be greater than the MAXIMUM_LONGITUDE. When this occurs, it may be convenient for a computer algorithm that uses these parameters to subtract 360.0 degrees from the MINIMUM_LONGITUDE. For example, if an image had longitude boundary limits from 10.0 degrees longitude (MAXIMUM_LONGITUDE) to 350.0 degrees longitude (MINIMUM_LONGITUDE) then it is implied that the zero meridian is in the middle of the image file. One could think of the longitude limits of the file going from 10.0 to -10.0 degrees longitude. For global maps that cover the entire 360 degrees of a planet, the MINIMUM_LONGITUDE will equal the MAXIMUM_LONGITUDE indicating that the "left" edge of the map has the same longitude as the "right" edge of the map.