Path: utzoo!attcan!uunet!mcvax!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.graphics
Subject: Re: compressing rgb images
Summary: Graphics package will be made available
Keywords: animation, compressing, raster display
Message-ID: <562@philmds.UUCP>
Date: 16 Jul 88 07:01:23 GMT
References: <2975@tekig5.TEK.COM> <7715@watdragon.waterloo.edu>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 36

In article <7715@watdragon.waterloo.edu> kppicott@violet.waterloo.edu (Kevin Picott) writes:
>In article <2975@tekig5.TEK.COM> wayneck@tekig5.TEK.COM (Wayne Knapp) writes:
>>
>>Can anyone point me to some infomation on compressing rgb images.  At this
>
>I'm also interested in a special class of these.  Those that are purely
>monochrome (foreground/background) and sparsely arranged (like those found
>in animation keyframes).  I am particularly interested to know if any one has
>done any work on spline-encoding.  Here, I use this term to mean converting a
>bitmap format into a series of splines representing component curves of the
>overall image.  The end use of such data would be real-time in-betweening of
>keyframes.  If the in-betweening is not possible, I would still like to know
>how to compress a reasonable number of image frames into a small amount of
>memory.

I'm working on a 3D graphics animation package for the Atari ST right
now (90 % ready 8-). Amongst matrix operations like multiplication,
rotation, translation etc. it will contain routines to compress and
expand image frames; both by storing end-point coordinates and by
storing the screen data in a compressed format. The former method is
useful if you have a fast line drawer (there is one too in the package)
because each line of the image has to be rebuild, the latter is useful
with many lines or curves or colours or whatever (an image that is complex
to build). Both methods can 'inbetween' as you call it if the number of
lines to draw is not too high (I've not searched for a limit yet).
Sources will be available on comp.sources.misc, probably within two
months from now (most C code, a bit MC-68000 assembler). The binaries
will go to comp.binaries.atari.st (a demo program and a library).
No fancy stuff like clipping, displaying surfaces , support of colours
and different drawing modes yet (although this could be added in a next
'release').

Of course I'm also interested in any other compression techniques that turn
up from this discussion.

     Leo.