Article View: comp.multimedia
Article #121Behaviour of QuickTime compressors
From: Lawrence D'Oliveiro, Waikato Uni...
Date: Thu, 06 Aug 1992 02:21
Date: Thu, 06 Aug 1992 02:21
52 lines
3400 bytes
3400 bytes
I was wondering the other day how smart the Apple-provided QuickTime compressors are in doing their frame-differencing compression. Would they do motion detection? To investigate this, I created a very simple movie in MacroMind Director 3.0. This was a black ball, 116 pixels in diameter, moving across a white stage (342 * 512 pixels in size) from left to right. Just for fun, I drew a graduated grey-scale highlight with Canvas and stuck it on the ball. I then exported the animation as a PICS file (Director 3.0 doesn't have direct QuickTime support) and tried compressing it as a QuickTime movie in various ways. The animation had I think a total of 25 frames, and the PICS file size was 192K (as opposed to 4K or something equally ridiculous for the original Director file). I had enabled Director's frame-differencing facility, where each frame of the PICS file after the first only redrew the part of the previous picture that was different. I put this data through the Animation compressor, which works by run-length encoding. At 8 bits per pixel, the resulting QuickTime movie was 196K in size. Allowing for some extra overhead for the QuickTime movie format, I'd say the Animation compressor had done about as good a job as Director had of picking up the differences between frames. The other interesting thing was that I'd set the spatial and temporal compression quality settings down to their absolute minimum. The Animation compressor is supposed to have a lossy mode, but I think this does not apply to pixel depths of 8 bits or less. I then tried the Graphics compressor, which only supports 8-bit-per-pixel images, but apparently works well with dithered images. With the quality settings on minimum, I was able to get the size of the movie file down to 52K, without any really noticeable quality loss. Finally I went back to the Animation compressor, and specified a depth of 16 bits per pixel. This means the Image Compression Manager had to depth-convert the frames of the animation up from the original 8 bits per pixel before compressing them. I was surprised to find that the size of the movie file was now 119K! I'd say it was definitely getting into lossy compression now. When I viewed the movie, I saw a bit of graininess in the highlight on the ball, but that was probably just an artifact of the "fast dithering" mode for displaying the movie on my 8-bit screen. By the way, I also discovered why Director is so slow at exporting its animations to PICS files: it closes and reopens the file after adding each frame! What a dumb thing to do, in what is otherwise such a neat program. In any case, I've sent the order off for the 3.1 upgrade--I'm looking forward to seeing what its direct QuickTime support is like. Lawrence D'Oliveiro fone: +64-7-856-2889 Computer Services Dept fax: +64-7-838-4066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
Technical Details
Message-ID:
<1992Aug6.142127.9903@waikato.ac.nz>Path:
arc1-ca.pugleaf.net!sparky!uunet!wupost!waikato.ac.nz!ldoShow Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!waikato.ac.nz!ldo From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Newsgroups: comp.multimedia Subject: Behaviour of QuickTime compressors Message-ID: <1992Aug6.142127.9903@waikato.ac.nz> Date: 6 Aug 92 14:21:27 +1200 Organization: University of Waikato, Hamilton, New Zealand Lines: 52