2 Replies Latest reply on Mar 19, 2020 6:42 AM by PhMi_4136011

    Stream 10 bit raw bw sensor with active pixel array of 1928 x 1088

    PhMi_4136011

      Hi,

      based on this Thread OV2740 UVC Request to set Exposure time , we were able to grab images and set exposure times.

       

       

      But we still struggle with the pixle format. Since we got a 10 bit raw gray scale sensor, we operate gpif in 16 bit mode (YUV2 with 0x59, 0x55, 0x59, 0x32 in descriptor file). Our sensor got an unusal active pixel array of 1928 x 1088. Does this mean  Streaming RAW10 Format Input Data to 16/24-bit Output Format in CX3 MIPI CSI-2 - KBA224387  won't work for us? The document says, the values need to be a multiple of 16...1928/1088 can't be divided by 16.

       

      Therefore we are currently developing a host application which avoids the problem and erases the unused 6 bits. I attached a two images in .txt format to show a systematic error within the camera picture.

       

      Is this error due to an expected bayer pattern ? We don't know how to handle this problem, is this know to you?

       

      Do we need to use other formats/ descriptor settings?

       

       

      Kind regards,

      Philipp

        • 1. Re: Stream 10 bit raw bw sensor with active pixel array of 1928 x 1088
          RashiV_61

          Hello Philipp,

           

          This KBA Streaming RAW10 Format Input Data to 16/24-bit Output Format in CX3 MIPI CSI-2 - KBA224387 mentions two scenarios:

          Condition 1: when 10 bit data (1 pixel)  is padded with 6 zeros so that total is 16 bits

          Condition 2: when 10 bit data is (1 st pixel) packed with second pixel's data to get 16 bits

           

          As per the project you shared, the mipi configuration structure is

          /* OV2740_RAW10_1080P :  */

          CyU3PMipicsiCfg_t OV2740_RAW10_1080P = 

          {

             CY_U3P_CSI_DF_RAW10,  /* CyU3PMipicsiDataFormat_t dataFormat */

              2,                          /* uint8_t numDataLanes */

              2, /* uint8_t pllPrd */

              89, /* uint16_t pllFbd */

              CY_U3P_CSI_PLL_FRS_250_500M, /* CyU3PMipicsiPllClkFrs_t pllFrs */ 

              CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t csiRxClkDiv */

              CY_U3P_CSI_PLL_CLK_DIV_4, /* CyU3PMipicsiPllClkDiv_t parClkDiv */

              0,                 /* uint16_t mClkCtl */

              CY_U3P_CSI_PLL_CLK_DIV_2, /* CyU3PMipicsiPllClkDiv_t mClkRefDiv */

              1928,         /* uint16_t hResolution */

              50                         /* uint16_t fifoDelay */

          };

           

          Here, CY_U3P_CSI_DF_RAW10, decides that it will pad zeros to the pixel.

          If you change this field to CY_U3P_CSI_DF_YUV422_8_2 the (10 bits) pixels will be packed to 16 bits

           

           

          As in the mipi structure the output video format is CY_U3P_CSI_DF_RAW10, the pixels will be packed with 6 bits of zero. For this you don't have to change the descriptors (the descriptors generated by the tool mentions the frame size of 1928*1088*2 bytes)The host application should be able to discard these extra (padded zero) data from the pixel data.  host applications like VLC, AmCap does not support RAW data format so you would need to develop custom application to discard extra (padded zeros) data.

           

          As per your question, the line size ( i.e 1928 * 10 bits ) should be multiple of 16 bits only when the pixels are to be packed i.e.  video output format mentioned in mipi structure is changed to CY_U3P_CSI_DF_YUV422_8_2.

          The line size is a multiple of  16 bits (1928 *10 / 16 = 1205)

           

          Please let me know if you have queries on this

           

          Regards,

          Rashi

          • 2. Re: Stream 10 bit raw bw sensor with active pixel array of 1928 x 1088
            PhMi_4136011

            Hi Rashi,

            Thanks again for your support.

             

            Our mistake was in the set exposure time function, so the image was exposed wrong and looked faulty.

             

            Our host application is working correct since we added a white balancing and a different demosaicing....

             

            Kind Regards,

            Philipp