🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.compression.research
Article #151

Re: DCT optimisation

#151
From: 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.
Technical Details
Message-ID: <C1LHAG.5H3@ecf.toronto.edu>
Path: arc1-ca.pugleaf.net!sparky!uunet!ukma!bogus.sura.net!howland.reston.ans.net!spool.mu.edu!torn!skule.ecf!kumarad
References: <C1L49B.9ML@cs.bham.ac.uk>

Show Full Headers
Complete Article Headers
Newsgroups: comp.compression.research
Path: arc1-ca.pugleaf.net!sparky!uunet!ukma!bogus.sura.net!howland.reston.ans.net!spool.mu.edu!torn!skule.ecf!kumarad
From: kumarad@ecf.toronto.edu (KUMARADAS JOSEPH CARL)
Subject: Re: DCT optimisation
Message-ID: <C1LHAG.5H3@ecf.toronto.edu>
Organization: University of Toronto, Engineering Computing Facility
References: <C1L49B.9ML@cs.bham.ac.uk>
Date: Fri, 29 Jan 1993 02:51:51 GMT
Lines: 37