Wayne on Micron smearing:
They will not be doing a new rev on the sensor - it is what it is. You only get the smearing for oversaturated pixels but it does kill it for natural lighting. They apparently knew about the problem because they went to a different pixel architecture for the sensor in the SI-3300 - it doesn't smear.

__________________
Silicon Imaging, Inc.
We see the Light!
http://www.siliconimaging.com

DOthan 2ghz chip is in and we are getting 70-85% cpu in Black and WHite preview..this is not good..we got 22% with the 3.06ghz P4..not sure what is going on yet...

also does anyone know if windows 2000 supports SATA disks? it seems that the drives I have (10,000rpm) are not working at a fast datarate..maybe a limit of windows 2000? can someone point me to a good disk speed test .exe for testing the disks on the system?

I agree, if you don't need the thread cut it out. The problem would be different CPU, different achitechture, maybe the main board bios hasn't been updated to support it properly. Consult Intel on coding for your application, and consult mainboard and chipset companies for drivers and bios updates.

Maybe we can get rid of the smear problem by reducing the overload causing it. There are a few ways:

- Use IR and ultra violet cut filters to reduce these emissions from strong light sources, thus reducing the satuation of a pixel compared to the surrounding pixels. As most strong light has high UV or IR content, then this might work very well. If we are extremely lucky the smear problem might be more sensitive to IR or UV.

- One changing gain to compensate (maybe change some on board components, but we aren't up to that, to reduce the circuits max load)

- Increase shutter speed, or use the artifical dual slope technique Steve suggested before (one fast frame and one normal 48th of a second).

- Use a ND filter to get it within limits.

- And playing around with pixel clock and parameters (read out) to see how they effect the smear.

Rolling shutter artifact, as per normal techniques.

So what do you reckon Rob, is it worth going to a camera store for filters to try this out?

Wayne,
I think you could test it out just by stopping down the lens. Sure you will get more DOF, but that shouldn't be related to what you are testing. If you can keep the Micron 1.3Mpix from saturating, any which way, it should be OK. Micron has said that the smearing is inherent in the pixel architecture and they changed that for the 3.2Mpix.

All CMOS color cameras are made with an IR cut filter to keep the colors from being skewed by IR. On some of ours it is built into the sensor cover glass, on others we add it.

__________________
Silicon Imaging, Inc.
We see the Light!
http://www.siliconimaging.com

Yes, thanks, I would like to see if Rob can improve his camera by doing this. Also if it canbe readily done to just the right amount, rather than having to stop everything down by half. If so, then that makes a reliable low end camera available for his software.

First In FIrst Out buffer. Long line of memory cells, circular (when it overflows it is trying to overrite a cell that hasn't been read out). Two pointers, one that pionts to new entry and ine that piont to entry being read. Whn pionters match problems, nothing canbe written (well at least thats a simple FIFO design, maybe more complicated). Different chipsets may have different fifo buffer sizes. So you can monitor how full the fifo is, and buffer anything that won't fit in dram, or findout what the smallest fifo buffers are in any chipset/PCI card/bys chip, and keep writes under this size. N ow I don't know if windows allows you to monitor this though. The problem might also be some timing hickup somewhere else in the computer/code causing data to be written to the fifo in big spurts that are too big to handle.

Because you are getting this problem, my guess is that the system doesn' throttle the FIFO, but that it works most of the time because i is big enough and fast enough to keep ahead of most applications (typical PC stuff). It could also mean that your framerate/pixel size is too for that chipset high.

When I think of it, if you are using dma from dram, then the dma/fifo circuites should throttle it.

the Dothan chip should have a heavy amount of on-chip L2 cache, around 2MB worth. What it doesn't have right now with the 855GME chipset is the memory bandwidth of the Prescott or Northwood on the 800Mhz front-side bus with dual memory channels. For that sort of memory bandwidth, you're going to have to wait till next January for the Alviso chipset which will have a dual-channel memory bus and 533Mhz front-side bus.