Noise in CMOS image sensor

[TD]

Hello, I would like to know how to estimate the noise on cmos image
sensors. We have a custom cmos image sensor designed/ manufactured by a
company and we have designed a proto board for hosting the cmos image
sensor with A/D converter, clock, power supply etc which is interfaced
to Analog devices FPGA/ FIFO board to read out the data to the
computer. My question is how do I characterize / estimate noise on the
sensor ? Thanks much...

-TD

 

[TD]

We reconstructed a couple of images from the sensor and we seem to see
the effect of alternate brighter and dimmer pixels. what are the other
noise sources ?

 

[Joerg]

Hello TD,

We reconstructed a couple of images from the sensor and we seem to see
the effect of alternate brighter and dimmer pixels. what are the other
noise sources ?

It's been a long time that I designed a CCD camera but what you most
likely see is the differences between adjacent readout columns. There
will be "gain" differences as well as offsets. That can be corrected
either analog or after the ADC. I did it analog but this was in the
80's, about the time the Rolling Stones came back.

Then there is the dark current which is temperature dependent. Also IR
sensitivity which the mfgs tried their best to muffle.

Most important are squeaky clean row and column clocks with not a speck
of jitter. This also means very quiet power rails. The real kicker was
to know when to sample and then do a proper integrate&hold with tons of
dynamic range. The only thing I found adequate for that task was a
quad-diode switch driven via a nicely symmetrical toroid transformer.
Which of course you couldn't buy back then. This got me about 15dB or so
more dynamic range out of one of the "stone-age" sensors than the data
sheet said.

Regards, Joerg

 

[KoKlust]

computer. My question is how do I characterize / estimate noise on the

sensor ? Thanks much...

-TD

I did designs with a CMOS image sensor.

The pure 'pixel noise' can be calculated as the RMS value of a number of
readings of the same pixel in a certain readout-mode, under certain lighting
conditions.

Be careful to skip the first image(s) after powerup or initialization, use a
repeatable control sequence, start in the (complete) dark, and get rid of
'dead' pixels before you do the calculation.

Noise is usually specified either as a number of electrons. Sometimes
manufacturers only specify the SNR in dB.

I agree completely with Joerg about the cleanliness of the control signals.
Also, optimal signal scaling (using a VGA, and automatically adapting the
shutter speed) can be used to optimize the SNR.

So that is all about 'temporal noise'. Because of variations between pixels,
there is also 'spatial' noise in the image. It is the same for each frame,
so you may be able to correct for these effects by analog or digital
(onchip/offchip) processing.

Spatial noise types:
- variation of the dark response from pixel to pixel (dark signal
non-uniformity, DSNU)
- variation of the offset from pixel to pixel (fixed pattern noise, FPN)
- variation of the sensitivity from pixel to pixel (photo response
non-uniformity, PRNU)

Does this help you?

Best regards,

Marco

 

[TD]

thans for your replies. Its been really helpful

I did a calculation of the "pixel noise"/ temporal variation on a pixel
and found it to be around 2-3 mV. We used a 12 bit A/D converter for
digitizing, and so a 9 or 10 bit A/D seems right with these noise
levels...Our voltage swing is 2V.

Also I estimated the DSNU. One thing I am not able to understand is
when I take the data set on a completely dark condition. I see that
every other pixel shows 0. I thought there will always be some noise in
the sensor/ readout circuitry leading to a non zero value. And the
alternate pixels are around 3mV.

And can you explain this, variation of the sensitivity from pixel to
pixel/ offset from pixel to pixel. I see variations in the pixel values
under uniform lighting conditions, making neighboring pixels brighter
and dimmer.

thanks again,
TD

 

[Joerg]

Hello TD,

I did a calculation of the "pixel noise"/ temporal variation on a pixel
and found it to be around 2-3 mV. We used a 12 bit A/D converter for
digitizing, and so a 9 or 10 bit A/D seems right with these noise
levels...Our voltage swing is 2V.

A 10 bit converter won't cut the mustard here. You need at least 12
bits. An honest and detailed data sheet will show you the effective
number of bits (ENOB) versus frequency. Many converters drop almost two
bits when being used at more than half the maximum clock frequency. So
from a noise perspective that 10 bit converter might really behave like
8.5 bits or worse. I think TI has a nice fast 16 bitter.

Also I estimated the DSNU. One thing I am not able to understand is
when I take the data set on a completely dark condition. I see that
every other pixel shows 0. I thought there will always be some noise in
the sensor/ readout circuitry leading to a non zero value. And the
alternate pixels are around 3mV.

Zero is not normal. There always is some noise and it should certinly no
be this non-uniform. Could the array be damaged?

And can you explain this, variation of the sensitivity from pixel to
pixel/ offset from pixel to pixel. I see variations in the pixel values
under uniform lighting conditions, making neighboring pixels brighter
and dimmer.

Offsets and variations are normal, see my previous post. If you observe
neighboring pixels of an illuminated area increase in value even though
they weren't illuminated that is usually caused by charge bleeding into
their cells. Often this is called "blooming". Mostly that happens when
you exceed the maximum charge in a pixel cell. I guess Shakespeare would
have said "the bucket overfloweth".

It's hard to guess what really happens on your array because none of us
knows how it's laid out. If you were at liberty to post the architecture
that would help a lot.

Regards, Joerg

 

[TD]

Hello Joerg, Thanks again for your suggestions.

Zero is not normal. There always is some noise and it should certinly no
be this non-uniform. Could the array be damaged?

We are reading out 4 channels of data from the CMOS sensor
corresponding to columns that are interdigitated. and we are reading
out the data row wise. When I view the data, I see there are 0
digitized values on only one of the channels ( so it may have been some
specified columns in the array) But we tried imaging a number of
different objects and the reconstructed image looks very good except
for FPN. So defintely the array doesnt seem to be damaged. aaha I think
I may have found out why it happens.

The A/d converter digitizes differential input from -1 to 1V. and hence
anything below -1v is reported as 0. I think what may have happened
here is we have an offset control for the analog output swing, probably
and hopefully its swinging from -1.2 to 0.8 or -1.1 to 0.9 instead of
-1 to 1V. and hence ADC reports these as 0s. (I also do not remember
digitized value reaching 4096, always a little lower) But I have to
see how I can control the offset and verify this....

Offsets and variations are normal, see my previous post. If you observe
neighboring pixels of an illuminated area increase in value even though
they weren't illuminated that is usually caused by charge bleeding into
their cells. Often this is called "blooming". Mostly that happens when
you exceed the maximum charge in a pixel cell.

But I see this pattern occuring even the pixels are not saturated. I
see this effect at almost all light levels.
I do not have the entire architecture and I am not allowed to post what
I have due to proprietary reasons.

Regards,
TD

 

[Joerg]

Hello TD,

The A/d converter digitizes differential input from -1 to 1V. and hence
anything below -1v is reported as 0. I think what may have happened
here is we have an offset control for the analog output swing, probably
and hopefully its swinging from -1.2 to 0.8 or -1.1 to 0.9 instead of
-1 to 1V. and hence ADC reports these as 0s. (I also do not remember
digitized value reaching 4096, always a little lower) But I have to
see how I can control the offset and verify this....

That would explain it. Offset controls for CCD are a very touchy
subject. They usually aren't meant to ease the life of the guy that has
to design the interface. In my CCD days about 20 years ago I used a
Philips NXA sensor. It was very particular about any of its DC levels.

But I see this pattern occuring even the pixels are not saturated. I
see this effect at almost all light levels.

Again, offset and transfer factor (often called gain) deviations are
part of life with CCDs. Not just between columns but also rows if the
readout occurs via more than one row at the bottom. In my case it was
three rows. I don't remember how many columns I had. I think it was four
like on your array.

Offsets can be measured. Usually (hopefully...) the manufacturer has
provided a covered blank pixel for each column. Then you can detect and
clamp on that value which will restore the DC bias for each columns.

Transfer function deviations are more difficult. Basically you'd have to
calibrate for that, using the cal values as coefficients to scale the
readout values.

I do not have the entire architecture and I am not allowed to post what
I have due to proprietary reasons.

That's understandable. But you as the circuit designer must have the
entire architecture. I don't know how else you could achieve optimum
performance.

Assuming you get raw and unsampled pixel output from the array: Do you
have a proper integrate and hold circuit? That makes a huge difference
in uniformity and also in dynamic range. Resist the temptation to just
kind of add the row outputs together and send them through some RC.
That's what the app notes for my array had originally suggested. The
difference between their sample camera and the new one was stunning.

Regards, Joerg