
Image Header

The first 256 bytes in an IM file contain the Image Header. The format of this 
header may change during experimentation, but it will always be a constant 256 
bytes long. These bytes can either be discarded or interpreted according to 
the following data structure:

struct CCDH_TAG {
        time_t start_time;
        time_t take_time;
        unsigned long image_number;
        unsigned long retries;
        unsigned long set_image_num;
        unsigned char integration;
        unsigned char gain;
        unsigned char unused[233];
        unsigned char version;  
} ccdh;

(Multi-byte values are stored least-significant byte first. time_t is four 
bytes counting the number of seconds since 1/1/80. long is four bytes. char is 
one byte. There are no slack bytes within the structure.)

start_time      is the scheduled time for the picture.
take_time       is the time that the picture was actually taken.
image_number    is the image number (as used in the IMxxxx file name).
retries         currently unused, will be set by adaptive exposure software to 
                show how many images were discarded.
set_image_num   not zero if command station was re-synchronising image 
                numbers.
integration     zero is the longest integration, with increasing numbers 
                indicating shorter integration times. The range of 
                integration times is from 20 msec to 2 msec.
gain            is two 4-bit numbers. The least-significant nibble sets the 
                low voltage threshold of the ADC, and the most significant 
                nibble sets the high voltage threshold. Between these two 
                thresholds 256 pixel values will be assigned. Changing the 
                values can expand or compress the camera's range to better 
                fit a particular scene.
unused          is space reserved for future use
version         is the last byte of the header. The current version is 0x80. 
                We will attempt to make future headers upwardly compatible 
                with version 0x80, by assigning meaning to currently 
                unused bytes. 
 
CCD Data 

Once the Image Header has been removed, only the CCD Data remains. This is the 
contents of the CCD, stored as a sequence of horizontal scan lines. 
Unfortunately, the CCD Data is not a simple raster image. Instead, it is 
divided into three sections: the 288 even lines, followed by 355 bytes which 
must be discarded, followed by the 288 odd lines. Each line is made up of 611 
pixels.

        Line 0
        Line 2
        Line 4
        ...
        Line 574
        Discard 355 bytes
        Line 1
        Line 3
        ...
        Line 575

When the image is displayed, the lines should be interleaved as follows, from 
the top of the image:

        Line 0
        Line 1
        Line 2
        ...
        Line 575

With the lines interleaved correctly, the image can be treated as a two 
dimensional array of 576 lines by 611 pixels. This is a raster image, which 
can be displayed on your screen or used as input to further image processing 
and format-changing programs.


DISPLAYING UO-22 IMAGES

A relatively high quality graphics system is needed to display the entire UO-
22 CCD image. In particular, the system should display 64 or more shades of 
grey. For MS-DOS users, this means at least a VGA adapter, and a Super VGA 
with 800 X 600 X 256 is much better.  Mapping the image to fewer grey levels 
will obscure the interesting detail in the pictures. Of course, it is best to 
have the full image on the screen, but if you have to trade off resolution 
against grey levels, go with the latter.

Users have taken two approaches to image display. Some have converted the 
raster array to the standard Graphics Interchange Format (.GIF) and displayed 
the image with public-domain, shareware or commercial GIF viewing programs. 
Others have written their own programs to manipulate and display the raster 
image. Each approach has advantages and disadvantages.

The .GIF format is popular, and .GIF viewers are available for most computers 
- from Sun workstations to PCs. Once someone has converted one of UO-22's 
images to .GIF format, the image can be widely distributed and viewed. GIF 
copies of the best UO-22 images frequently show up on the UO-14 mailbox, 
Compuserve, and the Internet. Some GIF viewers provide flexible contrast 
control, stretching, and image enhancement. Unfortunately, others are 
extremely simple and cope disappointingly with the wide dynamic range of the 
UO-22 pictures. Some sources of shareware .GIF viewers and utilities are 
listed at the end of this paper.

Writing your own display program is rewarding, but time consuming. It gives 
you the best control over the finished image, allows you to get the most from 
your particular computer and display, and educates you. The best current 
example of this approach is DISPLAY4.EXE by Colin, VK5HI, which works on IBMs. 
This program is distributed as freeware, and usually available on the UO-14 
mailbox.


INTERPRETING AND ENHANCING IMAGES

Once you have displayed an image, you have to interpret it. In some cases, 
geographical features will be so stunning that identification will be obvious. 
Usually, however, some contrast enhancement will be needed to bring your 
display's 64 grey shades into the most interesting part of the picture, then 
you have to get out a tracking program and an atlas to identify Earth 
features. 

Some fixed features will become familiar to you as you experiment with UO-22 
images. The two bands extending diagonally into the frame are the satellite's 
antennas. If the image shows a large body of water, you may see the sun's 
reflection making the water brighter than the land (a reversal of the normal 
contrast). Sometimes (less and less frequently), you may see the limb of the 
Earth, indicating that the UO-22 attitude control routines are out of tune. 
Towards the edges of the picture - and particularly when these coincide with 
the limb of the Earth - geographical  distortions become noticeable. Of 
course, since UO-22 spins around its Earth-pointing axis, North won't always 
be to the top of the image!

In general, picture quality is excellent, as shown by the photos accompanying 
this paper. Contrast between land and sea is high, and the 2-km resolution can 
be confirmed by examining coastlines and islands. Identifying scenes without 
reference to satellite tracking software can stretch one's geographical 
knowledge, but once the sub-satellite point and angle of rotation have been 
determined, prominent features should be easily located with the aid of an 
atlas.

After looking at raw images, you'll probably want to try some image 
processing. If you write your own display program, you can implement your own 
image processing algorithms and tightly integrate processing and display. If 
you use the GIF route, you can still perform processing on the raster array 
before conversion to GIF. In either case, your first job will be to get rid of 
known anomalies in the UO-22 images.

Duplicated DASH Packets

For a combination of reasons, the communications protocol on the DASH link 
sometimes duplicates packets between the Transputer and the 80C186 OBC. This 
causes a 1-packet-long portion of the Image Header or CCD Data to be repeated. 
On early images, these repeated sections were 254 bytes long; the packet 
length was recently changed to 110 bytes. After removing the PACSAT File 
Header, you can look for any 110-byte repeated blocks and remove them. (Be 
careful not to throw out areas of uniform pixel value; if all the pixels in a 
block have the same value, the block isn't a good candidate for removal.) 
Fortunately, the repeated packet problem can be solved through modifications 
to OBC and Transputer software. It is on the decrease, and shouldn't be with 
us for much longer.

Pre-Image Slack

When the pixels are clocked from the CCD sensor into the image memory, some 
initial non-image bytes are generated by the chip-set and stored by the DMA 
hardware. If these bytes are not removed, they will show up at the beginning 
of line 0; the end of line 0 will show up at the beginning of line 2, and so 
on, down the image. Because this is a constant offset, the image will not be 
distorted, but will appear to have "rolled" horizontally. Discarding 48 bytes 
after the 256-byte header moves the image to the left hand side of the screen, 
with all of the unused pixels showing up at the right hand end of each line.


Pixel Dropout

Because a relatively slow, low-power ADC was used in the Camera Head, the ADC 
cannot always follow the input video signal correctly. When the ADC cannot 
keep up, invalid pixel values are stored in the image memory. These pixel 
dropouts are usually on the right-hand edge of bright objects, and are either 
very bright or very dark pixels. Pixel dropouts can be removed with a "median 
filter" applied to each line. This filter examines a pixel, and if that pixel 
is sufficiently different from its neighbours, sets the pixel to the median 
value of its neighbors. For best results, the filter is applied from right to 
left. It is worth experimenting with the threshold for droupout detection and 
with schemes for identifying two immediately-adjacent dropouts.

The White Line

On all images produced by the UO-22 CCD camera,  two adjacent lines are 
significantly brighter than their neighbours, creating a horizontal white line 
across the image. A power surge in the CCD chip set during image capture 
causes this. Roughly speaking, a constant value has been added to all of the 
pixels in the line, and various schemes for removing this offset have been 
attempted. First, locate the white lines by searching for a discontinuity in 
the black reference band. Then calculate the average pixel value in each white 
line and in the last preceding "normal" line. Finally, calculate the 
difference between the "white line average" and the "normal line average" and 
subtract this value from each pixel in the white line. This is not entirely 
successful, but does reduce the impact of the horizontal stripe.

Low-Level Noise

It is inevitable that some noise creeps into the analogue signals as they are 
amplified and sampled in the Camera Head. There are no simple filters to 
eliminate this noise, which is only a bit or two in amplitude. Beware of this 
noise when using extreme contrast enhancement, and when viewing images with 
very low exposure. 
