Data Set Overview : This data set contains science, calibration and checkout images acquired by the OSIRIS Narrow Angle Camera system on the Rosetta mission. The images were acquired during the escort mission phase covering the period from 2015-07-28 to 2015-08-25. The images are CODMAC level 2. The ESC2 mission phase covers the escort of comet 67P/ Churyumov- Gerasimenko after the landing of Philae Essential Reading ----------------- The following documents, located on the dataset DOCUMENT folder, are essential for the understanding and interpretation of this data set: OSIRIS_SSR.PDF: Gives an overview of the science goals of the OSIRIS instrument and an overview of the instrument hardware. OSIRIS_SIS.PDF: Describes the OSIRIS PDS header Related Data Sets ----------------- The following PDS data sets are related: RO-C-OSINAC-3-ESC3-67PCHURYUMOV-M19-V1.0 RO-C-OSIWAC-2-ESC3-67PCHURYUMOV-M19-V1.0 RO-C-OSIWAC-3-ESC3-67PCHURYUMOV-M19-V1.0 Processing : The PDS images in this data set were generated using the OSIRIS telemetry processing facility at the Max Planck Institute for Solarsystem Research from the raw telemetry stream sent down from the rosetta spacecraft. The decoded telemetry stream was initially saved as Level 1 PDS images (raw telemetry header and raw image data). These raw Level 1 image files were then passed through a level 1 to level 2 processing pipeline. This pipeline converts the raw telemetry header into calibrated physical values and appends additional information collected from external data sources (SPICE, sequence library ...) Given that the calibration database is considered a single product even if it can be used separately to calibrate images from the NAC and the WAC, it is delivered in its entirety on the NAC and WAC datasets. Data : CCD Images ---------- The OSIRIS images are stored as PDS images (meaning data files with embedded label where the image data is stored using an 'IMAGE' PDS object. The raw image data is stored using a 16 bit unsigned integer low endian format. The pixel value 0 is used to indicate missing data (lost packets). Compression ----------- The OSIRIS flight software has the capability to compress the image data before transmission to ground using a number of compression algorithms and filtering schemes. OSIRIS implements a data segmentation scheme to decrease sensitivity to data loss during transmission. Each image is separated into blocks with a maximum size of 512x512 pixels. Each of these blocks are processed and compressed individually. All information about compression and post-processing is located in the SR_COMPRESSION group in the OSIRIS image headers. Each member of this group is a vector containg a data entry for each image segment used to generate the final image. The pixel coordinates of the segmentation boundaries can be found using the SEGMENT_[X,Y,W,H] fields. The name of the algorithm used to encode the image data is located in the ENCODING field. The following encoding algorithms are supported: NONE - No Compression SPIHT_D24 - Early implementation of the SPIHT algorithm that divided all data values by 24 before encoding SPIHT_LIFT - SPIHT compression with LIFT filtering SPIHT_TAP - SPIHT compression with TAP filtering SQRT_16to8 - Squarerooting followied by 16 to 8 bit reduction PACK9BIT - 16 to 9 bit truncation The effective compression ratio achieved by the encoder is stored in the COMPRESSION_RATIO member. If the encoding step was performed without information loss then the LOSSLESS_FLAG member is TRUE else FALSE. Please note that LOSSLESS_FLAG only refers to the encoding step. LOSSLESS_FLAG can be TRUE even is a lossy filtering step has been performed. OSIRIS can also perform a pixel averaging step. The pixel averaging box size can be found in the PIXEL_AVERAGING_WIDTH and PIXEL_AVERAGING_HEIGHT members. To increase the performance of the SPIHT compressor OSIRIS implements a number of optional pre encoding filtering steps. The following filtering are possible: 1. A Gauss 5x5 convolution smooth filter 2. A Sqrt filtering step performing the transformation I_Out : sqrt(I * gain) The type of gauss smooth filter used can be found in SMOOTH_FILTER_ID with the values 'NONE' 'CONVOL_KERNEL_1' (0.5 FWHM) 'CONVOL_KERNEL_2' (0.8 FWHM) 'CONVOL_KERNEL_3' (1.0 FWHM) If the sqrt filter has been used the SQRT_FILTER_FLAG is set to TRUE and the used gain value is stored in the SQRT_FILTER_GAIN field. Target Name and Description --------------------------- The TARGET_NAME and TARGET_TYPE keywords in the data labels are automatically set by the processing software using the following hierarchal rules: 1. The closest solar system object within 1 deg of the camera boresight (using a selected database of allowed targets). All solar system objects are given using a SPICE compatible object name. 2. Any deep sky within 1 deg of the camera boresight (using a selected database of allowed targets). 3. A number of special images which are acquired with the camera front door closed are named: Name Type Description --------------------------------------------------- CHECKOUT N/A Shutter Test Images CALIBRATION CALIBRATION Internal reference flatfield DARK CALIBRATION Dark/Bias current measurement 4. TARGET_NAME : UNK if no object was found matching the above criteria. Displaying the OSIRIS images ---------------------------- The OSIRIS images are stored using the following format ----------------- | header | ----------------- |pixel (0,0) | | | | | | | | | | pixel(w,h)| ----------------- this structure means that the image (as is typical for PDS images) needs to be vertically flipped to be correctly displayed on a typical computer screen. On top of this the images from the narrow angle camera requires a horizontal flip to be shown with in the same geometry as the wide angle camera images. To summarize: OSINAC images: flip horizontally + flip vertically OSIWAC images: flip vertically Using these transformations the x-image axis is roughly aligned with the spacecraft y axis and the y-image axis is roughly aligned with the spacecraft x-axis. File Naming Convention ---------------------- The OSIRIS image files use the following filenaming convention: CYYYYMMDDTHHMMSSUUUFFLIFAB.IMG where: C is either N NAC (narrow angle camera) W NAC (wide angle camera) YYYY is the year of acquisition MM is the month of acquisition DD is the day of acquisition T is the letter T HH is the hour of acquisition MM is the minute of acquisition SS is the second of acquisition UUU is the milli-second of acquisition FF is the image file type: the following filetypes are possible: ID Image Data (Normal images) TH Thumbnail version of the image (Highly compression version transmitted immidiately) PA Amplifier A pre pixels (cal data) PB Amplifier B pre pixels (cal data) OL Overclocked lines (cal data) L is the processing level of the image I is the instance id if the image (multiple transmissions of an image will be reflected in this number incrementing) F is the letter F A is the position of the filter wheel #1 B is the position of the filter wheel #2 .IMG is the file extension Example: W20040923T071606570ID12F12.img Is a WAC image acquired at 2004-09-23 at 07:16:06.657 UTC The file contains CCD image data (image type ID) with raw image data (level 1) and the image represents the 2 transmission of the image data. The image was acquired using the filter combination (1,2) : Hole+Red for the WAC. Note! The filename contains an approximate time of acquisition. This time value is only used to uniquely identify the image and should not be used for any calculation needing high precision. The time value in the filename has not been corrected for onboard clock drift and leap seconds. The best possible knowledge about the time of acquisition can be found in the header label START_TIME Parameters : Data Units ---------- The images in this dataset contains values in raw Data Number (DN) (uncalibrated) Time-Related Keywords --------------------- All time-related keywords in the data labels are based on the clock inside the OSIRIS processing unit. This time is periodically synchronized with the Rosetta spacecraft clock. The conversion into real time (UTC) has been calculated using the official clock drift kernels maintained by the spacecraft operations center and leap second list maintained by the IERS. Ancillary Data : Geometric parameters included in the data labels were computed using the N64 release of the SPICE toolkit and the most up to date versions of the SPICE kernels available at the time of processing. The filenames of the SPICE kernels used for the calculations can be found in the SPICE_FILE_NAME field. For high presition work the header geometry information should be ignored in favour of direct calculation using the most up to date kernels. Coordinate System : OSIRIS uses the Earth Mean Equator and Vernal Equinox of J2000 (EME J2000) as reference inertial coordinate system. Geometric parameters provided in the data labels were computed at the epoch specified by START_TIME, except for the target-to-sun parameters, which were calculated for the time when the light left the sun . The OSIRIS label contains two groups defining usefull coordinate system transformation: 1. SC_COORDINATE_SYSTEM Contains the offset and rotation needed to transform from EME J2000 to the Rosetta spacecraft coordinate system (Commong for all Rosetta payload elements) 2. CAMERA_COORDINATE_SYSTEM Contains the offset and rotation needed to transform from the Rosetta spacecraft coordinate system to the camera frame coordinate system of the NAC camera.

Confidence Level Overview : The OSIRIS cameras are intended to deliver the highest resolution images ever acquired of a cometary nucleus (~4 cm per pixel) with the highest possible spectro photometric quality possible (NAC). The OSIRIS cameras are intended to deliver high quality line emission maps of the inner coma (WAC) Review : The OSIRIS dataset will be reviewed first internally by the Rosetta project followed by a formal review by the PSA before release to the public. Data Coverage and Quality : The OSIRIS EDR data records in the CODMAC level 2 data sets does not contain any estimate of the data quality. Quality information is embedded (on a per pixel level) in the calibrated CODMAC level 3 data sets. The header field DATA_QUALITY_ID exists for legacy reasons but does not contain any usefull information.