Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!cs.umn.edu!msi.umn.edu!math.fu-berlin.de!fauern!unido!ztivax!athen!dhg
From: dhg@sinix.UUCP (David Griffith)
Newsgroups: comp.sys.next
Subject: Re: JPEG and NeXTstep 2.2
Message-ID: <1991May14.155313.12273@sinix.UUCP>
Date: 14 May 91 15:53:13 GMT
References: <13642@ur-cc.UUCP>
Organization: SNI AG Muenchen, STO XS
Lines: 33

In article <13642@ur-cc.UUCP> prie@escher.cc.rochester.edu (Tod Rieger) writes:
>
>     A passage from 'Communications of the ACM' April 1991,
>volume 34, number 4, page 45:
>
>NeXTstep 2.1 is currently shipping: this includes all video
>NeXTdimension capabilities with the exception of JPEG hardware
>support. JPEG hardware support will not be available until
>the NeXTstep 2.2 release in the fourth quarter of 1991.
>

Also in the same issue were estimates that JPEG compression of
a single frame took about ten seconds on a 68040 or 80486 (25MHz)
and just under one second on the new Intel i750. The requirement
of the C-Cube chip is that it do *30* frames per second. So
perhaps there is some truth in the rumours of a fundamental
design problem with the compression chip. You can implement
different versions of the compression algorithm some of which
are more "lossy" than others. Let's hope image quality isn't
sacrificed too much for speed. I'm hoping that we can program
the dimension board ourselves: that would give me the option
of implementing a simple but quick compression algorithm in
order to keep up with real time video. JPEG can be done offline
afterwards.

The original claim for the Dimension board was that it would
handle "all standard video inputs and outputs". But I've just
been told by my dealer that there will be two different versions,
one for NTSC and one for PAL/SECAM. The priority is NTSC and no 
date is available for PAL/SECAM. (Teach me to live in Europe :-|).
Anyone throw any light on this?

Dave Griffiths