2.7. Computer Output to Film/Video.   

It is often not convenient to generate an image in an animation sequence direct to a graphics terminal if it takes any length of time. It is even more dubious trying to generate and record onto video this way. It is better to generate and store the scene in a file. The frames can then be recorded onto a 1" Video Recorder, Betacam SP or onto 16, 35 or 70mm film.

This recording can be done via a film recorder, via a frame by frame system with a frame store such as a Vista board or dumped onto a Video disk recorder such as an Abekas which can take computer files in a certain graphics format and then play them back in real time.

A normal PAL TV image is 768x576 pixels. Each pixel requires values for the red, green and blue components. This means at least 768x576x3 bytes of information to describe a T.V. screen = 1.3 megabytes per frame. Multiply this by 25 frames per second ==> 33 megabytes for 1 second of animation. And obviously 1 minute of animation would require approximately 2 gigabytes.

2.7.1. Run Length Encoding Compression.   

Most formats used to store images will use some form of run length encoding - the information stored is NOT just the rgb values but codes which indicate when runs occur. For example, if an entire scan line was one single colour then instead of 768 x 3 bytes, we could store 6 bytes (99% compression!):

            1 byte to indicate a run rather than a colour

            2 bytes for the length of the run and

            3 bytes for the rgb value

The Utah Raster Toolkit format uses one form of run length encoding. The Silicon Graphics Image library uses another more efficient form which can often save up to 50% of the space. When we create a single file that contains many consecutive frames (i.e. animation ) we can use this compression technique.

This reduction though is still not sufficient to save enough space (we might still be looking at 1 gigabyte for 1 minutes animation). To save a lot of space we need to compress between frames: temporal compression.

2.7.2. Temporal Compression.   

If little changes between frames - only a few things are animated - then consecutive frames will have similar (rgb) values for the same scan lines. Therefore if we take a large number of consecutive frames, we can store the first and then store the differences between the first and the second, and then store differences between the second and third and so on. Our file of many frames now becomes a file with a base frame plus consecutive frame differences.

This technique is very efficient because the differences are simply scan lines of background colour (which will be ignored when we record) plus runs of the (rgb) values where changes have occured. The efficiency is gained by these long runs of background colour; these are reduced by up to 90%. Therefore the amount saved depends upon how much changes from frame to frame.

For example, a small object rotating may compress by 70-80% in the 2nd and subsequent frames. An object of one colour will compress better than an object with a texture map or a bump map since as the object moves the texture will probably change in each frame. (Sometimes the differences between the n'th and the n+1'st frame are greater than the normal size of the n+1'st frame! In this case we are not compressing at all and are simply making matters worse by our technique. This is not common but can happen with large, animated, textured objects).

Using these compression techniques, 300 frames or more have been stored in about 60 megabytes. This equates to about 200K per frame. The PC which does the recording has a program which caters for this compression (see later section on screen) and reconstructs the images by displaying the original and then only changing the screen via the differences for subsequent frames.

     


    
        Fig. 2.17 : Example of Animated Logo (15K bytes).

     


    
               Fig. 2.18 : Animation (37K bytes).