Newsgroups: comp.graphics
Path: utzoo!utgpu!watserv1!watcgl!imax!dave
From: dave@imax.com (Dave Martindale)
Subject: Re: Pixar sells hardware division to Vicom
Message-ID: <1990May4.135210.13071@imax.com>
Organization: Imax Systems Corporation, Toronto Canada
References: <1990May2.154503.9201@imax.com> <1185@med.Stanford.EDU>
Date: Fri, 4 May 90 13:52:10 GMT

In article <1185@med.Stanford.EDU> rick@hanauma.stanford.edu (Richard Ottolini) writes:
>
>Special purpose hardware has trouble keeping up with improvements in
>general purpose CPUs and software.  The latter are doubling in capacity
>about every year.  A relatively small company such as Pixar would be
>lucky to ewngineer new hardware every three to five years.
>

I can see this argument for software like RenderMan.  It probably runs
faster right now on a fast SGI box than it ever did on the Pixar Image
Computer.  But the PIC is basically a fast image-processing box,
with 16-bit integer arithmetic, and was never particularly well-suited
for floating-point-intensive operations like rendering.  At one time,
perhaps, its plain raw speed made simulated floating point on the PIC
faster than real floating point on a VAX or Sun, but that advantage
was bound to evaporate as general-purpose CPU's catch up.

But, as I said, I'm not interested in RenderMan.  I'm interested in
the Pixar hardware.  The PIC has a much better memory organization
and video hardware for handling large images.  You can put 32 million
48-bit pixels of memory in the PIC (if you can afford it!) and
treat it as one single image.  Or configure it as 42 1024x768 images.
Or almost anything else you want.  The memory is just a big linear
address space, and the video controller can be configured for
a nearly-arbitrary starting address and per-scanline address increment.
And each pixel is stored with 12 bits of RGBA, though only 10 of
those go through the lookup table.

If someone else was selling a replacement for the PIC, it wouldn't
bother me too much.  But I don't know of one.  Other vendors typically
have a fixed-configuration frame buffer, where each pixel on screen
has a fixed location in memory (at least when zoom is off), and with
no capability for expanding the size of the frame buffer.  So the only
way to display really large images is to have lots of non-display memory,
and repeatedly copy a selected window of it to the display as you pan
around.  Even the Pixar II did this.

In addition, most vendors think that 24 bits/pixel provides "true colour".
This can't provide the full brightness range that a CRT (or film)
is capable of while avoiding banding artifacts under all conditions.
Pixar stored 12 bits per component, with a reasonable scheme for
avoiding underflow and overflow when doing things like interpolation.
All processor data paths are 16 bits/component.

In short, Pixar seemed to care about dealing with "film-quality" images,
which are necessarily large in both spatial resolution and pixel bit
depth, when nobody else was.  Most other vendors don't seem to understand
film at all.  It's sad to see Pixar leave that business too.

Now, I know nothing of Vicom, and maybe they do care about film.  But my
impression of image processing companies to date is that they can't
understand why you would ever want more than 8 bits per component.

	Dave Martindale