At 1:42 PM -0400 8/24/05, Manfredi, Albert E wrote: >What they say is true for M-JPEG as well. Big deal. The big deal is that interframe compression IS NOT the best choice for all applications. It adds computational complexity, latency, and cost. If there is sufficient network and/or storage bandwidth, then an intraframe compression scheme offers significant benefits to many applications. >I'd like to see a compression efficiency comparison between >this, call it, M-JPEG2000 and MPEG-2 or H.264. And, of course, >as soon as a JPEG2000-based scheme is modified for efficient >moving image compression, just as JPEG was modified into >MPEG-2 last time around, This would be an apples and oranges comparison and prove nothing. ANY Interframe compression scheme would offer higher compression ratios. JPEG WAS NOT modified into MPEG-2. In fact, MPEG-1 was developed in parallel with JPEG, using many of the same core technologies for the I frame compression techniques. MPEG-2 was developed AFTER JPEG, and most of the new tools incorporated into that standard are related to interframe compression techniques and the coding of interlaced images. The JPEG camp was not looking to get into the motion imaging compression business. It was innovative designers at companies like Avid, Truevision and Media 100, who saw the potential of using JPEG for intraframe compression of video. They needed a frame based compression scheme with low computational complexity and latency to create the foundation for non-linear editing system. It just turned out that the inexpensive chips being designed for JPEG still image compression were able to provide the performance necessary to handle 30 frame per second. At the time an MPEG-1 encoder required a significant portion of a rack of electronics to provide a less desirable result. It is important to note that the non-linear application requires high quality. It took several years to tune M-JPEG to provide real transparency in image quality; the major reason for this was the performance of hard disk storage systems (at that time), which needed to handle 200-300 kBytes per frame of video stored to disk. The first systems from Avid and Media 100 used 1 and 2 GB disk drives and could only handle about 100 - 150 kBytes per sframe to disk. A comparison that would be meaningful would be to compare the image quality and bit rate requirements for M-JPEG versus JPEG-2000. For in-home networking and video storage, a system that can deliver high quality SD images at about 1-2 MBps would be commercially viable. I suspect that JPEG-2000 can do this >or the evolutionary H.264, that quote >will no longer apply. > >Here's a good introduction into the topic. Start with the >history, then just work through the subsequent sections. > >http://www.amara.com/IEEEwave/IW_history.html > >This seems like a truly different approach from MPEG/JPEG, as >opposed to the much more evolutionary nature of H.264. To >me, discrete Fourier, discrete Cosine, and discrete integer >transforms are just variations of the same theme. Obviously the wavelet transform is significantly different. And yes the MPEG standards are evolutionary, as they are riding the leading edge of the Moore's Law curve. New tools can be added periodically to improve the motion compensated prediction routines, and with H.264 they moved to an integer transform, which improves accuracy without a big hit to performance. But wavelets have had a difficult time historically competing in the Interframe compression arena, because of the need to introduce some kind of block based coding to handle the interframe predictions. I understand that there has been some progress in this area, but for now, wavelets are most promising for intraframe compression applications. > >> For those of us with experience in these matters, you >> could see another transformation in the works. With the >> commercialization of JPEG-2000 chips, it would only be a > > matter of time before wavelets started to invade the turf >> of MPEG and the world of non-linear editing. > >Those of us with experience know that the IP holders of >H.264 will first want to get their investment back, before >relinquishing this potentially lucrative market to >newcomers, eh? But a compression effiency comparison would >be nice. Too bad for those IP holders. They cannot force people to use their inventions, especially if there is a better, cheaper solution available for some applications. Regards Craig ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.