td@alice.UUCP (Tom Duff) (11/03/84)
I worked on the computer graphic sequences in Star Trek II and Return of the Jedi.
In both cases we shot frames directly from the monitor (A Barco CDCT for ST2,
and an E&S Picture System II monitor for RoJ) using more or less ordinary 35mm
animation cameras. The only unusual requirement is that the camera be able to shoot
single frames at fairly long exposures. Outboard animation motors are available
for most 16mm movie cameras, so this need not be an expensive proposition.
If you decide not to buy an off-the-shelf integrated monitor/color-wheel/camera
box like those made by Dunn Instruments or Matrix Instrument, you will run
up against a few problems, none of which is particularly insoluble.
The most serious (i.e. hardest to solve) problem is long-term stability.
If it takes you 30 seconds to shoot each frame (not unreasonable given typical disk
transfer rates and exposure times), a 10 second shot will take 2 hours to film.
If the brightness of the monitor varies slightly over a 2 hour period,
you probably won't see it, but when it's compressed to 10 seconds it may be
enough to ruin the shot. For the same reason, you should mount the camera
on the strongest support you can afford.
A 1 inch thick steel platform with the camera and the monitor bolted to it is about
as good as you might need. Failing that, get the strongest tripod you can
afford and try to use a ground-floor room with a concrete floor. The filming
room at Lucasfilm has wall-to-wall carpet over a wooden second-storey floor.
We tried to keep people out of the building (seriously!) when we filmed because
of the floor's instability. (BTW, I weigh about 300 lbs., which makes me a
first-rate film-room floor tester.)
A pin-registered animation camera is a necessity for professional work, but
may not be required for industrial or academic use. If the film jitters
too much for your liking, and you're sure your projector is not at fault,
you'll have to bite the bullet and find a pin-registered movement.
The second-most serious problem is shutter bars, which occur when the camera's
shutter is not open for an integral number of frames. The partial frame will be
be visible as a bar that's exposed more than the rest of the frame. The only
good way to solve this problem is to synchronize the shutter with the display's
refresh. We were fortunate at Lucasfilm that refresh was software controllable,
so we could build a simple (4 components -- a 555 timer, a 10 turn pot, a capacitor
and a solid-state relay) camera controller that we could wire in parallel with the
Sonalert beeper on a terminal. This would open the camera's shutter for a
fixed period of time (settable using the 10 turn pot) whenever a ctrl-g (ascii
BEL) was sent to the terminal. So, the program that shoots a frame does
the following:
blank the video
putchar('\7'); /* beep */
wait a while for the shutter to open
unblank the video for a fixed number of refreshes
blank the video
wait a while (long enough for the shutter to close)
All of the timing (including the 10 turn pot) gets adjusted manually
until it works.
If you can't synchronize the camera with your refresh, you can only stop the
camera down and hope that the difference between n and n+1 refreshes will
be unnoticable when n is large enough.
The third major problem you will encounter is color compensation. This is
usually the main cause of the desaturation problem that Dave Martindale
experienced. Ed Catmull's paper ``Tutorial on Compensation Tables'' in the
Siggraph 78 or 79 proceedings (sorry, I don't have the reference in front of
me, the title or year could easily be different. Once you find the right
volume, it's the first paper in the proceedings) tells you just about all you
need to know to compensate for the non-linear response of video monitors and
film. The paper includes the code required to do the computations. Just type
it in, do the measurements and run the program.
Other things to do include:
1) Film inside a light-tight enclosure if possible.
2) If you haven't got a light-tight box, make sure that no light can get
into the room. Tape up the cracks around the doors if you have to.
Make sure that any indicator lamps or LEDs that you can't turn off
are taped over, and any CRTs that you can't turn off are turned down
all the way. A light almost anywhere in a room will reflect off a
curved screen into the camera.
3) The light output from a CRT varies strongly with viewing angle.
If you film from too close up, you will notice that the edges
of the screen are much dimmer than the middle, because the camera
views them from a large angle. Use the longest lens you can and
shoot from as far away as possible.
4) Always slate your shots. Every shot should be prefixed with at least
a few frames (24 is a good number) containing as much information as
possible describing the shot. I always include:
Monitor used
Settings of monitor front panel controls
Camera and lens used
Film type, reel number, exposure length, f-stop
Date and time
Who made the shot
Shot name and Take number
Reason for take (e.g. last take aborted, changed exposure, fixed
bug in rendering code, etc.)
If you will be editing the film, its a good idea to put a single
solid white frame (overexposed if possible) immediately before the
first frame of the take, and immediately following the last. This
makes it *much* easier to find the shot when winding the film by
hand, on rewinds or in a moviola. If you don't label your takes,
you will regret it, `maybe not now, but soon, and for the rest of
your life.' I have a program that prompts you for slate information
(it remembers the last slate and re-uses it by default, except for
incrementing the take number) and draws a slate on the screen. It
also saves all slates permanently in a secret place. It's really easy
in the heat of production to forget to keep a record of what you did.
5) If you're doing a lot of shooting, it's a good idea to save it up
until nighttime, start it running and GO HOME! More takes are screwed
up by people interfering than anything else. Besides, you need the
sleep (especially close to deadline time.) Make sure that your
janitors and security staff know not to go near the film room
when the door's closed.
6) Film is cheap. Time isn't. If you're not sure of the right exposure,
run several in a row. The camera will just sit idle while you're at
home asleep anyway.
7) Test early and often. The feedback loop through the color lab is
almost always a bottleneck. If you can overlap color tests with
software development and image rendering, you can save yourself a lot
of boredom (or panic) later on.
Contrary to Dave Martindale, getting good images on film isn't that hard. It
requires patience, attention to detail and a rudimentary understanding of
a lot of things that computer programmers don't normally come in contact with.
But, having done it once, you're set for life.
Actually, there is one problem that can be harder to solve than any other.
Finding a color lab that will process your film repeatably from week to week
can be very difficult if you don't live near New York, Los Angeles or Seattle.
Unfortunately, computer displays are not as forgiving of processing
errors as are natural scenes. No matter how careful you are, if you
can't trust your color lab, you can't trust your pictures.
A good relationship with a lab that does consistent work is worth its
weight in Tektronix stock certificates.
Goodness, I didn't intend to run off at the mouth like this. Film is an
important output medium. 16mm film is roughly the same resolution as
RS170a (500 line) video, and is much cheaper to work with. Motion picture
standards are universal and the equipment to show them is ubiquitous.
Video equipment, especially for large audiences, is unavailable in many venues.
Television standards vary from nation to nation, and conversion from
one standard to another is very expensive (~$400 for a 1 hour NTSC to
PAL transfer, ~$500K to buy the machine to do it) because the market is
extremely small.