Hello Andrey, On Wed, 27 Jan 2010 13:02:30 -0700, Andrey Filippov <[email protected]> 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 _______________________________________________ Support-list mailing list [email protected] http://support.elphel.com/mailman/listinfo/support-list_support.elphel.com
