Gavin Greenwalt
Well-known member
- Joined
- Dec 29, 2006
- Messages
- 7,614
- Reaction score
- 0
- Points
- 36
- Age
- 40
- With permission this is from an article I wrote for Showreel Magazine. A Magazine I only just started reading when I got the last issue but is actually very exciting and I highly recommend picking up a subscription at http://www.showreel.org
As a result I request that you do not repost this elsewhere. Thanks.
- Gavin
Uncompressed images can be downloaded here:
http://www.mediafire.com/?e00ljjh9xjz
Let me begin this by prefacing that this is not an empirically accurate study on the effects of compression. Nor is it an evaluation of any one product, the goal is not to test any specific codec but rather a family of compression. If you are searching for a codec showdown you'll have to look elsewhere. However, what this article does hope to provide is a glimpse at the options that are available now or will become available in the near future and help you focus your attention on some options you might not have otherwise investigated.
The intent in these evaluations is to demonstrate a set of tests which could be carried out on one's own time without the need for rare or proprietary equipment. With a multitude of Ultra High Definition cameras on the horizon many of us are beginning to realize that holding onto an uncompressed workflow may be a luxury we can no longer afford. Hopefully when you’re done reading this article you’ll be able to walk away more confident in understanding the options available to you.
So what is a wavelet and how is it different from what you're already using? Well to answer that first we need to address how other widely used compression schemes work. I'll try to order them in it compression intelligence.
RLE and its friend Packbits are some of the least intelligent encoding schemes. These are your built-in compression options for Targa images. Both simply group together continuous sections of repeating data. For example if we have a row of pixels:
0 0 0 0 14 14 0 0 23 0 0 0 0 0.
RLE will group them into:
4 ‘0’s, 2 ‘14's, 2 ‘0’s, 1 ‘23’ and 5 ‘0’s.
This can save a great deal of space if your image has large blocks of solid color (for example alpha maps, text, motion graphics etc…) but does a very poor job on noisy images. If a solid block is 1 pixel wide or a thousand, it will take the same amount of bits to compress it with RLE.
Zip and LZW are the most common members of the next family of compression methods known as the “Dictionary Compressors”. The basic principle behind a dictionary compressor is similar to an RLE except instead of blindly operating in an order, a dictionary compressor finds repeating patterns wherever they might occur and calls on them later. For example if we have the sentence:
"I am hoping the article that I am writing will help you understand your compression options better"
The compressor will identify... 1:"I am" 2:"ing" 3:"you" 4:"ion" and 5:"th"... as recurring patterns to save in a library along with the data:
"1 hop2 5e article 5at 1 writ2 will help 3 understand 3r compress4 opt4ns better". On decompression the software will play a game of paint by numbers to fill in the data.
Both of these families of compression are mathematically lossless. The decompressed image is identical pixel for pixel to the original. However often on natural images they lose effectiveness and a more advanced compression scheme would do better.
The group of compression methods which we most often see in video is a family called DCT which is always lossy (The compressed image is similar but not identical to the original). This group encompesses JPEG, MPEG 1-4, HDCam, DV, and just about every other video compression system you'll probably encounter in your day to day work. Depending on the codec the image will be broken up into X pixel by Y pixel blocks. Each block, based on the quality setting, will attempt to discard all detail frequency above the specified quality threshold. The problem with this methodology is often some details don't fall entirely within neat little AxB sized boxes. As a detail, such as a strand of hair, extends through several boxes each box attempts to reduce itself into the most efficient box it can be regardless of what its neighbor is doing. If in the previous example the hair's contrast is low enough, it might be treated as a high frequency detail and discarded in one box, but not the next. This is where you often see zig-zaggy edges and is the bane of compositors everywhere.
Finally we have Wavelets which come in both lossless and lossy flavors. Despite the recent spike in interest in wavelets they aren’t some crazy new fangled invention. Several solutions have been commercially available for several years such as Bink Video which uses a hybrid wavelet/DCT scheme to compress videos for in-game cinematics. Fundamentally Wavelets share a great deal in common with DCT compression however it features one important distinction. A wavelet image is able to scale its sample size from a single pixel to the entire image depending on the content. If an image is 32pixels by 32pixels the wavelet will first evaluate all 32x32 boxes, then reduce it to 16x16, 8x8...and so on and so forth until finally reducing the image to a 1x1 pixel sample. Where there is fine detail, smaller, more refined boxes will be used. If the image detail is courser than the designated quality setting requires the encoder will discard those samples 'revealing' the lower resolution below. This results in more detail remaining in the areas that need it most and less detail where it would be unnecessary. It’s all very similar to how a painter will build up from large general brushes and washes to smaller detailed brushes. This method works especially well when you’re ‘short’ on bandwidth and require heavy compression. Wavelets also work especially well on many digital cinema cameras due to the lack of high frequency grain allowing them to heavily compress low contrast areas without a reduction in the SNR. It’s actually that side effect which has led to wavelets being employed as a noise and grain reduction algorithm.
So are Wavelets the be-all-end-all compression scheme? As all things in this world it isn’t as cut and dry as one might hope. Wavelets do offer some very distinct advantages over DCT. As the file size decreases the image tends to degrade much more gracefully and organically. Instead of ending up with a bunch of unnatural blocks wavelets tend to leave the noisy, low contrast areas of the image softer. In green screen scenarios this can actually be advantageous as it’ll intelligently reduce the noise in the large flat green areas while holding on to detail in the edges and hair. However all of this adaptive intelligence comes at a cost in speed. Compared to most DCT implementations your average Wavelet is downright sluggish, a fact which has kept wavelets out of the mainstream until now. That being said, wavelets have one last trick in their bag which is a feature pretty much incidental to their design. Because a wavelet is built up of progressively more refined levels of detail, stripping off a few top layers is relatively trivial. By specifying the “top” resolution you want decoded your wavelet footage can appear to the application as any 1/(2^N) resolution proxy without re-encoding. In editing scenarios this allows you to edit at 1k and then render out a 4k conformed timeline with the flip of a switch. Theoretically one should be able to do this in any Quicktime compatible editing or compositing application, however it is my experience that at the moment compatibility is still pretty spotty.
