DCT optimisation

Thread View: comp.compression.research

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Anthony H Phillips Thu, 28 Jan 1993 22:10

#150

Author: Anthony H Phillips
Date: Thu, 28 Jan 1993 22:10

13 lines
1471 bytes

I am a final year undergraduate doing a software engineering project in Digital Video.
I have implemented a number of image compression algorithms that run on Sun Unix
workstations, among these is a JPEG and MPEG codec. I should immediately add that these
are not true compliant codecs but merely abstract the core ideas present in them. The
problem I have is that I am currently using the standard fast DCT algorithm, but even
with the speed of a Sun/4 processor I cannot get more than a frame a second at 160 by
120 image size. I have already scaled the algorithm into integer maths that helped a
lot but I am stuck for the next move. I have also implemented a fairly sophisticated
motion estimation system which allows me to miss out well matched blocks completely
if the error between the motion estimated blocks and the actual block is below a given
threshold, this obviously presents one way of speeding up the process by simply not
doing an inverse DCT on every block !
Any thoughts and ideas would be greatly appreciated. Anthony Phillips.

Re: DCT optimisation

#151

Author: KUMARADAS JOSEPH CARL
Date: Fri, 29 Jan 1993 02:51

36 lines
2616 bytes

In article <C1L49B.9ML@cs.bham.ac.uk> ahp@cs.bham.ac.uk writes:
>I am a final year undergraduate doing a software engineering project in Digital Video.
>I have implemented a number of image compression algorithms that run on Sun Unix
>workstations, among these is a JPEG and MPEG codec. I should immediately add that these
>are not true compliant codecs but merely abstract the core ideas present in them. The
>problem I have is that I am currently using the standard fast DCT algorithm, but even
>with the speed of a Sun/4 processor I cannot get more than a frame a second at 160 by
>120 image size. I have already scaled the algorithm into integer maths that helped a
>lot but I am stuck for the next move. I have also implemented a fairly sophisticated
>motion estimation system which allows me to miss out well matched blocks completely
>if the error between the motion estimated blocks and the actual block is below a given
>threshold, this obviously presents one way of speeding up the process by simply not
>doing an inverse DCT on every block !
>Any thoughts and ideas would be greatly appreciated. Anthony Phillips.

Take a look at an artical by Ephriam Feig from IBM, published in "Image 
Processing and Techniques", Vol 1244, pp2-13.  It is I suspect the fastest
known algorithm for DCT's.  I worked on optimizing an implementation of it
while at IBM.  The work lead to what we believe to be the fastest JPEG
software decoder.

I still don't suspect that it will improve your frame rate significantly.
I too am a undegrad in my final year.  I was looking at issues in diplaying
MPEG type video using software, but I have decided to concentrate only on
the DCT section due to a lack of time.

For performance reasons I was looking at displaying 160X120 (coincidence!)
8bit gray-scale video.  How about coding the error stream with some other
less-computation intensive coding (run-length?)?

You may want to take a look at a product for OS/2 released by IBM for 
software only video display.  It uses their own video compression algorithm
with adjusts to difference CPU power.  I think it's called Ultimotion
or something to that effect.

Carl.

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads