This page describes the structure of the imagery elements involved in building up a complete scan from a single channel of
Meteor LRPT data.

Starting with the basics, a single scan line is 1536 pixels long. Each pixel ends up being 8 bits in resolution. An image is
built up in a similar way to other polar orbiter imagers by laying down scan lines, one after the other, as they are observed
from below the spacecraft. The camera on board the spacecraft scans from left to right (across track) to capture a single
line Earth data from directly below the satellite. The forward motion of the satellite (along track) provides the positioning
for the next line. So, as the spacecraft moves along track and the camera is repeatedly scanning across track at the sub-
satellite point, a 'raster image' is built up. The spatial resolution around the centre of a line is about 4-5km, similar to APT,
and suffers the usual distortions towards the edges of the image. (These are caused by the Earth's curvature giving an
increasingly slanted view to the spacecraft, the further left or right of the sub-satellite point the camera is looking.)

The added complication over APT and the like is that the actual image data sent down in the LRPT datastream has been
compressed to meet bandwidth and data volume criteria. The compression technique is based on the JPEG compression
standard. The Metop documentation suggests that the data could be 10-12 bits. That would require the use of what is
known as the extended JPEG version that accomodates 12 bit data. Investigations so far have revealed that the baseline
JPEG standard with 8-bit resolution is all that is required by Meteor LRPT. This makes processing much simpler, as the
12-bit extensions are not all that well documented, or supported in available decoding software.

So, how can the JPEG compression standard be applied to a single scanline 1536x1 pixels in size? The answer is it is not.
The JPEG algorithm operates on a minimum of a 8 by 8 pixel square grid. This is known as a Minimum Coding Unit, or
MCU. Jpeg images are built up from arrays of these 8x8 MCUs. For LRPT then, we need to group together 'slabs' of 8
consecutive lines, forming an 1536x8 pixel block. In order to break the image up into manageable sized chunks and
provide some protection against noisy data, this block is then divided into 16 segments. These segments are 96 pixels
wide (and 8 pixels tall) and form individual JPEG encoded image 'tiles' that can be pieced together to form a complete
image of the pass. These tiles are built from a grid of twelve MCUs in a single row. The tile data is compressed in the
JPEG format BUT is not an individual JPEG picture as such. The tiles do not have all the JPEG header information
attached to each one - this is simply not necessary. The tables and other information such as image size are all previously
defined and therefore don't need to be sent, thus saving downlink bandwidth. A neat feature of JPEG is the ability to set
the quality and thus the amount of compression with a quality flag byte. This is used by the spacecraft to control the
downlink bitrate, specifically trying to keep it relatively constant whilst providing the maximum amount of resolution and
image reproduction. This quality flag byte is the only extra JPEG information that is sent with each image tile. The decoding
tables are predefined and are the standard default ones used in the original JPEG spec and also in the METOP
documentation. As stated earlier, the individual tile image size is 96x8 pixels and are single channel, or greyscale, pictures.
Armed with this information and the collected tile data you can go throught the JPEG de-compression algorithm and
recover the 96x8 pixels. Other information in the packet that the data arrived in combined with the time order of reception
allow you to put the tiles together to form the scanline blocks and ultimately the whole pass.

The following diagram shows how a scanline from a single channel of imager data is bundled up and compressed,
onboard the spacecraft, ready for transmission on the LRPT downlink.

BACK