<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>i.MX Processorsのトピックi.MX8QM CSI-2 RAW 10 Bayer Processing</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/i-MX8QM-CSI-2-RAW-10-Bayer-Processing/m-p/1675073#M208048</link>
    <description>&lt;P&gt;Summary of support ticket regarding integration of RAW10 Bayer GRBG CSI-2 cameras on a i.MX8QM platform.&lt;/P&gt;&lt;P&gt;- How can RAW10 can be capture via the i.MX8QM ISI ?&lt;BR /&gt;- How to process the Bayer GRBG into RGB/YUV ?&lt;/P&gt;&lt;P&gt;&lt;U&gt;CAMERA CAPTURE&lt;/U&gt;&lt;/P&gt;&lt;P&gt;To validate RAW capture, the camera stream was configured to send specific pattern in the&amp;nbsp;Bayer GRBG :&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;G 0x0345 R 0x0123&lt;BR /&gt;B 0x02EF G 0x1AB&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;RAW16 Format&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump cam.raw | head&lt;BR /&gt;0000000 3450 1230 3450 1230 3450 1230 3450 1230&lt;BR /&gt;0000f00 2ef0 1ab0 2ef0 1ab0 2ef0 1ab0 2ef0 1ab0&lt;BR /&gt;==&amp;gt;&amp;gt; Left shift 4-bit&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;RAW8 Format&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump -C cam.raw | head&lt;BR /&gt;00000000 50 30 50 30 50 30 50 30 50 30 50 30 50 30 50 30 |P0P0P0P0P0P0P0P0|&lt;BR /&gt;00000f00 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 |................|&lt;BR /&gt;==&amp;gt;&amp;gt;&amp;nbsp;Left shift 4-bit, 8-lsb kept&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;RAW10 Format&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump -C cam.raw | head&lt;BR /&gt;00000000 00 14 00 8c 00 14 00 8c 00 14 00 8c 00 14 00 8c |................|&lt;BR /&gt;*&lt;BR /&gt;00000f00 00 bc 00 ac 00 bc 00 ac 00 bc 00 ac 00 bc 00 ac |................|&lt;BR /&gt;*&lt;BR /&gt;==&amp;gt;&amp;gt; Left shift 4-bit with an additional 6-bit left shift&lt;/P&gt;&lt;P&gt;G 0xD1400 R 0x48c00&lt;BR /&gt;B 0xBBC00 G 0x6AC00&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;NXP Support Update&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;For all RAW data, ISI can only choose RAW16 to receive and save the data to memory.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;In the reference manual: ISI register&amp;nbsp;CHNL_IMG_CTRL, FORMAT field&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;001100b - RAW10 - 10-bit RAW data packed into 16-bit WORD with 6 LSBs waste bits&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;NXP Support Update&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;This description is wrong, and internal team has submitted a ticket to modify this. As the Note says, "bit[15-14] and bit[3-0] being padding", but ISI cannot read from bit 13. It always reads from the start of those 16 bits and length of 16. So, the first two bits and last four bits are waste bits. Not the LSBs.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;This would match the note in CSI-2 Rx Controller description&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;The CSI data is right LSB aligned and zero padded depending on data format. When interfacing ISI, CSI data is shifted 6-bits due to ISI bits [5:0] always being zero (0bxxCSIDATAxxxxxx).&lt;/P&gt;&lt;P&gt;All RAW14, RAW12, RAW10,RAW8, and RAW6 video data is filled from BIT[13] to LSB, the remaining bits are zero padded. Only RAW16 input data will be saved to memory from BIT[15] to LSB.&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;This RAW data is shifted which makes it hard for direct processing from a Y16 or Y8 buffer.&lt;BR /&gt;Testing showed that some RGB and YUV may be able to capture the 8-lsb.&lt;/P&gt;&lt;P&gt;ISI Format 18 - YUV444_3P8P&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump -C cam.raw -s $((1920*1080*3)) | head -n 4&lt;BR /&gt;005eec00 45 23 45 23 45 23 45 23 45 23 45 23 45 23 45 23 |E#E#E#E#E#E#E#E#|&lt;BR /&gt;*&lt;BR /&gt;005ef380 ef ab ef ab ef ab ef ab ef ab ef ab ef ab ef ab |................|&lt;BR /&gt;*&lt;BR /&gt;G 0x0345 R 0x0123&lt;BR /&gt;B 0x02EF G 0x1AB&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Above the LSB of our bayer data are there. Storing in 3 planes allows to access the data directly. This may help for RAW8 ISI capture by keeping only the relevant plane.&lt;/P&gt;&lt;P&gt;Testing with&amp;nbsp;YUV444_3P10 only reported the 8-lsb shifted by 8 being saved, thus not able to get RAW10 this way.&lt;/P&gt;&lt;P&gt;&lt;U&gt;BAYER Processing&lt;/U&gt;&lt;/P&gt;&lt;P&gt;Bayer is not supported natively by the i.MX8QM. NXP GPU SDK has example of Bayer conversion using the GPU :&lt;BR /&gt;-&amp;nbsp;&lt;A href="https://www.nxp.com/docs/en/application-note/AN12060.pdf" target="_blank" rel="noopener"&gt;https://www.nxp.com/docs/en/application-note/AN12060.pdf&lt;/A&gt;&lt;BR /&gt;-&amp;nbsp;&lt;A href="https://github.com/nxp-imx/gtec-demo-framework/tree/master/DemoApps/OpenVX/SoftISP" target="_blank" rel="noopener"&gt;https://github.com/nxp-imx/gtec-demo-framework/tree/master/DemoApps/OpenVX/SoftISP&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;NXP Support Feedback&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;STRONG&gt;If the SoC is configured for both GPU to be independent, could they be used independently to perform BAYER conversion ?&lt;/STRONG&gt;&lt;BR /&gt;Yes. Just refer to&amp;nbsp;&lt;A href="https://www.nxp.com.cn/docs/en/user-guide/i.MX_Graphics_User's_Guide_Linux.pdf" target="_blank" rel="nofollow noopener noreferrer"&gt;https://www.nxp.com.cn/docs/en/user-guide/i.MX_Graphics_User's_Guide_Linux.pdf&lt;/A&gt;&amp;nbsp;8.3-8.4, app can get GPU ID by clGetDeviceIDs, and assign current softISP application to specific&lt;A href="https://gpu.to/" target="_blank" rel="noopener"&gt;GPU.to&lt;/A&gt;use two GPU, it may need two softISP software running, and assign each softISP to a target GPU.&amp;nbsp;Currently softISP uses Opencl, which not support multiple GPUs.&lt;/P&gt;&lt;P&gt;I checked with softISP owner, it is said opengles may support multiple GPUs, you can try to do your own porting.&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Processing Bayer GRBG with the i.MX8 GPU may be possible with the following work&lt;BR /&gt;- update the soft ISP from Bayer BGGR to Bayer&amp;nbsp;GRBG (for our case)&lt;BR /&gt;- update the soft ISP for 4-bit shifted&amp;nbsp;RAW10&amp;nbsp;data&amp;nbsp;(0bxxCSIDATAxxxxxx)&lt;BR /&gt;-&amp;nbsp;enable 2 GPU for multiple concurrent buffer processing (4 camera streams in our case)&lt;BR /&gt;- perform capture pipeline ( ISI -&amp;gt; GPU -&amp;gt; Memory ) (GStreamer integration ?)&lt;BR /&gt;- hope for good performance ( 30fps ?, at least above 15fps ?)&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;We will look at camera with RGB/YUV support for better compatibility.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Thanks&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/207913"&gt;@hector_delgado&lt;/a&gt;&amp;nbsp;for your support.&lt;BR /&gt;Stan&lt;/P&gt;</description>
    <pubDate>Fri, 23 Jun 2023 17:32:05 GMT</pubDate>
    <dc:creator>sbertrand</dc:creator>
    <dc:date>2023-06-23T17:32:05Z</dc:date>
    <item>
      <title>i.MX8QM CSI-2 RAW 10 Bayer Processing</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/i-MX8QM-CSI-2-RAW-10-Bayer-Processing/m-p/1675073#M208048</link>
      <description>&lt;P&gt;Summary of support ticket regarding integration of RAW10 Bayer GRBG CSI-2 cameras on a i.MX8QM platform.&lt;/P&gt;&lt;P&gt;- How can RAW10 can be capture via the i.MX8QM ISI ?&lt;BR /&gt;- How to process the Bayer GRBG into RGB/YUV ?&lt;/P&gt;&lt;P&gt;&lt;U&gt;CAMERA CAPTURE&lt;/U&gt;&lt;/P&gt;&lt;P&gt;To validate RAW capture, the camera stream was configured to send specific pattern in the&amp;nbsp;Bayer GRBG :&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;G 0x0345 R 0x0123&lt;BR /&gt;B 0x02EF G 0x1AB&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;RAW16 Format&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump cam.raw | head&lt;BR /&gt;0000000 3450 1230 3450 1230 3450 1230 3450 1230&lt;BR /&gt;0000f00 2ef0 1ab0 2ef0 1ab0 2ef0 1ab0 2ef0 1ab0&lt;BR /&gt;==&amp;gt;&amp;gt; Left shift 4-bit&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;RAW8 Format&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump -C cam.raw | head&lt;BR /&gt;00000000 50 30 50 30 50 30 50 30 50 30 50 30 50 30 50 30 |P0P0P0P0P0P0P0P0|&lt;BR /&gt;00000f00 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 f0 b0 |................|&lt;BR /&gt;==&amp;gt;&amp;gt;&amp;nbsp;Left shift 4-bit, 8-lsb kept&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;RAW10 Format&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump -C cam.raw | head&lt;BR /&gt;00000000 00 14 00 8c 00 14 00 8c 00 14 00 8c 00 14 00 8c |................|&lt;BR /&gt;*&lt;BR /&gt;00000f00 00 bc 00 ac 00 bc 00 ac 00 bc 00 ac 00 bc 00 ac |................|&lt;BR /&gt;*&lt;BR /&gt;==&amp;gt;&amp;gt; Left shift 4-bit with an additional 6-bit left shift&lt;/P&gt;&lt;P&gt;G 0xD1400 R 0x48c00&lt;BR /&gt;B 0xBBC00 G 0x6AC00&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;NXP Support Update&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;For all RAW data, ISI can only choose RAW16 to receive and save the data to memory.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;In the reference manual: ISI register&amp;nbsp;CHNL_IMG_CTRL, FORMAT field&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;001100b - RAW10 - 10-bit RAW data packed into 16-bit WORD with 6 LSBs waste bits&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;NXP Support Update&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;SPAN&gt;This description is wrong, and internal team has submitted a ticket to modify this. As the Note says, "bit[15-14] and bit[3-0] being padding", but ISI cannot read from bit 13. It always reads from the start of those 16 bits and length of 16. So, the first two bits and last four bits are waste bits. Not the LSBs.&lt;/SPAN&gt;&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;This would match the note in CSI-2 Rx Controller description&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;The CSI data is right LSB aligned and zero padded depending on data format. When interfacing ISI, CSI data is shifted 6-bits due to ISI bits [5:0] always being zero (0bxxCSIDATAxxxxxx).&lt;/P&gt;&lt;P&gt;All RAW14, RAW12, RAW10,RAW8, and RAW6 video data is filled from BIT[13] to LSB, the remaining bits are zero padded. Only RAW16 input data will be saved to memory from BIT[15] to LSB.&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;This RAW data is shifted which makes it hard for direct processing from a Y16 or Y8 buffer.&lt;BR /&gt;Testing showed that some RGB and YUV may be able to capture the 8-lsb.&lt;/P&gt;&lt;P&gt;ISI Format 18 - YUV444_3P8P&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;hexdump -C cam.raw -s $((1920*1080*3)) | head -n 4&lt;BR /&gt;005eec00 45 23 45 23 45 23 45 23 45 23 45 23 45 23 45 23 |E#E#E#E#E#E#E#E#|&lt;BR /&gt;*&lt;BR /&gt;005ef380 ef ab ef ab ef ab ef ab ef ab ef ab ef ab ef ab |................|&lt;BR /&gt;*&lt;BR /&gt;G 0x0345 R 0x0123&lt;BR /&gt;B 0x02EF G 0x1AB&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Above the LSB of our bayer data are there. Storing in 3 planes allows to access the data directly. This may help for RAW8 ISI capture by keeping only the relevant plane.&lt;/P&gt;&lt;P&gt;Testing with&amp;nbsp;YUV444_3P10 only reported the 8-lsb shifted by 8 being saved, thus not able to get RAW10 this way.&lt;/P&gt;&lt;P&gt;&lt;U&gt;BAYER Processing&lt;/U&gt;&lt;/P&gt;&lt;P&gt;Bayer is not supported natively by the i.MX8QM. NXP GPU SDK has example of Bayer conversion using the GPU :&lt;BR /&gt;-&amp;nbsp;&lt;A href="https://www.nxp.com/docs/en/application-note/AN12060.pdf" target="_blank" rel="noopener"&gt;https://www.nxp.com/docs/en/application-note/AN12060.pdf&lt;/A&gt;&lt;BR /&gt;-&amp;nbsp;&lt;A href="https://github.com/nxp-imx/gtec-demo-framework/tree/master/DemoApps/OpenVX/SoftISP" target="_blank" rel="noopener"&gt;https://github.com/nxp-imx/gtec-demo-framework/tree/master/DemoApps/OpenVX/SoftISP&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;NXP Support Feedback&lt;/SPAN&gt;&lt;/P&gt;&lt;BLOCKQUOTE&gt;&lt;P&gt;&lt;STRONG&gt;If the SoC is configured for both GPU to be independent, could they be used independently to perform BAYER conversion ?&lt;/STRONG&gt;&lt;BR /&gt;Yes. Just refer to&amp;nbsp;&lt;A href="https://www.nxp.com.cn/docs/en/user-guide/i.MX_Graphics_User's_Guide_Linux.pdf" target="_blank" rel="nofollow noopener noreferrer"&gt;https://www.nxp.com.cn/docs/en/user-guide/i.MX_Graphics_User's_Guide_Linux.pdf&lt;/A&gt;&amp;nbsp;8.3-8.4, app can get GPU ID by clGetDeviceIDs, and assign current softISP application to specific&lt;A href="https://gpu.to/" target="_blank" rel="noopener"&gt;GPU.to&lt;/A&gt;use two GPU, it may need two softISP software running, and assign each softISP to a target GPU.&amp;nbsp;Currently softISP uses Opencl, which not support multiple GPUs.&lt;/P&gt;&lt;P&gt;I checked with softISP owner, it is said opengles may support multiple GPUs, you can try to do your own porting.&lt;/P&gt;&lt;/BLOCKQUOTE&gt;&lt;P&gt;Processing Bayer GRBG with the i.MX8 GPU may be possible with the following work&lt;BR /&gt;- update the soft ISP from Bayer BGGR to Bayer&amp;nbsp;GRBG (for our case)&lt;BR /&gt;- update the soft ISP for 4-bit shifted&amp;nbsp;RAW10&amp;nbsp;data&amp;nbsp;(0bxxCSIDATAxxxxxx)&lt;BR /&gt;-&amp;nbsp;enable 2 GPU for multiple concurrent buffer processing (4 camera streams in our case)&lt;BR /&gt;- perform capture pipeline ( ISI -&amp;gt; GPU -&amp;gt; Memory ) (GStreamer integration ?)&lt;BR /&gt;- hope for good performance ( 30fps ?, at least above 15fps ?)&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;We will look at camera with RGB/YUV support for better compatibility.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;Thanks&amp;nbsp;&lt;a href="https://community.nxp.com/t5/user/viewprofilepage/user-id/207913"&gt;@hector_delgado&lt;/a&gt;&amp;nbsp;for your support.&lt;BR /&gt;Stan&lt;/P&gt;</description>
      <pubDate>Fri, 23 Jun 2023 17:32:05 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/i-MX8QM-CSI-2-RAW-10-Bayer-Processing/m-p/1675073#M208048</guid>
      <dc:creator>sbertrand</dc:creator>
      <dc:date>2023-06-23T17:32:05Z</dc:date>
    </item>
  </channel>
</rss>

