| DATA_SET_DESCRIPTION |
Data Set Overview
=================
This CD contains portions of the MOC Standard Data Product (SDP)
Archive, a collection of compressed image data from the Mars Orbiter
Camera on the Mars Global Surveyor spacecraft. Image data are
stored with PDS labels, but are otherwise unprocessed and
uncalibrated.
This CD contains also ancillary data files, an index file
('imgindex.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.
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.
Many of the longer-duration WA images actually span multiple
gain-offset states, although their labels and ancillary table
entries only contain the state in effect at the beginning of
data acquisition.
For some applications, it is useful to know the time of the
gain-offset state changes so that calibration can account for them.
Refer to the wago.tab file for this information.
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, reformatting, and addition of PDS
label information. 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. This processing is
too labor-intensive to process the much larger volume of mapping
data. Unfortunately, data quality continues to be poorer than
expected during the mapping phase of the mission.
The decompression software provided on this volume makes some
attempt to correct for errors, and each image file contains a field,
DATA_QUALITY_DESC, that indicates if errors were detected in
transmission. Enhanced, automated algorithms for correction of data
errors is being developed on an ongoing basis.
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.
When data rates from the spacecraft are low due to large Mars-Earth
range, the MOC's lossy transform compressor was used to increase the
number of images returned. This compressor is similar to the JPEG
compressor in common use, although it uses 16x16 transform (DCT)
blocks followed by quantization, zero truncation, and Huffman
encoding of the remaining coefficients from a fixed set of encoding
tables. The compressed data are sent in column order by block.
As data loss was assumed to be rare, no sync markers were included
in the data stream. Thus, packet loss or corruption within the
compressed stream results in the incorrect decompression of the
remaining transform blocks in that image fragment. Depending on the
size and form of the loss, the blocks will either contain random or
'test pattern' noise, or, if the decompressor happens to realign to
a block boundary, the remaining image data will appear normal but be
shifted by some amount within the fragment. As noted above, work to
improve these results is ongoing.
Another 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.
Media/Format
============
The MOC SDP 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_NOTE |
Confidence Level Overview
=========================
Geometric Accuracy
------------------
Latitude and longitude coordinates for the images given in the
imgindex.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 constructed operationally by MOC personnel
from deliveries by the MGS Project. While these should be
equivalent to those retrievable from the NAIF FTP server
(naif.jpl.nasa.gov), there may be small discrepancies and the
NAIF versions are to be preferred for all further processing.
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 commanded.
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
imgindex.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 imgindex.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 imgindex.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.
|
.png)
.png)
