wayneck@tekig5.TEK.COM (Wayne Knapp) (07/11/88)
Can anyone point me to some infomation on compressing rgb images. At this
point I'm completely open to ideas. I have some ideas but would like to
know what others have tried before I go off the deep end. My end intent
is using the compressed images for animation, so fratal compression stuff
is out as is anything that takes huge amounts of processing.
Thank you,
Wayne Knappkppicott@violet.waterloo.edu (Dewey Duck) (07/13/88)
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. --- Kevin Picott, or in real life: UUCP: [uunet!]watmath!watcgl!kppicott *-NET: kppicott@watcgl.waterloo.{edu, ca, cdn} POST: Home School 516 Scarlett Crescent 350 Columbia Avenue, Unit 76 Burlington, Ontario Waterloo, Ontario L7L 5M2 N2J 4B6 (416) 637-1721 (519)
leo@philmds.UUCP (Leo de Wit) (07/16/88)
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.