From: wilson@cs.utexas.edu (Paul Wilson)
Subject: TECH: LCD yields, configurations, cost 
Date: 14 Nov 1995 10:11:39 -0600
Message-ID: <48af3r$7v7@boogie.cs.utexas.edu>
Organization: CS Dept, University of Texas at Austin


From: wilson@cs.utexas.edu (Paul Wilson)

(was Re: PROD: Question on Virtual I/O quality)

In article <47qrn4$sv6@news1.halcyon.com>,
>From: Leo Nikora <Leo_Nikora@vio.com>
>
>The highest resolution available today in full-color miniature LCDs is
>181,470 pixels. This is far below the 640*480*3=921,600 pixels needed
>for full-color VGA resolution.
>
>There are monochrome VGA miniature LCDs available with
>640*480*1=307,200 pixels, but they are very expensive.  We sell a
>version of the "Virtual i-glasses" that uses these monchrome VGA LCDs
>for $3,500.

I'm curious what the cost/performance and engineering issues are here.
It seems to me that most of the inexpensive HMDs use a very
straightforward design with one LCD per eye, and total overlap.  This
doesn't take advantage of the biases and robustnesses in the human
visual system.

I would expect that somebody would make HMD's with four LCD's, two per
eye, with only partial overlap.  I wouldn't think that this would more
than double the cost to manufacture the HMD, and would be vastly
nicer.

One way of doing this would be to have a pair of LCD's per eye, with
nonoverlapped LCD's to the sides and overlapped ones in the middle.
That is, the left half of the left eye's FOV would be handled by one
LCD, and likewise the right half of the right eye's FOV by another.
The right half of the left eye's FOV and the left half of the right
eye's would be handled by a pair of overlapped LCDs to give
stereopsis.

You'd probably want to put the longer axis of each LCD in the vertical
orientation, since with double LCD's per eye, your horizontal FOV
problem is much less critical.

Several possible improvements:

* Don't exactly overlap the central LCD fields of view.
  With a pair of LCD's per eye, you're likely to have a line of
  some sort down the middle (actually, down the sides of the overlapped
  central part).  By making the overlap a little more or less than this,
  you could ensure that the lines in each eye's FOV don't overlap, and
  there is no "blind spot"---everything would appear to at least one
  eye.

* Use cheaper, lower-res LCD's for the sides.  Maybe even monochrome.
  FOV seems important for immmersion, but resolution is much more
  important in the middle. 

* Do optical tricks to enlarge the side LCD's apparent size, and
  put the center LCD's "in the middle" of them.  (Not really the
  middle, though.  E.g., for the left eye:

     +-----------------+
     |                 |
     |                 |
     |                 |
     |        +----------------+
     |        |                |
     |        |                |
     |        |                |
     |        |                |
     |        |                |
     |        |                |
     |        +----------------+
     |                 |
     |                 |
     |                 |
     +-----------------+

  with a mirror-image configuration for the right.  The small (hi-res)
  LCD image in the middle would be the mostly-overlapped one for stereopsis,
  and the other would be for wide FOV; the side LCD's for each eye would
  overlap little or not at all.

  The central ones don't have to be completely overlapped, and could
  be staggered both horizonatlly and vertically.  This would give you
  a kind of three-res FOV: the most central area would be stereoptic
  hi-res, and around that would be regions of mixed res (hi-res to one
  eye, low res to the other) with some stereopsis, and the rest would
  be low-res.

I'm curious what the yield issues are for this sort of thing.  For the
configuration in the diagram above, you'll waste some pixels of the
side LCD's.  Can you get flawed LCD's more cheaply, and use those?
(That is, pixels that aren't visible don't have to work, but the flaws
must be local---the LCD as a whole must work.)

I'm also curious what the basic manufacturing yield issues are in
LCDs.  I would think that most people would rather have hi-res LCD's
with a few dead pixels than flawless lo-res LCD's.  For stereo vision,
I'd think a few dead pixels here and there would be a non-problem for
most people, as long as the flaws were staggered---you wouldn't want a
dead pixel for each eye in the same part of the field of view,
especially near the center.  Randomly-placed dead pixels wouldn't be
so bad---like looking through a hi-res window with a few specks of
dirt on it.  (And of course, from a large lot of slightly flawed
LCD's, you could pick which ones to use for the right or left eye to
place the dead pixels in relatively unimportant areas, like toward the
outer edges.

What are the yield issues here?  Is it easy to manufacture LCD's with
twice the resolution if you're willing to put up with a few dead
pixels?  Or do most flaws kill the whole LCD?

Can somebody get ahold of lots of "flawed" LCD's and cheaply build a
bunch of very nice HMD's?  I would think the LCD manufacturers would
be delighted to have a market for LCD's they'd otherwise just throw
away.  (The side panels in the scheme above might be very cheap in
that case.)  What is the ratio of "perfect" LCD's to slightly flawed
ones?  Are most slight flaws dead pixels (not bad) or stuck pixels
(worse)?

If this is a reasonable idea in manufacturing terms, it seems like a
good area for some simple usability studies.  Experiments could be
done to see if people minded having a dead pixel toward the outer edge
of the nonoverlapped part vs. somewhere in the overlapped part.  (The
former has the advantage that it's not where you're looking most of
the time, the latter has the advantage that there's compensating
information from the other eye, like having a speck on one lens of
your glasses.)

-- 
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (wilson@cs.utexas.edu)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and  Scheme interpreters and compilers available via ftp from 
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)      
