[Elphel-support] mage Noise problem

[Alexander Tsvyashchenko]

Hello Andrey,

On Wed, 27 Jan 2010 13:02:30 -0700, Andrey Filippov <andrey at elphel.com>
wrote:

>> Visually the noise pattern looks completely static - ...
> 
> Alexander, what you see is really sensor "fixed-pattern noise" - the
> different dark signal from the sensor.

Yes, that looked like warm/hot pixels indeed, but my thoughts were that
their level/number was abnormally high. As it appeared this impression was
wrong: it was based on comparison to some images taken by uEye camera with
the same Aptina sensor (and which didn't show anything like that level of
warm/hot pixels), but after I started to investigate the difference
further, it appeared those shots were taken with "hot pixels suppression"
option turned on for uEye camera, and without it large number of warm/hot
pixels is also present at comparable exposures. Sorry for confusion!

[skipped]

> Actually for monochrome sensors I would recommend using that 100% JPEG
in
> "mono" mode over "raw" - it will be much faster and there will be no
> compression loss - 100% in Elphel cameras means literally  100% (as
> suggested by JPEG) - all quantization coefficients are equal to ones, so
no
> quantization is actually performed on the image data. Color sensors
benefit
> from JP4 mode that preserves Bayer color mosaic while having good
> compression ratio.

Thanks for clarification! Am I right assuming that while no information
loss occurs due to quantization, there still some (insignificant?) loss due
to DCT/other parts of compression process?

Also after some experimentation with different RAW/JPEG models I'm a bit
confused as to the exact meaning of "RAW" in 353 camera. What I'd like to
get is the image as close to the one taken by the sensor as possible - so,
no gamma (and also black level?) correction. Here are results I've got so
far:

1. When trying to take images using 8-bit RAW format, result seems to
depend on current values of GTAB_X parameters, suggesting that gamma
correction is in fact applied to this RAW image (???)

2. However, resulting RAW and JPEG images have considerably different
brightness/contrast, suggesting that some parts of processing are done
differently to RAW than JPEG?

3. I've tried to switch gamma correction off by changing GTAB_X values to
0x640400 (as far as I understood parameter description and gamma curve
graph produced by "Gamma Curve Drawing Example" that should be the correct
way to disable gamma + black level corrections?), but the difference
between RAW/JPEG still remains.

4. When trying to use 16-bit RAW, gamma correction seems to be not applied
anymore, but max pixel value is limited to exactly 19128 (even for those
pixels that are clearly fully saturated) - have no idea what this value
means and why it stops there ...

Probably I'm missing something fundamental about the way things are
supposed to work with RAW images here and about the way to get maximally
"untouched" images from camera?

> If you really plan to work with lonfg exposures you can use background
> subtraction - either on the host computer or using FPGA code that allows
to
> subtract fixed patters during image acquisition.

It's not 100% clear for now what exposures exactly final system will use,
but yes - looks like we will have to consider that possibility. Am I right
this is not available in current FPGA code?

Thanks!

-- 
Good luck!                                     Alexander