Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!elroy!daemon
From: rgd059@Mipl3.JPL.Nasa.Gov
Newsgroups: comp.sys.amiga
Subject: Re: Video Products
Message-ID: <6207@elroy.Jpl.Nasa.Gov>
Date: 13 Apr 88 07:03:25 GMT
Sender: daemon@elroy.Jpl.Nasa.Gov
Lines: 79

In article <8532@agate.BERKELEY.EDU> doug@eris (Doug Merritt) writes:
>Thanks for the info. Can you get your friend to give us the technical
>specs?

Disclaimer:  I did some of the software for Perfect Vision (the color display
section), so I hardly have an unbiased opinion.  Sorry if you think this is
commercialism, but you asked!

>For instance, how many bits per pixel can it grab for maximum
>quality (does it compare to DigiView's 21 bits per pixel?)

It gets 4 bits per pixel, gray scale.  For color, you get 12 bits.  That's
enough for most Amiga display purposes, since that's all the Amiga can display.
You can adjust brightness and contrast via the hardware, so you don't need the
extra bits for that.  In order to digitize color, you must make three passes,
like DigiView, but each of the passes is MUCH faster.  It works with color or
b&w cameras, VCR's, and TV's.  Currently, color is done via optical filters,
but there is a color splitter box coming RSN that will allow you to digitize
color from a NTSC color source.  With the box, it would take maybe 1.5 to 2
seconds to digitize a color picture (longer to display it, of course).
Resolution is 320X200 or 320X400.  Sorry, no hi-res.  It would add immensely
to the cost.  If we get enough requests, though.... (but it'd be expensive).

>For non-ham
>modes, does it framegrab at exactly ((# bit planes) divided by 60) ?

It grabs all 4 bits in one frame time (1/30 second interlace, 1/60 non-
interlace).  So, it will stop a moving image.  Unfortunately, it takes about
half a second to move the data into the computer (through the parallel port),
so you can get about 2 frames/second burst mode.  Color, of course, takes three
passes, so you must have a still source.  But, even with optical filters, it
can take as little as 5 seconds to digitize color (how fast can you swap
filters?).

>Does it support HAM at all?

Yep!  (that's my baby!)  It will convert to either fast HAM (no color
registers), slow HAM (color regs used to greatly reduce fringing), and 32-color
modes.  You can also lock the palette so it won't change, and it calculates the
best fit for each pixel.

> Do they, perchance, document how to directly
>read their interface themselves?

There is some assembly source included that demonstrate how to read the
hardware.  I believe it's the actual routines used by the software.
Good 'nuff?

>This last point has been a burr in my side for a long time...it'd be
>nice to be able to write my *own* software to grab DigiView images.

DigiView is almost all software, so they'd have to give away most of their
program (at least the meat of it).  Perfect Vision is mostly hardware.

>Similarly for sound samplers. Future Sound was kind enough to send
>me examples of C code to do so for their sampler, but it'd be nice
>if we had a standard way to talk to *any* sound sampler. Like a
>"snd:" device, for instance. I've been meaning to write one for
>Future sound for the last 15 months but it doesn't look like I'm going
>to get around to it after all.

Perfect Sound includes the complete source for the editor program (or at
least an old version of it), including, of course, the digitizing source.
If you get around to writing a device, we'd like to hear about it!

Perfect Vision retails for $219, it's much less mail order.  The color
splitter should be about $80-90 range, but it hasn't been decided yet.  (the
splitter will also work with DigiView...)

If you have any questions, you can call SunRize Industries at (409)846-1311.
Or, you can email me... but I'm not an official representative of SunRize,
I just do some contract programming for them on the side.  (in other words,
I can't sell you one ;-}  )

Oh... someone in an earlier posting mentioned a problem with having to use
a very short printer cable.  That has been fixed, so the newer ones should
work with reasonable-length cables.

Bob Deen  @  NASA-JPL Multimission Image Processing Lab
rgd059@mipl3.jpl.nasa.gov		span:  mipl3::rgd059