I sent this off to Barry and Eric.  Thought you might like a look at it:



Proposal for True Color Frame Animation Software

 

I. The Market

True color cards (those displaying 32000 and more colors

simultaneously) are starting to appear for less than $1000.00.  

One of the bonuses of the VGA was to equip everyone with analog

RGB monitors.  With true color we start to see a greater

interplay between the computer realm and the video realm.  I feel

it is likely that the market for a true color animator will be 2-

4x as large as the market for PJ.  While there are many technical

challenges to be met in designing and implementing such a system, 

it is likely that the transition from variable/hi-res 8 bit a

pixel frame editing to true color will be easier than the

transition from fixed/lo-res 8 bit a pixel frame editing to PJ.  

 

 

 

II. Low Level Technical Considerations

 

For an Animator style program to be effective we must first

develop real-time decompression algorithms.  Delta compression

will always work when not too much of the screen is moving, in

the worst case the speed of animation is determined by how fast

you can move an uncompressed frame from RAM (or disk) to the

display card.  For hand drawn animation six frames per second

(fps) is typically used for scenes where the motion is slow, 12

and occasionally 24 where the motion is fast.  In my experience

the traditional cel animator will be happy with 12 fps.  Computer

synthesized 3-D flybys on the other hand need 24 fps to appear

credible, and benefit from a solid 60 fps.   For video/filmed

sources I consider 15 fps near the bare minimum, and 30 adequate.

 

     Considering the small size of the traditional cel animation

market, a true color product is going to have to address 

computer synthesized or video sources.  Fortunately computer

synthesized graphics tend to have small enough changes between

frames that a system capable of displaying 15 fps of video is

easily able to display 30 fps of most synthesized imagery. 

Indeed without special compression/decompression hardware video

imagery reverts to the worst case more often than not.  So lets

look at the data rates required for 15 fps uncompressed images:

 

 Display       Resolution     Depth (bits)   Data Rate (byte/sec)

VGA/MCGA        320x200        8                960,000

Super VGA 256K  640x400        8              3,840,000

Super VGA 512K  640x480        8              4,608,000

8514/A         1024x768        8             11,796,480

NTSC            512x240       16              3,686,400

NTSC Interlace  512x480       16              7,372,800

Better NTSC     512x480       32             14,745,600

HDTV           1024x960       32             58,982,400

 

     The most popular "hi-res" mode of PJ is likely to be 640x480

since this matches the 16 color resolution people have come to

love in their VGA cards.  As you can see a minimal resolution but

still suitable for NTSC video-taping would have a _lower_ data

rate than hi-res PJ.  Even the shift from PJ resolution to the

relatively hi-end 512x480 32 bit-a-pixel resolution would be

roughly a 3x increase in data (as opposed to the 5x increase we

had coming from VGA/MCGA resolutions.)

 

     Though in truth PJ does not keep up with Autodesk Animator

frame rates in the high resolutions, it does come close.   We

achieved this by sending data to the video card 16 bits at a time

instead of 8.   In the time between the Animator release and PJ's

release the clock speed of your 'power' PC nearly doubled.  As a

result we managed to nearly break even!  I imagine clock speeds

will continue to go up, and that 32 bit buses will become more

common in the next 12-18 months.  So with luck when a true color

product is ready for release we will be able to maintain frame

rates even at the better NTSC resolutions.

 

III.  Hardware Assisted Compression and Decompression

 

     PJ manages to do a credible job of full-screen animation in

hi resolutions when playing back from RAM.  However even from a

very fast hard disk animation with large deltas are slow at best,

and often embarrassingly jerky.   One reason is disk speed has

not advanced at the rate that memory speed has, also the faster

disks already had 16 bit data paths at the time of the Animator. 

 Though personally I'd rather see a breakthrough in mass storage

technology, and EISA controllers with 32 bit interfaces, 

hardware image compression and decompression devices provide

another solution that at the moment looks a bit more likely in

our time frame.  

 

     I know of several hardware image compression efforts in

various stages.   There is the much talked about DVI effort.  I

am a bit skeptical of this one.   This started out as the work of

a small design team at Sarnoff (sp?) Labs. From what I can tell

the early work was quite good.  However it was done using silicon

compilers with the naive hope that the design could be hand

polished and speed tweaked in a timely manner without introducing

lots of bugs.  This is somewhat akin to thinking that the output

of a C compiler is a good place to start for developing maximally

efficient assembler code, and I can tell you it just isn't so!  

Better to work at a higher level and wait for the processes to

get faster underneath you in the meantime.   At any rate DVI was

developed by a small group who weren't tied to any particular

computer architecture.  Their prototypes (for expedience sake

from what I can tell) were mounted on boards that could slot into

a PC.  Bill Gates and the good folks with vested interest in the

IBM PC architecture were in dire need of an answer to the CDI

threat (see below).  They latched onto DVI, trumpeting it to the

press while it was still very much in the experimental stage.  

Meanwhile the DVI group was moved first to Princeton, and later

to Silicon Valley.   One wonders how many of the designers

survived the changes in management and the moves.   The target of

DVI, a read only medium with a data transfer rate not that much

better than high density floppies, is quite unlike the

interactive editing environment associated with the Animator. 

The color fringing and other artifacts introduced in the

compression process make DVI no better to the video producer than

straight analog NTSC (but with lower resolution).  Intel heard

some of our problems with this medium when we met with some of

their DVI management slightly before the release of the Autodesk

Animator and,to their credit,seemed concerned.  They offered no

solutions beyond --"well it is microcodable."   Given the amount

of money and press spent on DVI I suspect we will be hearing of

it for quite some time, but I frankly doubt it will be of use to

us in a true color frame editor.

 

Predating DVI is CDI (Compact Disk Interactive).   This is

envisioned as a keyboard-less computer more like a video-game

console than a PC which will, incidently, play back audio CD's. 

Sony, Phillips, and other extremely large corporations have been

working on it for some time.  It looks like a well-designed

system, though again four years after the big excitement in the

press it has yet to find it's way into consumers hands.  It is

based on a 68000 compatible processor running OS-9 (which is a

multi-tasking operating system I have a bit of experience with). 

There is also a (more modest) image decompression chip set which

has a mode that could, charitably, be described as true color. 

The original chip set could do run-length decompression.  Later

seeing the Antic Cyber stuff, Zoetrope, Dpaint III, and, indeed,

talking to myself, they implemented delta decompression first in

software and now I hear in hardware as well.   The true color

mode is 9 bits a pixel, and uses a color model closer to NTSC

than RGB, though I've forgotten the details.   (It is better than

HAM on the Amiga though!)   

 

A company well worth watching is Compression Labs.  I don't know

many details, but they have been making compression components

for video-phones for several years now, and seem quite stable and

on the ball.   Their work that I've seen has been black and

white, with a relatively low frame rate, and lo res to boot.  But

they do compress and decompress in real time, and squeeze it down

enough to go over a phone line. 

 

C-Cubed also is very far along in some digital video compression

chips.   Since you probably know more about them than I do I'll

omit the details here.  Perhaps you can fill me in on it later.

 

How exactly our true color frame editing software will relate to

these hardware image compression engines is hard to say without

working directly with these chips.    In PJ I put the

decompression routines onto drivers which are loaded by PJ, and

can be developed by third parties.   I made the decision to keep

the compression side on the host.  (This makes it easier to

interchange files and makes the drivers less complicated,  but

means that hardware assist has to be tailored to our format.)  In

the true color system I will put both the compression and the

decompression into the driver so that the driver can format the

data to be as fast as possible with a particular set of hardware. 

 It's my feeling that for at least the first couple of years of

release this hardware is going to be either an 80486 or a TI

34010 or 34020 for most people.  (The 34010 is a microprocessor

with an instruction set especially handy for graphics.  It turns

out it does Limpel Zif Welch (arc-type) and Huffman decoding much

faster than a traditional microprocessor as well.  We'll see soon

how fast it can decompress PJ-formatted Flic's, Jake Richter and

TIGA 2.0 willing.)   Given the changing state of hardware

compression, loadable drivers is the best way to handle these

chips at the present time.

 

 

IV.  Adaptation of PJ to True Color

 

Adapting PJ to true color will proceed in several phases.  First

we need to devise a file format and associated 80386 compression

and decompression routines.   This will probably take one to two

months and should be started as soon as possible.  If we manage

to devise even semi-credible frame rates on today's hardware I

would say it'd be easy to sell Autodesk on the rest of the

project.   Possibly we can work on 34010 assisted techniques

during this stage.  (There's a 34010 in the Hercules Graphics

Station Card which is currently one of the cheapest ways to get

into true color.)

 

The next phase is to bring up a true color PJ with no changes to

the user interface.   This'll probably take around three months.

 

The third phase would be to bring the benefits of true color to

the user.  The Palette Panel will, of course, need extensive

reworking.  It'd also be desirable to incorporate 'object based'

antialiasing rather than post-process antialiasing (lines that

are drawn with soft edges rather than smoothed out by the user as

a second operation.)  We will, I assure you, think of many other

features that are suddenly easy to implement in the context of

true color, and desirable to the user.   I would like, if

possible, to get Dan Silva to work with us during this phase,

which should be allotted at least three months.

 

Finally we need to consider features such as outline fonts,

better titling in general,  communication with the 3-D software

(which works naturally better in true color than in 256 color),

and, God bless us, whatever ADI has turned into by then.   Add

three months for these types of features, three or four months

for QA and we should be ready to sell the product.

 

V. Conclusion

 

A true color frame editing system to be released in 12-18 months

looks in my mind a good deal more feasible than PJ ever was.  I

believe it will benefit more from synergy with our 3-D software,

and make more use of video image sources than anything we've seen

yet.   In short, I feel we should embark on the initial stages of

developing compression formats immediately, possibly using Jim

Mackraz, Eric Lyons, or myself.   We may want to put off later

stages until we see how PJ does, but I am confident that a true

color product will do much better than the hi-res 256 color one.



&