re: load brightness, videoconferencing
On Mon, 22 Jan 1996, Paul Chinn wrote:
> Time slicing should not cause the kind of flashing I am seeing which is:
> every so often a frame whose entire brightness is significantly greater
> than normal frames.
Imagine a film camera. Think of what would happen if every now and then
the camera gets distracted while the shutter is open. You'll get an over
> If timeslicing was causing the
> problem, we'd see things like brightness changing part way thru the
> image and it splotches or bands. Plus, consider windows 3.1 which has
> no preemption yet QuickMovie yields a stable image.
I'm doing this from memory, so be prepared for errors.
For the CCD to take a picture, it is told:
1. transfer image array to buffer array and clear it.
2. wait one shutter time
3. transfer image array to buffer array and clear it.
4. Transfer buffer array to output device, pixel by pixel.
Note that step 1 and 3 are the same operation. It's just in step 1, we
care about shifting the dark pixels into the array, in step 3, we care
about the exposed pixels coming out of the array.
If we read the bits out slowly in step 4, the first scanline is ok, but
later scanlines are too bright. When I put a delay after every pixel,
only the first 3 scanlines had anything but white.
I don't think the quickcam has a single atomic command for steps 1,2, and 3.
Usually, it's not a problem, because the comunication delays are short
compared to a shutter time. However, scheduling delays can cause a problem.
One way to deal with the problem is to time sending the first few commands.
If we don't do it fast enough, throw away the frame and try again. In bright
light, it takes a lot longer to transfer am image out the parallel port than
to take it. The longest "shutter time" is measured in seconds.
Paul Haas, paulh@Hamjudo.com, nope, I still haven't put pictures on my