home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / compress / research / 402 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.5 KB  |  48 lines
  1. Newsgroups: comp.compression.research
  2. Path: sparky!uunet!ukma!bogus.sura.net!howland.reston.ans.net!spool.mu.edu!torn!skule.ecf!kumarad
  3. From: kumarad@ecf.toronto.edu (KUMARADAS JOSEPH CARL)
  4. Subject: Re: DCT optimisation
  5. Message-ID: <C1LHAG.5H3@ecf.toronto.edu>
  6. Organization: University of Toronto, Engineering Computing Facility
  7. References: <C1L49B.9ML@cs.bham.ac.uk>
  8. Date: Fri, 29 Jan 1993 02:51:51 GMT
  9. Lines: 37
  10.  
  11. In article <C1L49B.9ML@cs.bham.ac.uk> ahp@cs.bham.ac.uk writes:
  12. >I am a final year undergraduate doing a software engineering project in Digital Video.
  13. >I have implemented a number of image compression algorithms that run on Sun Unix
  14. >workstations, among these is a JPEG and MPEG codec. I should immediately add that these
  15. >are not true compliant codecs but merely abstract the core ideas present in them. The
  16. >problem I have is that I am currently using the standard fast DCT algorithm, but even
  17. >with the speed of a Sun/4 processor I cannot get more than a frame a second at 160 by
  18. >120 image size. I have already scaled the algorithm into integer maths that helped a
  19. >lot but I am stuck for the next move. I have also implemented a fairly sophisticated
  20. >motion estimation system which allows me to miss out well matched blocks completely
  21. >if the error between the motion estimated blocks and the actual block is below a given
  22. >threshold, this obviously presents one way of speeding up the process by simply not
  23. >doing an inverse DCT on every block !
  24. >Any thoughts and ideas would be greatly appreciated. Anthony Phillips.
  25.  
  26. Take a look at an artical by Ephriam Feig from IBM, published in "Image 
  27. Processing and Techniques", Vol 1244, pp2-13.  It is I suspect the fastest
  28. known algorithm for DCT's.  I worked on optimizing an implementation of it
  29. while at IBM.  The work lead to what we believe to be the fastest JPEG
  30. software decoder.
  31.  
  32. I still don't suspect that it will improve your frame rate significantly.
  33. I too am a undegrad in my final year.  I was looking at issues in diplaying
  34. MPEG type video using software, but I have decided to concentrate only on
  35. the DCT section due to a lack of time.
  36.  
  37. For performance reasons I was looking at displaying 160X120 (coincidence!)
  38. 8bit gray-scale video.  How about coding the error stream with some other
  39. less-computation intensive coding (run-length?)?
  40.  
  41. You may want to take a look at a product for OS/2 released by IBM for 
  42. software only video display.  It uses their own video compression algorithm
  43. with adjusts to difference CPU power.  I think it's called Ultimotion
  44. or something to that effect.
  45.  
  46. Carl.
  47.  
  48.