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.