[net.graphics] Graphics to VCR, Help

cranmer@trwrba.UUCP (Daniel N. Cranmer) (10/26/84)

Hello,

	Does any one know of a set up that allows one to use a video cassette
recorder to record graphics directly from the computer. One of the problems
we have noted is that our high resolution graphics monitors are too high-res
for normal TV. Also the problem of recording via a camera leaves a lot to be
desired. Any help would be appreciated. (Thanks!)

		TRW
		Dan Cranmer
		One Space Park 92/3385
		Redondo Beach, CA 90278
		(213)535-4509

herbie@watdcsu.UUCP (Herb Chong, Computing Services) (10/28/84)

As far I as know, using a VTR/VCR designed for the NTSC broadcast system
will not record to high enough resolution to use even on an IBM PC screen
at high res.  It limits you to about 300 by 200 pixel resolution unless
you have an exceptional VTR/VCR.  Most people that I have heard of doing this
use special recorders.  I don't know whether these are custom built or modified.The bandwith of signal of a VTR/VCR isn't high enough unless you do things like
increase the speed of tape and/or the head rotation.

Herb...

I'm user-friendly -- I don't byte, I nybble....

UUCP:  {decvax|utzoo|ihnp4|allegra|clyde}!watmath!watdcsu!herbie
CSNET: herbie%watdcsu@waterloo.csnet
ARPA:  herbie%watdcsu%waterloo.csnet@csnet-relay.arpa
BITNET: herbie at watdcs,herbie at watdcsu

dmmartindale@watcgl.UUCP (Dave Martindale) (10/29/84)

There are at least three different issues involved when trying to
record computer graphics output on VTR's.

The first is matching the format of the frame buffer to the NTSC video
standard, in terms of the number of pixels displayed.  NTSC provides
484 full lines of video, interlaced.  You thus need a frame buffer that
displays about that many lines.  1024x1024 displays just cannot be
encoded directly into NTSC format.  Also, the frame buffer has to be
able to put out the data in an interlaced format: all the even lines in
one field, all the odd ones in the next field.  The number of pixels
horizontally doesn't matter as much, as long as the horizontal sweep
rate is about 15.73KHz.  However, the resolution that will actually be
visible on the screen in the horizontal direction will be between
300-400 pixels in luminance (brightness) with somewhat less colour
resolution.  So displaying a vertical line that is only one pixel wide
will not look very good if it is a different colour from the
background.  These are fundamental (bandwidth) limitations of the NTSC
standard and cannot be bypassed if you are using standard video
equipment.

The next problem is synchronization.  NTSC specifies a horizontal sweep
of 15734 Hz, a vertical sweep of 59.94Hz, a particular number of lines
of vertical blanking, and a particular structure of the pulses during
the vertical interval.  Some frame buffers don't put out video that
looks anything like this standard at all; 1000-line systems usually use
a 32KHz horizontal sweep, for example.  Some frame buffers that are
designed to be displayed on standard TV have the rates "about right"
and may be good enough for the TV to lock onto, but not good enough for
a VTR to handle.  Only a few frame buffers provide real, RS170 (NTSC)
sync in their video signals.   Another way of getting good sync is to
use a standard TV sync generator, and lock your frame buffer to it;
again only a few frame buffers seem to provide external sync
capability.

The last problem is encoded signal quality.  The TV encoders that
generate RF for feeding to a TV set seem to be pretty awful.  Even the
cheap (all-in-one) RGB-to-NTSC encoders are not very good.  But if you
get a broadcast quality NTSC encoder (intended for encoding the output
of a studio colour camera) and your frame buffer puts out RGB signals
compatible with this encoder, you can get quite good results (subject
to the bandwidth limitations mentioned above).

In the computer graphics lab at Waterloo, we have a Leitch sync
generator and a Cox NTSC encoder (both intended for TV studio use).
The frame buffer in use is an Adage/Ikonas RDS3000, which handles
external sync plus has enough flexibility in its video timing to fit
either a 512x484 or 640x484 into the video frame.  We record on an
ordinary Sony U-Matic 3/4 inch recorder, though the video produced is
standard so any sort of NTSC VTR would work.  The quality is
surprisingly good.

However, for this quality of equipment, you'll have to spend $5K+, and
it takes an oscilloscope to set it up properly.  And, of course, the
Ikonas is not included in that price.  Generating good-quality video is
not cheap, at the moment.

If you have a graphics system of some sort that cannot be coerced into
producing NTSC timing of its signal at all, then there are "black
boxes" that can convert video from a variety of formats to NTSC video.
They are basically frame buffers in their own right, which digitize the
incoming signal and store it in memory using the timing of the incoming
signal, simultaneous with the contents of memory being scanned and
turned back into video at NTSC rates.  Cox makes one; other
manufacturers must do so as well.  They are all likely to cost $10K+.

To understand better what is going on in the process of generating video
signals, try borrowing a book on television engineering from your nearby
university library.

	Dave Martindale
	Computer Graphics Lab
	University of Waterloo

keithd@cadovax.UUCP (Keith Doyle) (10/31/84)

A cheaper, but perhaps not as effective method would be to go to film
first and then convert back to video.  Unfortunately it may be necessary
to single frame the film in order to avoid obnoxious sync bars on the film.
If the computer can control the shutter of the camera, and can 'single shot'
or accurately control the video output so that each camera exposure contains
a consistant number of vertical sweeps of the picture, the entire process
can then be automated via program control.  It's concievable that this
could be done with very low budget equipment, (super 8 etc..) if price
is important, and the resultant film can then be transferred to whatever
format video you like by local film or video labs.

However, I have no idea what effect this will have on the resultant resolution
of the final video tape.  Turn around time is also very long, but you get
what you can pay for.

Keith Doyle
{ucbvax,decvax}!trwrb!cadovax!keithd

dmmartindale@watcgl.UUCP (Dave Martindale) (11/02/84)

Re using colour film as a way of getting good video:
There definitely is equipment around that will do high-quality transfer
from film to video.  The equipment itself is very expensive, but you should
be able to pay someone to do the transfer.

However, getting good images on film isn't easy.  Just photographing the
face of the monitor doesn't work too well - the colours seem to desaturate
a lot (we tried doing some animation tests using exactly this technique).
There are devices around that are designed specifically for producing
good-quality photographic images; typically they use a black&white CRT
and colour filters to generate colour images.  One real advantage of such
equipment over video equipment that generates NTSC directly is that your
frame buffer doesn't need to accept an external sync signal.  Anything
that the camera's monitor will lock to is fine.

On the other hand, to produce good, stable animation on film, you need
a film transport for your camera which holds a fair length of film and
uses pin registration of the film for precise positioning from one frame
to the next.  Such a camera might cost you almost as much as the video
equipment I mentioned, but in cases where you can use the final output
on film, the quality can be much better than standard television can
ever provide even on the best possible equipment.

A difference between this approach and generating video directly is
that the direct-to-video approach allows you to record in real time and
only in real time (unless you have a VTR which can record single
frames, still a very expensive item - $75000), while a film cameras
allows you to record only in non-real time.

So the video approach allows you to record interaction as it happens,
while film is much better for recording animation.