kas@cs.aber.ac.uk (Kevin Sharp) (03/19/91)
>>>>> 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 3BZeachus@aries.mitre.org (Robert I. Eachus) (03/20/91)
In article <KAS.91Mar19151224@gabriel.cs.aber.ac.uk> kas@cs.aber.ac.uk (Kevin Sharp) writes:
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....
Sounds like you haven't heard of IFF (Interchange File Format). It
was originally proposed as a machine (and application) independant
structured file format for interchange of multimedia data. Deluxe
Paint (for the Amiga) was the first application to use it. It has
since become the format of choice on the Amiga, and is starting to
show up on several other platforms. Anyway, there are several ANIM
formats, most of which use differences from alternate video frames to
make double buffering easier, but differing in the compression method.
(Using the previous frame instead of the current frame allows a
simpler display algorithm: Only change some pixels in the frame you
are not currently displaying, switch frame buffer pointers, repeat.)
The current IFF specs are available from both Commodore and
Electronic Arts. Since it is an extensible format, new "FORMS" are
added every so often. There are many public domain and commercial
products which use, display, or convert IFF files.
--
Robert I. Eachus
with STANDARD_DISCLAIMER;
use STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...rthomson@mesa.dsd.es.com (Rich Thomson) (03/21/91)
In article <KAS.91Mar19151224@gabriel.cs.aber.ac.uk> kas@cs.aber.ac.uk (Kevin Sharp) writes: >None of popular image formats would be suitable. What you need is a >movie format. If that's the way you want to go, perhaps you should look at the AutoDesk Animator format (.fli files). It was described on comp.graphics on the 12th of March. I've included the article below. -- Rich Path: orca!uunet!lll-winken!taco!hobbes!kdarling From: kdarling@hobbes.ncsu.edu (Kevin Darling) Newsgroups: comp.graphics Subject: Re: FLI file-format? Keywords: FLI, file-format Message-ID: <1991Mar12.202026.5005@ncsu.edu> Date: 12 Mar 91 20:20:26 GMT References: <172@gem.stack.urc.tue.nl> Sender: news@ncsu.edu (USENET News System) Organization: North Carolina State University Lines: 175 >Has someone a description of the FLI-format? Autodesk Animator files explanation (.FLI only excerpted). I believe that the original programmer wrote up this doc. It's correct, as I've used the info to realtime playback stock .FLIs on a 680x0 machine. All numbers in a .FLI file are in Intel format, so you may have to compensate for that, of course. - kevin 8.1 Flic Files (.FLI) The details of a FLI file are moderately complex, but the idea behind it is simple: don't bother storing the parts of a frame that are the same as the last frame. Not only does this save space, but it's very quick. It's faster to leave a pixel alone than to set it. A FLI file has a 128-byte header followed by a sequence of frames. The first frame is compressed using a bytewise run-length compression scheme. Subsequent frames are stored as the difference from the previous frame. (Occasionally the first frame and/or subsequent frames are uncompressed.) There is one extra frame at the end of a FLI which contains the difference between the last frame and the first frame. The FLI header: byte size name meaning offset 0 4 size Length of file, for programs that want to read the FLI all at once if possible. 4 2 magic Set to hex AF11. Please use another value here if you change format (even to a different resolution) so Autodesk Animator won't crash trying to read it. 6 2 frames Number of frames in FLI. FLI files have a maxium length of 4000 frames. 8 2 width Screen width (320). 10 2 height Screen height (200). 12 14 2 flags Must be 0. 16 2 speed Number of video ticks between frames. 18 4 next Set to 0. 22 4 frit Set to 0. 26 102 expand All zeroes -- for future enhancement. Next are the frames, each of which has a header: byte size name meaning offset 0 4 size Bytes in this frame. Autodesk Animator demands that this be less than 64K. 4 2 magic Always hexadecimal F1FA 6 2 chunks Number of 'chunks' in frame. 8 8 expand Space for future enhancements. All zeros. After the frame header come the chunks that make up the frame. First comes a color chunk if the color map has changed from the last frame. Then comes a pixel chunk if the pixels have changed. If the frame is absolutely identical to the last frame there will be no chunks at all. A chunk itself has a header, followed by the data. The chunk header is: byte size name meaning offset 0 4 size Bytes in this chunk. 4 2 type Type of chunk (see below). There are currently five types of chunks you'll see in a FLI file: number name meaning 11 FLI_COLOR Compressed color map 12 FLI_LC Line compressed -- the most common type of compression for any but the first frame. Describes the pixel difference from the previous frame. 13 FLI_BLACK Set whole screen to color 0 (only occurs on the first frame). 15 FLI_BRUN Bytewise run-length compression -- first frame only 16 FLI_COPY Indicates uncompressed 64000 bytes soon to follow. For those times when compression just doesn't work! The compression schemes are all byte-oriented. If the compressed data ends up being an odd length a single pad byte is inserted so that the FLI_COPY's always start at an even address for faster DMA. FLI_COLOR Chunks The first word is the number of packets in this chunk. This is followed directly by the packets. The first byte of a packet says how many colors to skip. The next byte says how many colors to change. If this byte is zero it is interpreted to mean 256. Next follows 3 bytes for each color to change (one each for red, green and blue). FLI_LC Chunks This is the most common, and alas, most complex chunk. The first word (16 bits) is the number of lines starting from the top of the screen that are the same as the previous frame. (For example, if there is motion only on the bottom line of screen you'd have a 199 here.) The next word is the number of lines that do change. Next there is the data for the changing lines themselves. Each line is compressed individually; among other things this makes it much easier to play back the FLI at a reduced size. The first byte of a compressed line is the number of packets in this line. If the line is unchanged from the last frame this is zero. The format of an individual packet is: skip_count size_count data The skip count is a single byte. If more than 255 pixels are to be skipped it must be broken into 2 packets. The size count is also a byte. If it is positive, that many bytes of data follow and are to be copied to the screen. If it's negative a single byte follows, and is repeated -skip_count times. In the worst case a FLI_LC frame can be about 70K. If it comes out to be 60000 bytes or more Autodesk Animator decides compression isn't worthwhile and saves the frame as FLI_COPY. FLI_BLACK Chunks These are very simple. There is no data associated with them at all. In fact they are only generated for the first frame in Autodesk Animator after the user selects NEW under the FLIC menu. FLI_BRUN Chunks These are much like FLI_LC chunks without the skips. They start immediately with the data for the first line, and go line- by-line from there. The first byte contains the number of packets in that line. The format for a packet is: size_count data If size_count is positive the data consists of a single byte which is repeated size_count times. If size_count is negative there are -size_count bytes of data which are copied to the screen. In Autodesk Animator if the "compressed" data shows signs of exceeding 60000 bytes the frame is stored as FLI_COPY instead. FLI_COPY Chunks These are 64000 bytes of data for direct reading onto the screen. -eof- Notes: Since these are animations, the last frame will delta into a copy of the first one (which was usually a large BRUN chunk). Therefore, looping should go back to the _second_ frame chunk (usually a LC or COLOR chunk) instead of all the way back to the file beginning, to avoid a "stutter" caused by unnecessarily redecoding the original frame. Also, a very few files may have palette animation, so write your code so that COLOR chunks can be found at any time. - kevin -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
jim@psitech.com (Jim Rothrock) (03/22/91)
In article <KAS.91Mar19151224@gabriel.cs.aber.ac.uk> kas@cs.aber.ac.uk (Kevin Sharp) writes: >>>>>> On 16 Mar 91 23:51:10 GMT, tiefel@sunshine.Kodak.COM (Lenny Tiefel) said: >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. On the Amiga, most programs store their data in IFF files, which can contain several kinds of data. For example, an IFF file can contain a "form" ILBM, which is a bitmapped image. 8SVX is digitized sound data, and SMUS is music data. There is also an *ANIM* format, which is a sequence of compressed images. Only the differences between the frames are stored, and (I believe) several different compression methods can be used, depending on the type of image. e.g. run-length compression works well on 3D animations made up of flat-shaded polygons, but isn't as useful for photorealistic images containing very few contiguous sequences of pixels with the same color. The ANIM documentation and ANIM players are readily available (on the Amiga, at least). Someone should look into using this format for the movie images. -- Jim Rothrock | Disclaimer: My opinions do *not* represent the opinions jim@psitech.com | of PsiTech, Inc.
neideck@kaputt.enet.dec.com (Burkhard Neidecker-Lutz) (03/22/91)
I may be mistaken, but wasn't the whole purpose of this offer to give researchers in motion imagery compression a bae to work from ? If that is true then the compression used better be lossless and easy to code and decode. Given that it's also 24bit data I would say that only one of the more popular formats such as PPM can be used. This will make the voulem somewhat prohibitive but the stuff will be only useful if it's of high quality. Burkhard Neidecker-Lutz, Digital CEC Karlsruhe (who has his own video frame grabber for exactly this kind of research...)