From: wilson@cs.utexas.edu (Paul Wilson) Subject: Re: TECH: LCD yields, configurations, cost Date: 24 Nov 1995 15:10:18 -0600 Message-ID: <495cbq$djo@boogie.cs.utexas.edu> Organization: CS Dept, University of Texas at Austin From: wilson@cs.utexas.edu (Paul Wilson) In article <48kvq4$j1f@news1.halcyon.com>, Leo Nikora wrote: > [...] >wilson@cs.utexas.edu (Paul Wilson) wrote: > >>... >>I would expect that somebody would make HMD's with four LCD's, two per >>eye, with only partial overlap. >>... > >Partial overlap has two major problems. First, with the possible >exception of an SGI Reality Engine, there aren't many sources (games, >TV, etc.) that generate partially overlapped images. This might be >solved in the future, but there's always the chicken-and-egg quandary. Yeah, I kinda figured that. But it doesn't seem hard, at least in the simple forms. If you're imaging two (stereo) images anyway it should be trivial to cut each image in two pieces one way or the other. If you have a fairly good scalable graphics image, I'd think it wouldn't be two hard to simply image the outside panels separately----they don't overlap anyting on the inside panels, and the initial FOV clipping will quickly eliminate anything that's already been drawn for the inside panels. >Second, the area of overlap always appears brigher than the rest of >the image. This might be solved by complex brightness controls, but >that keeps driving costs up. If you just image four views in software (see above about quick clipping to avoid wasted/redundant work), you could image them with different brightness levels depending on whether they're the overlapped panels or the nonoverlapped panels. (Again, I'm talking about the really simple version, where you just have two fully overlapped central panels and two nonoverlapped outer panels.) Another alternative would be to simply make the outside LCD's brighter, which doesn't seem hard. It might not be perfect, because there maybe scaling issues when the overall scene brightness changes and so on, but I'll bet it would be good enough for most people, given that they'd get much better FOV and resolution. (Alternatively, a darkening filter over the inside panels could do the adjustment, but it seems a shame to sacrifice brightness/contrast in the middle; you'd rather overdrive the outer panels a little.) This seems like something that would be easy to experiment with given a hi-res HMD and some simple software hacks. > >>... >> 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. >>... > >There are two kinds of LCD pixel defects: stuck-on, and stuck off >(dead). Even a few stuck-on pixels are extreemly annoying, and >destroy the emersive effect. Stuck-off pixels are less objectionable, >but binocular summation seems to add them rather than cancle them. So >two LCDs with 5 dead pixels each looks like one image with 10 dead >pixels. This problem is exacerbated with moving images because then >the stationary defective pixels seem to be in motion, and the eye >notices them. Hmmm... I'd guess that the problem is that the pixels are on the wrong side of the optics, and give the effect of being projected out onto the virtual world. If they were on the near side of the optics, they'd be defocused and much less objectionable---like specks on specs, which millions of people live with every day, even if they don't like them. One way to fix this would be to put a speck on the near side of the optics to mask the dead or stuck pixel. This is annoying because it requires a customized speck mask built for each individual HMD. If I could afford a hi-res HMD, I'd be happy to build my own speck mask. One way to do this is to identify where the specks are, and then print a mask with corresponding specks using a laserprinter and transparent film. Pop the film into the HMD and you're done. This is actually pretty easy to automate. Write a simple program that turns on one pixel at a time and uses a very cheap camera to notice what steps don't work. First try black-on-white to find stuck-on pixels, then try white-on-black to find stuck-off pixels. A semiautomatic (no camera version) would be very easy to implement. Just have a tester look at an all-white image and roughly identify the coordinates of the stuck-off pixels, then run the try-it-out pixel-flipping program to exactly identify which pixel is stuck. Then do the same with an all-black image to find the stuck-off pixels. This could be sped up a little by using images that have fairly fine grids and markers on them, e.g., 6 pixels apart, with two sets of grid alignments so that you don't miss any pixels that are hidden by the grid or the coordinate labels. I'd think that this would allow a tester to identify the stuck pixels in about two minutes, and enter their coordinates into a mask-printing program in another two minutes, and print the thing out in another two minutes and pop it in and try it in another two. About 10 minutes of unskilled labor per HMD, which seems pretty cheap. >Today's miniature LCDs were designed for camcorder viewfinders, and in >my opinion have made a good (and perhaps the best) resolution-defect >trade off. Except that they're trying to make perfect LCD's as cheaply as possible, rather than "good enough" LCD's that minimize cost per unit area. (Also, they don't have the same interactions with the human visual system, e.g., stereo views that somewhat mask single-eye defects (if they occur on the near side of the optics) and wide views where the outside is not critical.) -- | 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/)