Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!jarthur!nntp-server.caltech.edu!lo-fan.caltech.edu!sns
From: sns@lo-fan.caltech.edu (Sam Southard Jr.)
Newsgroups: comp.compression
Subject: Atronomical data compression
Keywords: Spectra, Keck
Message-ID: <1991Mar23.013557.28151@nntp-server.caltech.edu>
Date: 23 Mar 91 01:35:57 GMT
Sender: news@nntp-server.caltech.edu
Reply-To: sns@deimos.caltech.edu (Sam Southard Jr.)
Organization: Caltech Astronomy Department
Lines: 32

I have a topic/question that should be suitable for this newsgroup.  I am a
software engineer working on the software for the Keck Telescope (the new 10m
in Hawaii).  One of the things I am doing is taking the data from the CCD to
a VMEbus controller crate (Sun 1E running VxWorks) and from there to a
Sun 4/470 over the ethernet.

Each image can be up to 4096x4096 pixels (a 2x2 mosaic of 2048x2048 CCDs), each
pixel being 16 bits.  Obviously, if this kind of data is going over the
Ethernet, we want to compress it as much as possible.

The compression I can do is restricted in a few ways, including:

	1) It can not take much CPU, since some real-time control of the
		instrument is being done by the same VxWorks box.  Much is a
		term that is yet to be defined.
	2) Simple schemes like counting the number of times a pixel occurs
		in a row and comressing that to a single occurance and a count
		are out, because there is a random element to the data (cosmic
		rays, etc.), which means that it is unlikely that there will be
		many cases where this method would compress the data.

I have thought of a few methods which I can try, but I am interested in looking
at as many ways as possible.  I have lots of actual data to try out various
compression methods, and a reasonable amount of CPU to burn in choosing the
algorithm (or two or three) which will actualyl be used.

Does anyone have any suggestiongs?

-- 

Sam Southard, Jr.
{sns@deimos.caltech.edu|{backbone}!cit-vax!deimos!sns}