Data Set Overview
  =================
    This CD contains portions of the MOC Decompressed Standard Data
    Product (DSDP) Archive, a collection of decompressed images from
    the Mars Orbiter Camera on the Mars Global Surveyor spacecraft.
    Images are stored with PDS labels, but are otherwise unprocessed
    and uncalibrated.
 
    This CD contains also ancillary data files and browse images in a
    JPEG format, HTML documents that support a web browser interface
    to the CDs, an index file ('imgindx.tab') that tabulates the
    contents of the CD, and documentation files.
 
    For more information on the contents and organization of the CD
    volume set refer to the 'CD CONTENTS, DIRECTORY, AND FILE NAMING
    CONVENTIONS' section of the aareadme.txt file located in the root
    directory of the data volumes.
 
    Using a web browser, open the 'index.htm' file located in the
    'root' directory of the CD. The HTML document will direct you to
    other informational documents and the image browser for rapidly
    viewing the image collection.
 
 
  Parameters
  ==========
    Although this dataset has not been calibrated, and the algorithms
    for calibration are still being developed, we here describe some
    of the relevant calibration parameters.
 
    The MOC uses programmable gain and offset states, commanded on the
    ground prior to image acquisition, to condition the CCD output
    signal prior to its digitization to 8 bits.  The very wide
    potential dynamic range of MOC images has required a large number
    of gain states (16 for the NA and 20 for the WA) and offset states
    (256 possible) compared to, for example, the Viking cameras, which
    had only two gain and two offset states.  This leads to the
    operational complexity of predicting the scene brightness in
    advance and selecting appropriate parameters.
 
    The GAIN_MODE_ID and OFFSET_MODE_ID fields in the image headers
    describe the gain/offset selection.  The GAIN_MODE_ID is a two-
    digit hexadecimal number which is the value of the MOC hardware
    register that selects the gain.  The allowable flight values are
 
          Narrow Angle
    gain  hex    gain   hex
    ----    --- ----    ---
    1     F2     7.968  EA
    1.465 D2    11.673  CA
    2.076 B2    16.542  AA
    2.935 92    23.386  8A
    4.150 72    33.067  6A
    5.866 52    46.740  4A
    8.292 32    66.071  2A
    11.73 12    93.465  0A
 
         Wide Angle
    gain  hex   gain   hex
    ----  ---   ----   ---
    1.000 9A    16.030  96
    1.412 8A    22.634  86
    2.002 7A    32.092  76
    2.832 6A    45.397  66
    4.006 5A    64.216  56
    5.666 4A    90.826  46
    8.014 3A   128.464  36
    11.34 2A   181.780  26
    16.03 1A   256.961  16
    22.67 0A   363.400  06
 
    where the gain value given is the nomimal multiplicative factor
    from the lowest gain state.
 
    The OFFSET_MODE_ID is the value of the MOC hardware register that
    selects the offset.  Offsets are commanded in units of 5 (five)
    Data Numbers (DN), so an OFFSET_MODE_ID of '1' would correspond to
    a DN offset of 5.  All offsets are positive.
 
    The simplified MOC response equation (without pixel-to-pixel
    variation terms) is as follows:
 
           dn = a*(r*ex+dc*ex+g)+(z-off)
 
    where r is the average signal level being generated at the focal
    plane (in DN/msec at minimum gain), z is the fixed zero offset,
    off is the commanded variable offset in DN (note that the offset
    is subtracted), dc is the dark-current term (in DN/msec at minimum
    gain), g is the gain-dependent offset (in DN at minimum gain), a
    is the system gain (where minimum gain is 1 and all other gains
    are >1, as given in the above tables), and ex is the exposure time
    (given in the image headers as the LINE_EXPOSURE_DURATION.)
 
    In-flight values for the fixed parameters in the above equation
    are still being derived from flight data.  The values from ground
    testing at ambient conditions are
 
    system    z         dc             g
 
    NA prime  25.5767   -0.0529099     0.381963
    NA spare  28.934    -0.0099495     0.371922
    WA red    27.5633    0.0013369     0.196468
    WA blue   27.9424    0.0008232     0.264303
 
    The significance of the negative dark-current terms for the NA
    systems is suspected to be due to other system noise sources in
    ground testing; the NA systems should have negligible dark
    current, even at room temperature, because of the short exposure
    times.
 
    The calibration algorithm will consist of two independent parts:
    removal of the pixel-to-pixel variation, which causes the visually
    apparent 'streaking' in the downtrack direction in MOC images, and
    conversion to either relative or absolute flux units (for purposes
    of mosaic construction, photometry, etc.)  Work is ongoing to
    define these algorithms.  Future volumes will include more
    information.
 
 
  Processing
  ==========
    Processing included packet decommutation, removal of the MOC
    communications protocol headers, and decompression.  No additional
    geometric or radiometric processing was done.
 
    For most of the pre-mapping phase of the MGS mission, data quality
    did not allow error-free transmission of the instrument data to
    Earth. The MOC protocols (in particular, the formats for
    compressed image data) were designed for the bit error rates
    expected in mapping.  As a result, considerable data losses were
    incurred in the image data.  The majority of processing for pre-
    mapping data was done to minimize the effects of this data loss.
    These efforts are ongoing; corrections for significant losses may
    appear on future volumes.
 
    MOC image data are broken up into 'packets' of approximately 1000
    bytes.  A typical data loss is that of one or two packets, due to
    uncorrectable bit errors caused by noise in the space-to-Earth
    communications path, momentary loss of receiver lock caused by a
    transition between the one-way and two-way tracking modes, or loss
    in the Earth segment of the Deep Space Network.
 
    For uncompressed images, a packet loss leads to loss of 'line
    sync' in the image.  Since the amount of actual image data in a
    packet is variable and cannot be determined precisely without the
    packet, such errors must be corrected by hand.  This has been done
    for as many images as practical.  The majority of NA images were
    acquired using the lossless predictive compression mode of the
    MOC.  However, when a packet is lost from this compressed data
    stream, the decompression algorithm cannot realign itself to the
    compressed pixel boundaries, and must skip ahead to the next sync
    marker, which occurs only every 128 lines in the image.  The
    effect of decompressing the data between the site of packet loss
    and the next sync marker is unpredictable, but usually results in
    either semi-random variations in pixel brightness (with the
    general morphology of the original image still visible) or
    essentially random noise patterns.
 
    A second type of loss is that of tens or hundreds of packets
    caused by bad weather, hardware failure, or operator error at the
    DSN stations, or miscommanding of the telemetry playback on the
    spacecraft.  For these errors in a compressed data stream, over
    128 lines of the image were lost, making it impossible to recover
    even the original downtrack size of the image.  Such images are
    described as 'PARTIAL' in the NOTE field of each image header.
 
    The browse images were subsampled via averaging and then auto-ends
    stretched to create visually acceptable contrast.  No other
    processing was performed.  Subsampling was intended to produce an
    image of an approximately fixed size, so the subsampling employed
    varied depending on the original image's dimensions.
 
 
  Media/Format
  ============
    The MOC DSDP archive is delivered to the Planetary Data System
    using CD media.  Formats are based on standards for such products
    established by the Planetary Data System (PDS) [PDSSR1992].

Confidence Level Overview
  =========================
 
    Geometric Accuracy
    ------------------
      Latitude and longitude coordinates for the images given in the
      imgindx.tab file were computed using the best-available
      spacecraft position and orientation information, in the form of
      SPK and CK kernel files for the NAIF SPICELIB software.  The
      versions used were recommended by the MGS Project and were
      retrieved from the NAIF FTP server (naif.jpl.nasa.gov):
 
      mgs_ab1.bsp: Mars Global Surveyor Aerobraking-1 SPK file, MGSNAV
      Solution, Created by Boris Semenov, NAIF/JPL, October 2, 1998
 
      mgs_spo.bsp: Created 1998-09-26/12:50:00.00.
 
      mgs_spo2_gsfc.bsp: Mars Global Surveyor SPO-2 SPK file, GSFC
      Solution, Created by Boris Semenov, NAIF/JPL, October 2, 1998
 
      mgs_sc_ab1.bc: Created by Boris Semenov, NAIF/JPL November 29,
      1998
 
      mgs_sc_spo1.bc: Created by Boris Semenov, NAIF/JPL November 29,
      1998
 
      mgs_sc_spo2.bc: Created by Boris Semenov, NAIF/JPL November 29,
      1998
 
      de403s.bsp: Dated 14-NOV-1995, Created 1995-06-01/12:14:42.00.
 
      Latitude is given in areographic form using the IAU 1994
      definition of the Martian equatorial and polar radii (3397.0 and
      3375.0 km, respectively).  Coordinates are computed using the
      1994 IAU spin vector values.
 
      Because of uncertainty in the MOC-to-S/C frame offset and
      limitations of the processing software, the MOC offset
      ('I kernel') was not applied; this should make a difference no
      more than 1/2 MOC NA FOV, probably less.
 
      It has been observed by MSSS that the USGS MDIM images were
      constructed based upon a definition of Mars' orientation from
      the Viking period.  It can be shown that this results in a
      systematic shift between the 'old' and 'new' systems of 0.213
      degrees in longitude.  To place an image footprint onto the
      MDIM, one should subtract 0.213 degrees from the longitudes
      tabulated on this data volume.  Any residual error in the
      location of the image is caused by further uncertainties in the
      MDIM and/or in the position and orientation information of the
      MGS spacecraft.  Obviously, the best available SPICE information
      should be used for geometric calculations.
 
      In cases where only a portion of the lines of the image were
      actually recovered on the ground due to the data loss described
      above, the lat/lon coordinates given in the table are those of
      the center and corners of the image as received, with the caveat
      that in rare instances, lines may have been lost from the top of
      the image.  In such cases, the start time of the image is that
      commanded, not the actual line time of the first line of
      received data, and it is not possible to determine what the true
      footprint of the image is, without matching features seen in the
      image to preexisting image data.
 
      In a few cases, spacecraft pointing information was not
      available for an image.  In these cases, a nominal nadir
      pointing attitude has been assumed.  This may lead to large
      errors in the footprint information, which should be considered
      advisory only.
 
    Map Projections of Images
    -------------------------
      High-precision map projections of the images may be generated
      using the parameters given in the image header and/or the
      imgindx.tab file, the appropriate SPICE kernels, and map-
      projection software capable of processing line-scan imagery.
 
      Lacking such software, however, a first-order map projection may
      be produced by using the lat/lon coordinates of the image
      corners given in the imgindx.tab file, transforming these four
      points from rectangular image space to the essentially arbitrary
      quadrilateral in map-projection space using the desired map-
      projection equations, and then performing a four-point bilinear
      warp.  Such a warp can be done in commercial packages such as
      Photoshop, as well as software specifically for planetary image
      analysis (PICS, ISIS, VICAR, etc.)
 
      Users wishing simply to correct for the effects of imaging
      flipping, non-square pixel aspect ratio and image skew may also
      find the USAGE_NOTE, PIXEL_ASPECT_RATIO and IMAGE_SKEW_ANGLE
      fields in the imgindx.tab file useful.  The USAGE_NOTE indicates
      if the image should be flipped left-for-right prior to
      additional processing.  If IMAGE_SKEW_ANGLE is not too far from
      90 degrees, the image can be rectified to square-pixel form by
      expanding it in the vertical axis by a factor of
      PIXEL_ASPECT_RATIO (noting that values less than 1 result
      in shrinking rather than expansion.)  Skew angles far from 90
      degrees can be corrected by skewing the image from a rectangle
      to a rhomboid with a base angle of the given skew angle.