Article View: comp.compression.research
Article #151Re: DCT optimisation
From: KUMARADAS JOSEPH CARL
Date: Fri, 29 Jan 1993 02:51
Date: Fri, 29 Jan 1993 02:51
36 lines
2616 bytes
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!kumaradReferences:
<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