Xref: utzoo comp.windows.x:34262 comp.graphics.visualization:386 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!dcl-cs!aber-cs!gabriel!kas From: kas@cs.aber.ac.uk (Kevin Sharp) Newsgroups: comp.windows.x,comp.graphics.visualization Subject: Re: [xpert...] free video movies Message-ID: Date: 19 Mar 91 15:12:24 GMT References: <1991Mar15.183911.18550@kodak.kodak.com> <1991Mar16.235110.14802@ox.com> Sender: kas@aber-cs.UUCP Followup-To: comp.windows.x,comp.graphics.visualization Organization: Robotics Research Group, UCW, Aberystwyth Lines: 55 In-reply-to: tiefel@sunshine.Kodak.COM's message of 16 Mar 91 23:51:10 GMT >>>>> On 16 Mar 91 23:51:10 GMT, tiefel@sunshine.Kodak.COM (Lenny Tiefel) said: Lenny> The Eastman Kodak Research Laboratories will be generating Lenny> video movie sequences and providing these freely through Lenny> anonymous ftp within the next three months. (The details Lenny> will be given later.) Lenny> So, to provide the world's research community with the most Lenny> useful images, consider the following questions: Lenny> What image format would be most useful? Lenny> Example: gif None of popular image formats would be suitable. What you need is a movie format. One obvious thing you do in a movie format is not to replicate data in consecutive frames. This can have the advantage of both reducing the data size and increasing the speed at which it can be played. For example using an encoding where only changes in the image are recorded you don't redraw those bits that don't change. This fits in very tidily with a run length encoding scheme. I have an idea that if for the first image in the sequence you ... * take 24bit image as 8 bits red, 8 bits green, and 8 bits blue * apply run length encoding independently to each bit throughout the image ... then for subsequent frames you take the difference from the previous frame and encode it in the same way you'll end up with efficient compression for photo-realistic images. The basis being that on the whole the RGB values of such images change slowly over the image and over time. Possible enhancements ... * use a Grey code (one where only a single bit changes between consequetive codes in sequence) instead of a binary sequence for the RGB values. * use chromience and luminance instead of RGB * use variable length words throughout. I'd be interested to hear how this might work with or compare against JPEG or similar industry standards. Comments please. -- -- Kevin Sharp, UUCP : {WALES}!ukc!aber-cs!kas Research Associate, JANET: kas@uk.ac.aber.cs AI and Robotics Research Group, PHONE: +44 970 622450 Department of Computer Science, University College of Wales, Aberystwyth, Dyfed, UK. SY23 3BZ