Central Site Product Display (CSPD) system has been developed by Space and Naval Warfare Systems Command (SPAWAR) for disseminating a whole range of weather and oceanographic information to a variety of clients afleet or ashore. The clients (not necessarily related to the Navy) can request/receive data via serial (dial-up), Internet and VSAT connections. The information being served includes pressures, temperatures and wind directions on and above the surface, barometric heights, temperatures on the ocean surface and at specific depths, precipitation, primary observational data (weather reports), storm warnings, and a number of satellite images of different kind (IR, Visual, DMSP). The satellite images are usually 512x512 or 1024x1024 8-bit graylevel pictures.
CSPD is being developed upon the foundation of a very popular software system NODDS built by the Fleet Numerical and Meteorology Center (FNMOC) at Monterey, CA. NODDS has been in operation for more than 4 years. The server runs on a Cyber mainframe. It was written in FORTRAN with modules dating as far back as 1987. The client portion of NODDS was written in QuickBASIC for PC-DOS. The hardware base of the old system is clearly in need of updating, so is the software. The new CSPD server has to work on modern-day workstations (HP 9000, Sun SPARC, Concurrent's MAXION RISCstation) while the clients are to run on almost any platform: UNIX workstations, Macintosh and PC computers. Furthermore, there is a clear need to expand the system to include more, specialized weather products, to improve display of received information, and decrease communication time. Improving satellite imagery communication is of special priority, especially as far as flexibility of requesting and compressing images is concerned. The new system should allow the user to browse and request all available satellite imagery (rather than a few pre-selected pictures), to choose a compression algorithm and its parameters, and evaluate anticipated image degradation when a lossy compression is selected. The user should also be able to specify non-uniform compression of certain areas/features which he considers particularly important. Again, the rationale for using the compression is to reduce the communication time.
Computer Information Science, Inc. has been working on this project as one of the contractors. CIS is solely responsible for handling of satellite imagery within CSPD. We have written all software to compress/decompress satellite images using technology developed at CIS, as well as the code to convert satellite imagery from DEF to TIFF formats, to view images under CSPD and standalone, and to catalog imagery. We have also completely re-written the server part of CSPD in C++, and perform its maintenance and enhancement.
The current CSPD system is of the client-server type, though there are capabilities for a broadcast-type dissemination. The overall functionality of the system can be represented by the following diagram:
To formulate a request, the user
Whenever the server comes across a request for a satellite image, it queries the database to see if an image of the corresponding type (IR, visual) covering a specifies area (and valid for a specific period of time) is present in the database. If the image exists, the server obtains the name of the corresponding TIFF file and launches a compressor to compress the file according to the parameters specified in the request. If the compression was succesful, the resulting binary file is included in the return packet. Otherwise the server sends a message detailing the error (as a matter of fact, a stderr produced by the compressor).
When the client receives the reply, it unpacks and preprocess it. At this time, the client runs the decompressor, which decodes the received binary file into a PGM file. The latter is used by a display module to show the picture, and, possibly, lay temperature, pressure, etc isoplots and other information over the satellite picture.
Note, the compressor and decompressor are separately compiled and run executables, which are launched (spawned) whenever there is a need to encode/decode image data. The modules are available for a variety of platforms, and rather versatile: they support very simple and unified interface. The fact that request/reply parsing and compression/decompression is performed by separate executables has several advantages. For one thing, one can modify the compression module (say, by adding more sophisticated compression techniques) without the need to recompile/relink the client or server executables. Moreover, the compressor can be run by programs other than the CSPD server, as the functionality it provides - image compression - can be used in some other contexts, say, within WWW environments.
All satellite images are compressed for transmission, with the compression method and parameters specified in the request. When a satellite product is first selected by the user, the request contains some "default" compression specifications. It's the compression manager that lets the user customize the default settings. Thus the place of the compression manager can be illustrated by the following chart
The compression manager allows interactive selection of a compression method and its parameters. Note, the compression is almost always lossy. To give the user an idea how well the delivered image would look like and whether important features the user is looking for would be preserved, the compression manager loads up some (relatively small) sample image and displays it along with the compressed and decompressed picture, using the parameters the user has set up. Here's a snapshot of the component manager screen
The new version supports non-uniform compression as well.
At present, the compression manager implements a few variants of a modified Laplacian pyramid compression method (multi-resolutional analysis with overcomplete frames) discussed in papers presented at Data Compression Conferences
The very nature of environmental images, or any image for that matter, suggests that not every detail of the picture is equally important to the observer. For example, the area of the hurricane eye on a satellite image should be of high resolution, while the tight cloud cover of the hurricane body is less informative and may be rendered with a lower resolution, though it cannot be completely discarded. In disseminating the weather information to ships, a meteorologist at a particular ship needs very accurate data on cloud cover, wind direction, temperature, etc. just in the vicinity of his ship. The information about what is going on outside that small area is used for prognosis and does not have to be of very high precision. Accordingly, the amount of loss and inaccuracy that can be tolerated during the communication varies not only from one user to another but also from one region of the image to another. This raises the problem of a non-uniform, lossy compression, i.e., compression where the loss varies with the location/features/frequencies, etc., and tailoring such compression to a particular user and circumstances. Preserving the information during compression to the extent the user needs, but not more, helps to drastically reduce the amount of data that has to be transmitted.
At present, CSPD supports non-uniform compression within a single rectangular region. The compression manager can be used to select the region, assign a degree of importance to it, and see the effect of the compression on a sample image.
Note that the compression ratio shown on the picture is significantly underestimated. The sample image is subsampled to be as small as 128x128. It's well known that smaller images are tougher to compress. In our experience, when the same method applied to a full-size 512x512 satellite image, the compression ratio would be at least 4 times as much.
The new version of the CSPD clients and server is being phased in. However, the system, and especially its satellite imagery delivery part is under further development. The challenges here are