Data Set Overview
=================

The Cassini Orbiter Imaging Science Subsystem (ISS) archive datasets
consist of the Cassini ISS raw, uncalibrated experiment data record
image files, attached and detached label files (VICAR and PDS),
helpful and required PDS files, including an index table containing a
host of parameters for each image on the volumes, and related ISS 
instrument documentation. The volumes containing these products are 
referred to as the 'DATA' volumes.

Additionally, the ISS datasets include pre-launch ground calibration 
images, assorted calibration data files, algorithms, and 
documentation, the ISS calibration processing software (CISSCAL), 
and the ISS Data User's Guide. These volumes are referred to as the 
'CALIBRATION' volumes. (NOTE: ISS in-flight calibration images are 
found on the DATA volumes, as sequenced in Spacecraft Clock order.)

Several hundred thousand ISS images were taken throughout the entire 
CASSINI mission, including images taken during flybys of Earth, 
Venus, and Jupiter, and images taken of Saturn and Saturn's rings and 
moons while in orbit around Saturn.

In addition to imaging these targets, instrument calibration images 
were taken prior to launch and also while in-flight, as well as 
support images for other Cassini instrument teams and images for 
optical navigation; all of which are contained within these datasets.

Three separate datasets are generated by the ISS team:

  1) Cassini Orbiter Earth/Venus/Jupiter ISSNA/ISSWA EDRs -- Contains 
  all cruise phase imaging, including Earth, Venus and Jupiter flyby 
  images, and in-flight calibration images.

  2) Cassini Orbiter Saturn ISSNA/ISSWA EDRs -- Contains all Saturn 
  Tour phase imaging, including Saturn, Saturn's Rings and Satellites,
  along with in-flight calibration images.

  3) Cassini Orbiter Calibration ISSNA/ISSWA EDRs - Contains EDR 
  calibration related files, including calibration data files (eg., 
  dark currents) sample calibrated images, Cassini ISS calibration 
  processing software, calibration documents, the ISS Data User's 
  Guide, and the collection of pre-launch ground calibration images.

The ISS Data User's Guide can be found in the document directory of 
the most recent CALIBRATION volume, or accessed from:

http://pds-imaging.jpl.nasa.gov/software/

More information on the details of this volume can be found in the
aareadme.txt file at the root level of this volume and in the document
directory.



Processing
==========

Telemetry Processing
--------------------
Once the spacecraft data has been transmitted to the Deep Space 
Network (DSN) and sent electronically to JPL, it is reformatted by 
the Cassini Instrument Operations Team (IO) within the Multimission 
Image Processing System (MIPS) from a series of data packets into a 
two dimensional image, converting any 12-bit images to 16 bits in the 
process. Images acquired with lossless or lossy compression are 
decompressed. These Experiment Data Record (EDR) images are then sent 
to Cassini ISS Operations (ISS OPS) where they are ingested into the 
ISS Archive Database for access by Imaging Team members and the 
archive generation process.

Preliminary (quick-look) versions of the images are generated
immediately and distributed for instrument performance analysis. In
an attempt to make the most complete products, IO then performs
reconciliation, if there is missing data in these preliminary 
versions.  Once reconciliation is performed (within two weeks from 
downlink time), a final version of the image is produced and 
electronically provided to ISS OPS. Only the final image versions are 
archived on the ISS archive volumes. 

Some images have been converted down to 8-bits by the Lookup Table
(LUT); in these cases, a reverse LUT can be applied to restore them 
to their approximate full 12-bit values. (This is an option in the 
Cassini ISS Calibration (CISSCAL) software that is supplied in this
Archive.)  There is no way to restore an 8LSB image back to its full
12-bit fidelity unless the original pre-converted DN values were all
less than 255, or one is confident of smooth gradients across the
image. Consult the calibration documentation for more information
about converting image DN values to physical units.



ISS OPS Processing
------------------
The EDR image files are housed within ISS OPS during the lifetime of
the mission for ISS team access and archive volume assembly.  They are
stored in the ISS Archive Database as received from the JPL/IO team.  
No further modification, calibration, or processing is done to the 
images by ISS OPS. The EDR images are assembled onto the archive 
volumes exactly as they are received from IO/MIPS.

ISS OPS performs two functions utilizing the EDR data files received
from IO/MIPS: 1) auto navigation of the images, and 2) assemblage of
the archive volumes.

The ISS auto-navigation software provides for the refinement of
geometric information for each image.  Newly generated geometric
information is captured for inclusion in the index.tab file.  These
are the collection of archive keywords for supporting search and
query capabilities within the PDS. (The ISS Auto-Navigation software
is described below.) 

The ISS archive generation software provides for the assemblage of the
files being written to the archive volume.  This software was produced
by ISS OPS for selecting the appropriate range of images per volume,
gathering the static archive files and generating the dynamic files
being writing to the archive DVD volume.



ISS Auto-navigation
-------------------
The auto-navigation software (Autonav) was developed by the ISS team 
to perform the large task of image pointing refinement (c-smithing) 
for the hundreds of thousands of images taken by the ISS cameras.  
Autonav uses an array of object detection algorithms in conjunction 
with the most recent spacecraft position and orientation kernels to 
navigate the images. 

The output of Autonav for any particular navigated image is a single,
discrete c-kernel for the image mid time.  These c-smithed c-kernels
are packaged up in larger time periods and delivered to the Cassini
project's database and subsequently to the PDS NAIF node, and are
maintained within the ISS Archive Database for use by ISS team
members and by the ISS archive generation process.

Though the success rate of Autonav is high, it is not 100%. The code 
was structured to minimize the number of false-positive navigations.  
So, in many cases, some images that seem navigable will fail to meet 
the success thresholds built into Autonav.

In order to validate Autonav results, a tool was developed to allow a
final reviewer to quickly visually scan through Autonav results and
look for false-positive navigations and approve those that look
correctly navigated. A c-kernel compare tool is also used to
compare the auto-navigated c-kernels against the Attitude Control 
Subsystem (ACS) reconstructed c-kernels and flag large discrepancies 
between the two for further investigation. 

However, all of these thresholds and verification steps do not
absolutely prevent Autonav from producing false results, so future
users are warned to exercise caution with respect to these results. 
Autonav results, when accurate, will greatly improve the accuracy of
the geometrical quantities calculated for the index.tab file.



Data
====

Image VICAR Files
-----------------
All ISS images are in JPL/MIPS VICAR (Video Image Communication And
Retrieval) image format. More information about this format and 
software that can be used to view it can be found in the 'Software'
section below.

Each VICAR image file is accompanied by a detached ASCII PDS label
file. The label consists of ASCII 'keyword=value' pairs describing the
important characteristics of the image.


Image Index Table
-----------------
The image index table file, index.tab, contains keyword information
about each image on the volume.  Some of this information comes
directly from the EDR detached PDS image label produced by IO; for 
example, keywords such as FILE_NAME, DATA_CONVERSION_TYPE, 
IMAGE_MID_TIME, FILTER_NAME, etc.  The remaining keywords come from 
the Autonav software (as discussed above) which calculates many 
geometrical quantities and target information such as 
TARGET_DISTANCE, PIXEL_SCALE, PHASE_ANGLE, TWIST_ANGLE, etc. 

This file consists of fixed-length records in ASCII character format.
Each line is a record containing all the keywords for a particular
image on the volume.  Fields in a record are delimited by commas. 
Non-numeric fields are enclosed in quotes and left-justified, whereas
numeric fields are not enclosed by any characters and are
right-justified.  Multi-valued fields are enclosed in brackets and
each item in that field is separated by a comma.

The file index.lbl details the keyword name, data type, start byte,
number of bytes, and format so that keywords can be easily referenced
and the file can be properly read into a database.



Ancillary Data
==============
The Cassini Project produces SPICE files (spacecraft positions,
planetary positions and constants, processed pointing geometry,
spacecraft clock versus universal time, etc.) for use in observation
planning and in calculating many of the image keywords populating the
index.tab file on this volume.  These Cassini SPICE files are not
included in this ISS data archive but can be obtained from the PDS
NAIF node. 

However, provided to support image searching and querying, the
index.tab file contains over 100 keywords related to each image,
including geometrically-oriented keywords.  Some of these keywords
are supplied by IO/MIPS as part of the EDR processing, others are
generated by the ISS auto-navigation software.

Other ancillary files include the collection of software interface
specifications related to the production of the EDR data files and the
archive volume DVDs, documents related to camera calibration and the
calibration processing software, as well as a list of published
references that can provide a thorough discussion of the ISS science
goals and objectives and ISS camera instrument.



Coordinate System
=================
For proper interpretation of the image data, one should use a
Cartesian coordinate system referenced to the Earth mean equator of
J2000. 

There are two ISS coordinate systems in use: that officially used on
the Cassini Project to describe camera orientation (X_cm, Y_cm),
which is directly related to the readout directions of the CCD
samples and lines, and that in general use by imaging scientists,
(X_im, Y_im}, to describe images which are rotated from the target
being imaged. There is also the spacecraft coordinate system {X_s/c,
Y_s/c, Z_s/c}.  The cameras, and other instruments on the RSP, are
pointing in the Y_s/c direction. The positive Z_s/c axis points
towards the spacecraft s main engines; the -Z_s/c points towards the
High Gain Antenna; the +X_s/c axis is up. 

The CCD readout proceeds as follows. The bottom line of the CCD is
shifted down (i.e., toward the remote sensing palette, toward -X_s/c))
into a vacant 1-line serial register. This line is shifted then to the
left (in the +Z_s/c direction), pixel by pixel, to the signal chain
until the entire line is read out. The pixels are numbered by the
order in which they proceed to the signal chain. Thus, the first has
sample = X_cm = 1, the last has sample = X_cm = 1024. That is, the
readout proceeds in the X_cm direction. After this line is completely
read out, the next line is shifted down into the serial register and
read out, and so on until all 1024 lines have been shifted into the
register and then along to the signal chain. This results in the
following relationship between the spacecraft and the physical
ISS/CCD coordinate systems: (sample, line) = {+X_cm, +Y_cm} =
{-Z_s/c, +X_s/c}. 

The images of celestial bodies taken by the ISS are inverted up/down
and flipped left/right (i.e., rotated 180 degrees) by the optics in
both cameras.  The relationships between targets and inertial space,
as well as, the relationship between the target and the orientation of
the Cassini spacecraft, are all maintained through this rotation.
Thus, the image of a celestial target, as well as the image of the
spacecraft coordinate system in the focal plane, are rotated from
their physical orientations. A celestial target with its North pole
aligned with the spacecraft +X_s/c axis would appear inverted and
flipped on the CCD: that is, in the focal plane and display image
plane, the North pole of the target and the +X_s/c axis would point 
in the direction of decreasing line (-Y_cm and -Y_im);the targets 
western limb (or, astronomical East) and the -Z_s/c axis would point 
towards decreasing sample (-X_cm and -X_im). 

The Cassini C-Kernel contains information that is used by the 
Navigational Ancillary Information Facility (NAIF) SPICE toolkit to 
derive a matrix which transforms a vector in inertial coordinates 
into the spacecraft coordinate system (X_s/c, Y_s/c, Z_s/c). The 
Cassini Frames kernel describes a transformation matrix that 
transforms a vector from the camera coordinate system (X_cm, Y_cm, 
Z_cm) into the spacecraft frame. The proper combination of the two 
describes the orientation of the physical camera/CCD system relative 
to inertial space. To compute the correct orientation of inertial 
space, and the targets in it, in the image plane, which is where 
anyone handling an image will work, one must apply an additional 180 
degree rotation about the center of the image.  



Software
========
The image processing software used to create the EDR image files is
called VICAR (Video Image Communication And Retrieval).  VICAR is an
entire system of software, formats, and procedures for image storage
and processing and was developed and is maintained by JPL's MIPS. A 
full explanation of VICAR, its standards, software and reference
information can be found at the website: 

   http://www-mipl.jpl.nasa.gov/vicar.html

Information on tools for visualizing VICAR images can also be found 
there. For example, the  PDS-provided NASAview tool can be downloaded 
from the PDS site (http://pds.jpl.nasa.gov) and used to view the raw 
images.

The 'CALIBRATION' volume contains the calibrated image and 
calibration data files, calibration processing software files, 
algorithms, pre-flight ground calibration images and related 
calibration documentation. These files together will facilitate 
processing of the raw ISS images to higher-level calibrated image 
products. 

Specifically, the Cassini ISS Calibration software (CISSCAL) is
available in the EXTRAS directory on the calibration volume. It is
to be used in conjunction with the files contained in the CALIB
directory of the same volue. G-zipped TAR files containing the 
contents of both of these directories are also available to avoid any 
filename case issues that may arise when reading the DVD filesystems.

The contents of these volumes will continue to evolve and 
improve as the knowledge of the mission parameters improves. As a 
result, these volumes are released periodically with the latest 
available calibration files and software. These updates are described 
in the errata.txt file.



Media Format
============
This volume is being delivered to the Planetary Data System (PDS)
using DVD media.  Formats are based on standards for such products
established by the PDS [PDSSR1992].

Confidence Level Overview
=========================
The quality and completeness of the image data are determined in two
phases.  

Firstly, within IO/MIPS, images are constructed from the raw data 
stream using automated MIPS-provided VICAR software. Verification 
software is used to generate product and quality reports that detail 
what data/images are missing or incomplete.  Reconciliation, performed
by IO/MIPS, is done by taking multiple passes over the data to obtain 
the best possible image products.  For example, it may be necessary to
replay telemetry from the DSN,eliminate station overlap and keep the 
'best' available telemetry from either station and discard the 
remaining telemetry.

Secondly, the ISS team routinely performs comparisons of the images 
returned versus what images were planned. Missing/incomplete images 
are confirmed by looking at the product and quality reports (more 
discussion on these reports is found below in this document).  This 
is done as part of the ISS team's normal data usage and science
analysis. However, not all missing/incomplete products are verified 
by the ISS team. ISS OPS-generated scripts are additionally run by 
team members to ensure all images posted by IO/MIPS to the server are 
indeed received by ISS OPS and are maintained in the ISS archive 
database.

Keyword values are subject to inaccuracies; usage is cautioned. The 
accuracy of the index.tab keywords is dependent on the accuracy of 
the auto-navigation software and of the various SPICE kernels used 
to calculate the keywords, as discussed elsewhere in this document.

Those keywords that come directly from the image label are included 
verbatim and are as reliable as the sources of those keywords (i.e. 
MIPS in the telemetry processing phase utilizing spacecraft and camera
commanding software inputs).

The quality and completeness of the archive volumes generation process
are also determined by the accuracy of the archive generation software
written and employed by the ISS OPS team. This archive generation 
software divides the images into correctly sized blocks for recording 
on the archive volumes and then copies the appropriate image files 
and static information files prior to creating the archive volume 
disk. An interface to the software allows a human user to choose 
which volume to generate. The dynamic information files are updated 
as needed. These files are stored in a subversion file repository and 
are reviewed, before a ISS OPS-generated script is run on the volumes 
to check for obvious mistakes or omissions. Additional validation 
software is run by PDS to ensure the disk conforms to PDS standards. 



Review
======
Validation is considered to have 2 aspects: 1) quality scientific
usability and 2) technical compliance to PDS standards.  In order to
ensure PDS-compliant products, the archive volumes are validated by a
collaborative effort between the ISS/CICLOPS team, the Imaging and
Central Nodes of the PDS, and non-Cassini imaging scientists. The
ISS/CICLOPS team is responsible for producing PDS-compliant archive
volumes, while the PDS personnel are responsible for ensuring that the
archive volume(s) meet PDS standards. Validation is performed on each
volume by PDS using their validation tools. ISS/CICLOPS-developed
operational volume verification tools and procedures are also utilized
prior to delivery to PDS Imaging Node.  Together these verification
checks ensure PDS-compliant archive volumes.

Scientific usability is assessed through the ISS science team's
normal and routine use of the ISS datasets in their science analysis.
Additionally, imaging scientists not associated with the Cassini
project participate in the archive volume peer review process where
they verify the 'science' content of the dataset, the completeness
of the documentation, and the scientific validity (i.e., the
integrity and usability) of the datasets. 

Several reviews on sample archive volumes and directory files are
being performed prior to the start of volume production.  The peer
reviews of sample volumes is conducted by PDS.  These reviews serve
to validate the volume for proper structure, format, completeness,
and science usability. Any deficiencies in the reviewed archive
volume found are corrected and resolved. When all correctable errors
have been resolved, production of the archive volumes proceeds and
further validation is performed on a spot check basis by the both the
PDS and the ISS/CICLOPS team. Non- correctable errors (e.g., an error
in the downlink data file) is described in the evolving errata file,
errata.txt, included on each archive volume in the Root Directory.



Data Coverage and Quality
=========================

Product and Quality Reports
---------------------------
On the DATA volumes, the /document/report/ subdirectory contains
product and quality reports detailing the status of the downlink,
noting any missing or incomplete data products and the reason for the
discrepancy.  

NOTE: no product and quality reports were generated for images prior 
to SCLK 1431917000.

The quality report consists of one to three tables; depending on
whether there are missing or incomplete products.  The first table
lists information about all the predicted products for the time range
covered in the report.  This information includes the following:

  FILENAME: Filename of the product.
  OBSERVATION_ID: Planned observation from which product originated.
  SEQUENCE_NUMBER: The order the image appears in the observation. 
  COMMAND_FILE_NAME: Camera commanding file name for this product.   
  ORDER_NUMBER: The order the image appears in the IOI file.
  SCETSTOP - The image stop time in UTC.

If there are partial/incomplete products, a second table is given
describing those products.  This table consists of the following:

  FILENAME: Filename of the product.
  DATA_POL: Images truncated due to data policing.
  DSN_GAP: Images not received or partially received due to DSN issue.
  TRUNC_RO: Images truncated due to a short readout cycle.
  UNEXPLAINED: Incomplete images where the reason is unknown.

The following columns are used to explain incomplete images:

  'PARTIAL' means that an image was received, but is incomplete due to
   the problem at the top of that column.
  'NO' means that while the image is incomplete, it is not caused by
   the problem characterized by that column.
  'NULL' means that either analysis is not complete for that
   column/image, or an explanation has been given but further
   reconciliation will not be performed.

If there are missing products, a third table is given describing those
products.  This table consists of the following:

  SCLKSTOP: Spacecraft clock time of image stop time.
  CAMERA: Camera taking this image, NAC or WAC.
  TRIGGER: Trigger number issued to camera for this image.
  TRIGGERTIME: Spacecraft clock of trigger execution time.
  OFFSET: Offset of image time from trigger execution time.
  PEF: Predicted Events File for this product.
  IOI: Filename of camera commanding file (IOI) for this product..
  REASON: Reason for missing product if known.

The Product Report contains statistical product generation
information in paragraph form. The information includes the following:

  Number of FINAL and COMPLETE products
  Number of FINAL and INCOMPLETE products
  Number of incomplete products due to TRUNCATED READOUT
  Number of incomplete products due to DATA POLICING and DSN GAPS   
  Number of PRELIMINARY and COMPLETE products
  Number of PRELIMINARY and INCOMPLETE products
  Number of preliminary and incomplete products due to DATA POLICING
    and DSN GAPS
  Number of MISSING products
  Number of missing products due to DATA POLICING and due to DSN GAPS
  Number of UNPREDICTED products


A Quality and a Product report are generated for the NAC and WAC each
for a total of four reports covering the images on the volume.  The 
Product and Quality reports are labeled as follows:

  __.rpt

  Examples:
    COISS_2001_nac_quality.rpt
    COISS_2001_nac_product.rpt
    COISS_2001_wac_quality.rpt
    COISS_2001_wac_product.rpt


Truncated Images
----------------
There are three possible causes of image truncation in the ISS 
cameras: 1) data loss during downlink caused by problems with the DSN
(unrelated to the instrument), 2) even line truncation in lossless 
images in which individual lines are truncated, and 3) readout window
truncation in which the entire remainder of an image is lost. The
latter two, camera-related cases will be discussed here.

In the lossless compression case, there is a software requirement that
lossless data compress by a factor of two at minimum.  The camera 
handles this by making sure that the compressed data for an odd/even 
pair does not exceed the data for a single uncompressed line.  If it 
does, then the even line data is truncated such that the requirement 
is met, resulting in an image with an uneven right side, or 
occasionally, every other line completely missing.

The other kind of truncation, readout window truncation, occurs when 
the time it takes to readout an image is longer than the readout time 
allowed for it.  The camera stops transmitting data to the spacecraft 
when the time is up.

When an image is planned, one of the camera parameters to be set is
the Readout Index.  Each index corresponds to an allowed readout
window time.  There are 4 time windows and two cameras, resulting in 
16 possibile readout indices.  The readout window must be adjusted 
for telemetry rate, of which the possible settings are as follows:

     Telemetry Rates    Kbits/sec   Packets/sec
     ------------------------------------------
     S&ER5              356.6       48
     S&ER6              203.1       32
     S&ER3              182.8       24
     S&ER1              121.9       16
     S&ER2              60.9        8
    
For example, if you only look at the NAC times we have...

    NAC time in seconds for telemetry rate (packets/sec)
 
     Index      48pps  40pps  32pps  24pps 16pps 8pps
    --------------------------------------------------
     0-3         50     60     75    100   150   300
     4-7         25     30     38     50    75   150
     8-11        14     17     21     28    42    84
     12-15        6      7      9     12    18    36

You could have a truncated image if, for example, you have a 1x1 
uncompressed 12-bit image.  The camera generates 2277 packets and at 
24 packets per second takes about 95 seconds to readout.  If you had 
chosen a readout index from 4 though 7, or 50 seconds, then the 
camera would only be half-way through the data when its readout 
window was up and the resulting image would be partial.  So if you do 
not want truncation in this case, you must choose a readout index 
between 0 and 3.  This also limits how quickly you can take images.  
One might want to image more quickly and accept the image truncation.

It gets more complicated when images are read out in a compressed 
mode.  There the amount of data to be transmitted from camera to 
spacecraft depends on how well it compresses (its compression ratio).
Say you have a 1x1 12bit lossless image and you expect 5:1 
compression.  You would expect 461 packets and a readout time of 19.5 
seconds, so ISSPT chooses readout index 8 (28 seconds).  Now say the 
data was less compressible than you expected and only compressed at 
3:1.  The number of packets was actually 764 with a readout time of 
32 seconds.  The camera will stop at 28 seconds and you will not get 
the last 1/8 of the image.


ISS Lossy Compression Camera Bug Anomaly
----------------------------------------
An anomaly in the NAC and WAC camera software (Flight Software Version
1.3) was discovered in April of 2004.  This machine error is caused by
the retrieval of extended and overclocked pixels in images in LOSSY
compression mode.  A fix was executed in September of 2004 to correct
the problem.  A significant number of images were lost due to this bug
between the SCLK times 1462417483 thru 1481784349.  These missing
images are noted in the quality reports with the ISA number listed in
the 'REASON' column.  Cassini Incident Surprise Anomaly reports
Z83951, Z83931 and Z84199 were filed to document the problem. These
will be accessible only to operations personnel during the mission,
and are listed here for convenience.


NAC Haze Anomaly of 2001
------------------------
In May 2001 (Day 150), in NAC images taken of the Pleiades, a diffuse
circular halo appeared around the central peak of the image of Maia;
WAC images were not likewise degraded.  The apparent cause of this
anomaly was the resumption of normally scheduled decontamination
cycles after a 13-month hiatus.  Additionally conservative
decontamination cycles were performed and the haze disappeared
leaving the point response function of NAC within pre-anomaly limits.
See ISA #Z71910 for more detailed information on this NAC Haze 
Anomaly. 


Horizontal Banding
------------------
Both NAC and WAC images exhibit a low amplitude, coherent noise
characterized by horizontal banding with significant power
concentrated in a few spatial frequencies. The spatial frequencies
present in the images depend on the read out rate from the CCD. The
cameras did not show this problem until they were connected to the
spacecraft in the Spacecraft Assembly Facility. The pattern is not
fixed on the chip and is highly correlated with the overclocked pixel
value, indicating a fluctuation in the video bias level of the CCD.
The changing amplitude of the banding (measured in DN) in various
gain states is consistent with a constant amplitude in electrons; the
dependence of the frequency content on read out rate is consistent
with a constant temporal frequency. The source is unknown but is
likely a ground loop somewhere on the spacecraft.

Measurements indicate that the banding in the NAC has an amplitude of
~2.5 DN in the 12 e-/DN gain state (Gain 3); Fourier analysis shows
mainly two frequency components, with the secondary peak having 1/3
the power of the main peak. After correction for the CCD readout
rate, the main peak occurs at 2.1 Hz; the secondary peak at 2.5 Hz.
This produces a beating pattern with a combined frequency of 0.4 Hz.
In the WAC, the amplitude is much smaller (~ 0.5 DN for the 12 e-/DN
(Gain 3) state), with a dominant read-out corrected frequency of 4.0
Hz; two smaller peaks of 1/10th the power occur at 1.9 Hz and 5.9 Hz.
Calibration software being developed by the Imaging Team and within
the Cassini Imaging Central Laboratory for Operations will contain
algorithms designed to reduce this coherent noise in Cassini images
without unacceptable damage to the image data themselves.


Vertical Banding
----------------
Irregular vertical banding is another type of coherent noise that has
been seen in many images; it seems to be absent in images that are
read out in telemetry mode S&ER5 (366 kb/sec). The source of the
banding is presently unknown.



Limitations
===========

Geometric Accuracy
------------------
Software was developed by ISS/CICLOPS to calculate a large set of
geometrical quantities for each image provided in the index.tab file,
along with the keywords from the EDR PDS detached label.  These
geometrical quantities were computed using the most recent spacecraft
position and orientation kernels.  And, in cases where the
auto-navigation software was successful for an image, the Autonav
c-kernel was used instead of the reconstructed c-kernel provided by
the Attitude Control Subsystem (ACS).

The accuracy of the geometrical calculations is dependent on the
accuracy of the kernels provided to CICLOPS and the correctness of
the CICLOPS software.  In order to validate the correctness of the
software, representative random set of sample images were chosen and
the results thoroughly inspected and verified for correctness. 
Additionally, the data has been used and verified through normal
science analysis throughout the mission.  However, there is a small
chance that some special cases may produce inaccurate results.

Which SPICE kernels were used by the software is indicated in the
'Spice_Product_ID' keyword found in the index.tab file.  In some
cases, spacecraft pointing information is not always available due to
gaps in the c-kernel timeline.  In these cases, no calculations are
performed on these images, and thus some keywords may be set to
'NULL'.  Unknown, null, or not-applicable keyword values are
indicated as such according to current PDS standard values assigned
for UNK, NULL, and N/A respectively.

The index.lbl file contains the necessary information for interpreting
the index.tab file, including keyword names, data types, start bytes,
number of bytes, formats, and definitions.