\section{ Introduction }

Hi, this is some preliminary documentation to the tarkin/w3d code. It's written
to document the code, explain and discuss the used algorithms and help those 
ones who want to read or modify the code.

It's neither complete nor written to learn everything about compression 
algorithms. If you want more general introductions to data compressions please 
take a look in the Bibliography to find some pointers.

The first section will give a brief overview over the compression codec.
Then all parts of the encoder/decoder will be described in the order they appear
in the encoder. Have fun !


\section{ Overview about the highlevel part }
\subsection{ Or: How it may work when it's done }

The incoming images should get transformed into a motion flow field. This
has some nice properties which makes it well to compress. It's
complexity is independent of image object complexities and speeds. It only
depends on the number of objects in the image and their speed divergence -- 
the worst case would be a image with hundrets of small fast moving objects. 
Since the human eye has similiar troubles in analyzing such images we 
can hope that artifacts here won't matter.
Such smooth motion fields are ideal to compress using wavelets -- a panorama
move could be stored theoretically in the DC coefficient \dots
 
To encode a block of frames (say 16 or 32 for example) we may first encode
a I-Frame, the first or center image of this block by wavelet compressing it.
Then the motion fields relative to this frame get wavelet compressed (3D or
2D+Frame differencing) and transmitted. Since some cases can't be 
efficiently expressed in motion fields (imagine an object which was outside the
reference image and is now moving in) we need some additional error correction
informations, these can be simple differences of the reconstructed image after
application of the relative motion field and the original images. These 
differences could get wavelet encoded and then transmitted.

For now have we the wavelet transform code, the coefficient encoder and a 
working but not very efficient entropy coder. Since the above steps all require
these tools I think we have a base we can work on. What we need now is the 
motion flow detection and the putting-it-all-together-framework.


\section{ Overview about the lowlevel part }

Almost all steps in the compression codec try to transform data into a 
representation with a few large numbers and many smaller ones which need
less bits to encode and can be compressed well by entropy coders.

An RGB image is first transformed into a YUV-alike colorspace to decorrelate in
color direction, U and V are usually much smaller than the RGB components.
Y is a weighted average of the red, green and blue color component.

Then each color component is then transformed into frequency space using a 
lifting integer wavelet transform. This is again decorrelating, this time in 
image space direction. Our wavelet transform implementation can handle 1D-, 
2D- and 3D-data. The resulting coefficients are then quantized and entropy 
coded, these areas still need a lot of work, thus they are not yet documented.


