X-Mozilla-Status: 0001
        X-Mozilla-Status2: 00000000
               Message-ID: <37784F27.66A00F8@engin.umich.edu>
                     Date: Tue, 29 Jun 1999 00:44:23 -0400
                     From: Eric Durant <edurant@engin.umich.edu>
                 X-Mailer: Mozilla 4.5 [en] (WinNT; U)
        X-Accept-Language: en
             MIME-Version: 1.0
               Newsgroups: sci.image.processing
                  Subject: Re: Discrete Cosine Transform
               References: <37721CA4.57F5A3BF@wanadoo.fr>
                           <3773086D.AC4E0939@home.com>
                           <7l5ubo$b32@groucho.cs.ubc.ca>
                           <3777A718.5303B8F1@llnl.gov>
             Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>Dave Martindale wrote:
>>That 8x8 blocking is a "feature" of particular compression systems
>>that use DCT transforms.  The DCT itself is capable of transforming
>>an image of any size, without blocking artifacts, and if you're
>>building your own compression system you could use full-image DCT.

Subhasis Saha wrote:
>Well, if you try to compress an image by taking a full image (say 256
>by 256 or 512 by 512) DCT, you get a different kind of artifact in
>the decompressed image known as "ringing artifacts", since the basis
>functions become too long.  That's why it's never done. 8x8 block or
>16x16 block seems to be the most optimal in the sense of exploiting
>the correlation that exists between neighboring pixel values in an
>image. Of course as a result of this smaller blocks compression can
>be accomplished by parallel processors.

The optimum block size (in some rate-perceptual distortion sense) is a
function of the image being encoded (consider a greatly oversampled
press quality photo compared to a typical JPEG photo on a Webpage). 
Taking this a bit further, significant gains can be had for a minimal
increase in complexity by using quadtree-based segmentation with the
DCT.  You still get a bunch of m^n squares, where m is typically 2 in
practice, but now n is a variable; we're not restricted to 2^3 = 8
squares as in standard JPEG.  I concluded some research and wrote a
short paper (including MatLab demonstration code) on this a few months
ago.

http://www.edurant.com/papers/eecs651_JPEGEnhancements.ps.gz
or
ftp://ftp.eecs.umich.edu/people/edurant/eecs651.ps.gz

Eric Durant
---
Website:  http://www.edurant.com/
ICQ:      9118339