Hi Tao,

As the camera  relies on normal image processing for its operation, the easiest 
thing will be to disable most automatic functionality and use Python program to 
directly interface the FPGA, read data array. We will create instructions, but 
there will be no significant difference for your image processing algorithms as 
I explained in my reply to Allen. This mode is mostly for the testing of the 
camera itself, its FPGA and it does not improve 3-d reconstruction, there are 
other much more efficient ways to do that.


---- On Tue, 27 Mar 2018 03:15:34 -0700 Tao 
Zhang<tao.zh...@blacksesame.com.cn> wrote ---- 

    Hi Andrey,
 We now can restore 12 bit as the method you described. But that 12 bit is 
lossy. We want lossless 12 bit or 10 bit data from camera to verify our 
algorithm. Can you help give that guide?
  Tao Zhang
 章   涛
   发件人: Allen Yin 
 发送时间: 2018年3月27日 16:34
 收件人: Elphel Support <support-list@support.elphel.com>
 抄送: Pioneer Li <pioneer...@blacksesame.com.cn>; Tao Zhang 
<tao.zh...@blacksesame.com.cn>; Qun Gu <qun...@blacksesame.com>; 
Winston Zhang <winston.zh...@blacksesame.com.cn>
 主题: 答复: [Elphel-support] 答复: 答复: 答复: 答复: 答复: sync stereo with lidar
 Hi Andrey,
 Could we bypass the “gamma” module in the FPGA?  We want the original raw data 
from sensor.
 Allen Yin
   发件人: Elphel Support <support-list@support.elphel.com> 
 发送时间: 2018年3月22日, 星期四 23:23
 收件人: Allen Yin <allen....@blacksesame.com.cn>; Elphel List 
 抄送: Pioneer Li <pioneer...@blacksesame.com.cn>; Tao Zhang 
<tao.zh...@blacksesame.com.cn>; Qun Gu <qun...@blacksesame.com>; 
Winston Zhang <winston.zh...@blacksesame.com.cn>
 主题: Re: [Elphel-support] 答复: 答复: 答复: 答复: 答复: sync stereo with lidar
 ~/.imagej/Eyesis_Correction.xml is not really needed - it just hides/reveals 
some experimental buttons on the interface
 This is the contents of such file:
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
 <comment>last updated Thu Sep 08 14:09:47 MDT 2016</comment>
 <entry key="ADVANCED_MODE">False</entry>
 <entry key="DCT_MODE">False</entry>
 <entry key="MODE_3D">False</entry>
 result.jpg looks correct. It should be super-contrast as it is linear, so it 
CAN NOT be saved as JPEG - it needs either 16 bits or 32 bit TIFF as when you 
save it from imageJ (save as tiff). And it is "monochrome" - each pixel 
corresponds to the sensor pixel value. For you application I would recommend to 
use just green subchannel (checkerboard pattern, half of all pixels) - in that 
case you do not need to have aberration correction.
 Your plots for gamma seem correct too, to be sure I need to look into the code 
again - I wrote that part several years ago.
 Gamma is not changed automatically in the camera, but you may change it using 
one of the interfaces - camvc of just parsedit. In addition to the power (0.57) 
there is another parameter - dark level - the sensor adjusts its ADC to have 
output level of 160 (on 4096 scale) or 10(256) for the complete darkness, 
so-called "fat zero". 
 Gamma is applied inside the FPGA and parameters are saved in the Exif header, 
so for processing it is possible to "undo" gamma and restore linear scale.
 ---- On Thu, 22 Mar 2018 00:58:53 -0700 Allen 
Yin<allen....@blacksesame.com.cn> wrote ---- 
    Hi Andrey,
 There seems to be an another error, “2.jpg”. 
 I have some doubts, could you please help me?
 1.     Does gamma value remain unchanged when camera works ?  Who realize this 
gamma mapping, sensor or ISP?
 2.     When gamma0 = gamma1 = gamma2= gamma3 = 0.57, gamma_scale0 = 
gamma_scale1 = gamma_scale2 = gamma_scale3 = 1024,
  gamma mapping  is  Vout = a*Vin^gamma, a = 2.23  gamma = 0.57 , is it right? 
If not right, could you tell me the right? I use this gamma curve to convert 
the 12bit raw data, “result.jpg” is the result.
Support-list mailing list 

Support-list mailing list

Reply via email to