CCSD3ZF0000100000001NJPL3IF0PDS200000001 = SFDU_LABEL
RECORD_TYPE = STREAM
SPACECRAFT_NAME = "GALILEO ORBITER"
OBJECT = TEXT
NOTE = "BAD DATA VALUE HEADER DESCRIPTION"
END_OBJECT
END
BAD DATA VALUE HEADER DESCRIPTION
The following memorandum describes the format and content of the bad data
value header of the Galileo SSI REDR and EDR images.
JET PROPULSION LABORATORY INTEROFFICE MEMORANDUM
384-91-3:GMY
May 14, 1991
To: Distribution
From: Gary Yagi
Subject: Tracking GLL SSI Bad-Data Values, Binary Label Design, Revision 2
Revision summary: Reed-Solomon overflow records are defined as a new bad
data type. These are encoded as line segments (CODE=2) with RECORD-ID=7.
References:
1) "Tracking GLL SSI Bad-Data Values, a Preliminary Design", G. Yagi,
April 3, 1989.
2) SSI Experiment Data Record, Galileo SIS 232-07.
3) "Galileo SSI UDR file format", Payam Zamani, 10 April 89.
4) "VICAR Run-Time Library Reference Manual", D. Stanfill, June 10, 88.
This memo defines the format and contents of the binary labels used to
store SSI bad-data values, as proposed in Reference 1.
There are two parts to the binary label: the binary header, and the binary
prefix (see Ref. 4, Sec. 2.1.2). The binary header precedes the image data
(as do the ASCII labels) and contains information which pertain to the entire
image. The binary prefix precedes each image line and contains information
specific to each line. Binary labels are created by adding the U_NLB and
U_NBB keywords to the XVOPEN call. Binary labels are accessed from a file
already containing them by adding the CONDITION, BINARY keywords to the
XVOPEN call. Note that since VICAR programs do not normally include these
keywords in their XVOPEN calls, binary labels are usually ignored and
disappear when new versions of an image are created. Binary labels were
originally designed to support the generation of Voyager EDRs.
The binary header consists of an arbitrary number of records. The first
record contains ancillary telemetry information and the image histogram
(Ref. 2). The remaining binary header records contain bad-data information,
stored as a sequence of "objects" in 16-bit integer format. The following
types of objects have been defined:
OBJECT TYPE CODE FORMAT
--------------- ---- --------------------------------------
Single pixels 1 line,sample
Line segments 2 line,starting-sample,number-of-samples
Column segments 3 sample,starting-line,number-of-lines
These objects are used to encode the following bad-data types:
BAD-DATA TYPE RECORD-ID CREATED BY:
-------------------- --------- -----------
Data drop-outs 3 GALSOS
Saturated pixels 4 GALSOS
Low-full-well pixels 5 GALSOS
Single-pixel spikes 6 ADESPIKE
Reed-Solomon overflow 7 GALSOS
Single-pixel spikes are stored as single pixels, data drop-outs, saturated
pixels, and Reed-Solomon overflow records are stored as line segments, and
low-full-well pixels as column segments.
Note: If a Reed-Solomon overflow occurs on a given line, it will cause
the line to pass through the R-S decoder uncorrected. For compressed image
data, all pixels to the right of the first bit error will be corrupted.
Since it is not possible to determine where this bit error occurs, the entire
line is flagged as bad.
Each record will be in 16-bit integer data format and will contain only one
type of object. The first three integers of each record contain the record
ID, object code (CODE), and the number of objects in the record (N), respec-
tively. The remainder of the record will contain a sequence of N objects.
The maximum number of objects which can be stored on a record is a function
of the EDR record length and object code. Full-frame and summation-mode EDRs
have record lengths of 1800 bytes and 1000 bytes, respectively:
FULL-FRAME SUMMATION-MOD
CODE MAX OBJECTS MAX OBJECTS
---- ----------- --------------
1 448 248
2 299 165
3 299 165
If more objects of a certain type exist, they are written on subsequent
records. The records are not necessarily written in any particular order,
although they must all precede the image line records.
Example 1: Let a binary header record contain the sequence of integers
6,1,3,211,104,322,111,401,233. The record contains single-pixel spikes (6)
encoded as single-pixels (1). There are three objects encoded as line-
sample coordinates: (211,104), (322,111), and (401,233).
Example 2: Let a binary header record contain the sequence of integers
4,2,2,110,216,105,789,420,381. The record contains saturated pixels (4)
encoded as line segments (2). There are two objects. The first line
segment is on line 110 and from sample 216 to 320. The second line
segment is on line 789 and from sample 420 to 800.
Example 3: Let a binary header record contain the sequence of integers
5,3,2,299,710,91,521,72,729. The record contains low-full-well pixels (5)
encoded as column segments (3). There are two objects. The first column
segment is on sample 299 and from lines 710 to 800. The second column
segment is on sample 521 and from lines 72 to 800.
The following is an example of a program which reads an image containing
bad-data information, does something with this information, and outputs
an image which does not contain any binary labels (all subroutines other
than XV routines are fictitious):
COMMON/HDRREC/RECORDID,CODE,NOBJECTS,SPIX(2,448) !Binary header record
INTEGER*2 RECORDID,CODE,NOBJECTS,SPIX
INTEGER*2 BUF(900),LSEG(3,299),CSEG(3,299)
EQUIVALENCE (BUF,RECORDID),(SPIX,LSEG,CSEG)
COMMON/IMGREC/LHDR(100),PIXELS(800) !Image line record
INTEGER*2 LHDR,PIXELS,LBUF(900)
EQUIVALENCE (LBUF,LHDR)
CALL XVUNIT(IUNIT,'INP',1,IND)
CALL XVOPEN(IUNIT,IND,'COND','BINARY')
CALL XVGET(IUNIT,IND,'NL',NL,'NS',NS,'NLB',NLB)
DO L=2,NLB !Loop through the binary header records
CALL XVREAD(IUNIT,BUF,IND,'LINE',L)
IF (CODE.EQ.1) CALL SINGLE_PIXEL(SPIX,RECORDID,NOBJECTS)
IF (CODE.EQ.2) CALL LINE_SEGMENT(LSEG,RECORDID,NOBJECTS)
IF (CODE.EQ.3) CALL COLUMN_SEGMENT(CSEG,RECORDID,NOBJECTS)
ENDDO
CALL XVUNIT(OUNIT,'OUT',1,IND)
CALL XVOPEN(OUNIT,IND,'OP','WRITE')
DO L=1,NL !Loop through each image line record
CALL XVREAD(IUNIT,LBUF,IND) !Read a line record
CALL PROCESS_LINE(PIXELS,NS) !Process the image line
CALL XVWRIT(OUNIT,PIXELS,IND) !Write the image line
ENDDO