[Elphel-support] mage Noise problem

[Andrey Filippov]

>
> 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?
>

Alexander,


There is enough precision in DCT, no color conversion in mono/jp4 modes, so
no other sources of errors. The restored images differ less than 1 count.

>
> 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.


In 8-bit mode the gamma (as well as optional subtraction/multiplication by
the provided array) "gamma" converter is not bypassed (otherwise 4 bits of
the senor 12 bits would be wasted), in 16-bit mode "gamma" is bypassed. I
did not use it for quite some time so I'm not sure why the maximal value is
19128 - to my knowledge it should be limited by 0x7fff. Different sensor
have different number of bits and they data is left-shifted to have the same
range. It may be related to - I'll probably need all the other settings in
your camera to find reason.

But as I wrote above - I did not use that 2 bytes/pixel mode for quite a
while for the reasons explained in
http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/How-many-bits-are-really-needed-in-the-image-pixels/(unfortunately
after they updated their site the illustrations and
javascript calculator were gone). Gamma conversion with gamma=0.5 (square
root) perfectly matches the noise performance of the sensor, so compressing
12 bits -> 8 bits and then expanding them back on host will not increase the
error above the naturally present http://en.wikipedia.org/wiki/Shot_noise in
the sensor with FWC~=8500e-. The "raw" data output is designed for
troubleshooting the FPGA algorithms and it is not optimized for speed (PIO
vs. DMA), because it does not provide additional information from the sensor
but is too slow to put data through the network at the full frame rate.

Black level - by default we have internal sensor black level compensation
turned on. With default settings it adjusts internal analog circuits to
provide dark level output of 0xa0 , so scaled to 8-bits it is 0x0a - the
value that is subtracted by default during "gamma" conversion. Of course,
you can make zero "fatter" if needed.


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 (???)
>
Yes, that is correct. ADC provides 12 (> 8bits). But if you want you can
always make gamma==1.0 (that will waste 4 LSBs)

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?
>
Do you have camera set in monochrome (not color) mode? Autoexposure/balance
turned off?


> 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.
>

Can you provide some example images? Last time I was testing raw it did
match the compressed output

>
> 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 ...
>

Yes, in 2-byte mode gamma is not needed as ADC provides less than 16 bits.
Why did you get 19128 - I'm not sure, data is limited by maximal positive
short (with 12-bit ADC it is actually0x7ff8), I need to look at the other
parameters settings in your case. I tried such raw file on my camera,
converted it with Imagemagick to 8-bit png at it appears exactly as I
expected - saturated by 50% of the full scale (most significat bit is always
0). Here is the screenshot -
http://community.elphel.com/screenshots/raw_15bits.png , and here is the
file itself - http://community.elphel.com/files/raw/image_16_01.raw (Image
is not that great - sensor is actually color, so there is a Bayer pattern,
and there is red filter in front of the lens ).


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


16-bit raw image is virtually untouched by the FPGA ADC output, the only
conversion is a reversable "out=in<<3" to match the output range for
different resolution sesnors (sensor still maintains avarage black level at
160 ADC counts if not specifically disabled),  but I would recommend you to
use regular 100% JPEG, black level=10/256 (in the camera parameters it is 8
bit value so it is left shifted by 7 before subtraction from a 15-bit value)
and gamma=50%. Then un-apply the gamma on PC side, MakerNote in Exif header
contains gamma, black level and analog gain(s) values, so it is possible to
make precise correction based on the image itself.


> 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?
>

Subtraction - yes, it is available, but in your case it could be easier to
make it on the PC side. The problem wityh subtraction of the dark image is
that you need to have the reference image acquired at the same temperature
and exposure as the real one. And camera does not have mechanical shutter to
automate that process, so it is easier to make it application-specific on
the host side.

Andrey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20100129/f7686ecc/attachment-0002.html>