From: David Woolley (david_at_djwhome.demon.co.uk)
Date: Wed Jan 15 2003 - 22:57:24 PST
> http://www3.sympatico.ca/stephane_dumas/CETI/
I've not looked at it from an ETI's point of view much yet, but from
a contemporary earthling's point of view the use of JPEG was a bad choice -
you only got away with it because you oversampled by a factor of 8, which
meant the Discrete Cosine Transform (the bit that gives the real compression
in JPEG) saw only all white or all black, so could do a lossless coding.
I would have used GIF or PNG and not oversampled (embed it in an image
element and let the browser scale it, saving transmission time and
avoiding a file that causes memory distress if you try to manipulate it).
The GIF is 20947 bytes and the PNG is 14809 bytes. The JPEG at this
scale was about 111K, showing how bad JPEG is for this sort of data.
(A PNG of the oversampled image is about 32K.)
As regards the ETI's view of the transmission, I wonder what you are
doing to ensure strong spectral components at the nominal carrier,
so they know that there is something to look at, and at the baud rate,
or half the baud rate, to improve their chances of recovering the
message.
I also wondered whether it was a good idea to use variable width symbols,
with variable starting offsets, as knowing where to look for symbols ought
to improve the signal to noise ratio.
The subscripts and superscripts are going to confuse an ETI that is
relying on all symbols being on a line. Consider, that at the limits of
usable signal to noise ratio, you will want to do an analogue match on the
complete symbol before trying to decide which symbol it is, so you may not
be able to see individual pixels.
This archive was generated by hypermail 2.1.2 : Wed Jan 15 2003 - 23:11:22 PST