| Message ID | 1466439608-22890-2-git-send-email-sakari.ailus@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 06/20/2016 06:20 PM, Sakari Ailus wrote: > The 10-bit packed raw bayer format documented that the data of the first > pixel of a four-pixel group was found in the first byte and the two > highest bits of the fifth byte. This was not entirely correct. The two > bits in the fifth byte are the two lowest bits. The second pixel occupies > the second byte and third and fourth least significant bits and so on. > > Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> As mentioned, this needs confirmation. I wonder, isn't this specified in the UVC spec? Regards, Hans > --- > .../DocBook/media/v4l/pixfmt-srggb10p.xml | 32 +++++++++++----------- > 1 file changed, 16 insertions(+), 16 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml > index a8cc102..747822b 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml > @@ -47,10 +47,10 @@ > <entry>G<subscript>01high</subscript></entry> > <entry>B<subscript>02high</subscript></entry> > <entry>G<subscript>03high</subscript></entry> > - <entry>B<subscript>00low</subscript>(bits 7--6) > - G<subscript>01low</subscript>(bits 5--4) > - B<subscript>02low</subscript>(bits 3--2) > - G<subscript>03low</subscript>(bits 1--0) > + <entry>G<subscript>03low</subscript>(bits 7--6) > + B<subscript>02low</subscript>(bits 5--4) > + G<subscript>01low</subscript>(bits 3--2) > + B<subscript>00low</subscript>(bits 1--0) > </entry> > </row> > <row> > @@ -59,10 +59,10 @@ > <entry>R<subscript>11high</subscript></entry> > <entry>G<subscript>12high</subscript></entry> > <entry>R<subscript>13high</subscript></entry> > - <entry>G<subscript>10low</subscript>(bits 7--6) > - R<subscript>11low</subscript>(bits 5--4) > - G<subscript>12low</subscript>(bits 3--2) > - R<subscript>13low</subscript>(bits 1--0) > + <entry>R<subscript>13low</subscript>(bits 7--6) > + G<subscript>12low</subscript>(bits 5--4) > + R<subscript>11low</subscript>(bits 3--2) > + G<subscript>10low</subscript>(bits 1--0) > </entry> > </row> > <row> > @@ -71,10 +71,10 @@ > <entry>G<subscript>21high</subscript></entry> > <entry>B<subscript>22high</subscript></entry> > <entry>G<subscript>23high</subscript></entry> > - <entry>B<subscript>20low</subscript>(bits 7--6) > - G<subscript>21low</subscript>(bits 5--4) > - B<subscript>22low</subscript>(bits 3--2) > - G<subscript>23low</subscript>(bits 1--0) > + <entry>G<subscript>23low</subscript>(bits 7--6) > + B<subscript>22low</subscript>(bits 5--4) > + G<subscript>21low</subscript>(bits 3--2) > + B<subscript>20low</subscript>(bits 1--0) > </entry> > </row> > <row> > @@ -83,10 +83,10 @@ > <entry>R<subscript>31high</subscript></entry> > <entry>G<subscript>32high</subscript></entry> > <entry>R<subscript>33high</subscript></entry> > - <entry>G<subscript>30low</subscript>(bits 7--6) > - R<subscript>31low</subscript>(bits 5--4) > - G<subscript>32low</subscript>(bits 3--2) > - R<subscript>33low</subscript>(bits 1--0) > + <entry>R<subscript>33low</subscript>(bits 7--6) > + G<subscript>32low</subscript>(bits 5--4) > + R<subscript>31low</subscript>(bits 3--2) > + G<subscript>30low</subscript>(bits 1--0) > </entry> > </row> > </tbody> > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hans. On 20/06/16 18:03, Hans Verkuil wrote: > On 06/20/2016 06:20 PM, Sakari Ailus wrote: >> The 10-bit packed raw bayer format documented that the data of the first >> pixel of a four-pixel group was found in the first byte and the two >> highest bits of the fifth byte. This was not entirely correct. The two >> bits in the fifth byte are the two lowest bits. The second pixel occupies >> the second byte and third and fourth least significant bits and so on. >> >> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> > As mentioned, this needs confirmation. I wonder, isn't this specified in the UVC > spec? > > Regards, > > Hans I'm assuming this is intended to be the same format as generated by many Bayer sensors. Those are defined in both the SMIA CCP2 (section 7.9), and MIPI CSI2 (section 11.4.4) specs. Whilst nominally restricted, they are both available via unofficial websites if you Google for them (I'm happy to send links, but didn't want to break mailing list rules by just posting them). CSI2 draft spec Figure 98 "RAW10 Data Transmission on CSI-2 Bus Bitwise Illustration" is probably the clearest confirmation of the bit ordering. dcraw from http://www.cybercom.net/~dcoffin/dcraw/ can consume Raw10 via nokia_load_raw for (dp=data, col=0; col < raw_width; dp+=5, col+=4) FORC4 RAW(row,col+c) = (dp[c] << 2) | (dp[4] >> (c << 1) & 3); And checking against the Raspberry Pi hardware simulator, the RAW10 parser code has for (i = 0; i < width; i++) { switch ((i + tile_x) & 3) { case 0: val = (buf[0] << 2) | (buf[4] & 3); break; case 1: val = (buf[1] << 2) | ((buf[4] >> 2) & 3); break; case 2: val = (buf[2] << 2) | ((buf[4] >> 4) & 3); break; default: val = (buf[3] << 2) | ((buf[4] >> 6) & 3); All of those agree with Sakari's update that the first pixel's LSBits are in bits 1..0 of byte 5, 2nd pixel in bits 3..2, etc. Regards, Dave (working on the Pi CSI2 receiver V4L2 driver as there is now sufficient data in the public domain to do it. I'll be wanting these formats!) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/20/2016 10:38 PM, Dave Stevenson wrote: > Hi Hans. > > On 20/06/16 18:03, Hans Verkuil wrote: >> On 06/20/2016 06:20 PM, Sakari Ailus wrote: >>> The 10-bit packed raw bayer format documented that the data of the first >>> pixel of a four-pixel group was found in the first byte and the two >>> highest bits of the fifth byte. This was not entirely correct. The two >>> bits in the fifth byte are the two lowest bits. The second pixel occupies >>> the second byte and third and fourth least significant bits and so on. >>> >>> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> >> As mentioned, this needs confirmation. I wonder, isn't this specified in the UVC >> spec? I can't find anything in the uvc spec. This format was apparently added for an Intel R200 3D camera, so I suspect it followed the SMIA/CSI standard and that the doc is indeed wrong. So: Acked-by: Hans Verkuil <hans.verkuil@cisco.com> Regards, Hans >> >> Regards, >> >> Hans > I'm assuming this is intended to be the same format as generated by many > Bayer sensors. > Those are defined in both the SMIA CCP2 (section 7.9), and MIPI CSI2 > (section 11.4.4) specs. Whilst nominally restricted, they are both > available via unofficial websites if you Google for them (I'm happy to > send links, but didn't want to break mailing list rules by just posting > them). > CSI2 draft spec Figure 98 "RAW10 Data Transmission on CSI-2 Bus Bitwise > Illustration" is probably the clearest confirmation of the bit ordering. > > dcraw from http://www.cybercom.net/~dcoffin/dcraw/ can consume Raw10 via > nokia_load_raw > for (dp=data, col=0; col < raw_width; dp+=5, col+=4) > FORC4 RAW(row,col+c) = (dp[c] << 2) | (dp[4] >> (c << 1) & 3); > > And checking against the Raspberry Pi hardware simulator, the RAW10 > parser code has > for (i = 0; i < width; i++) { > switch ((i + tile_x) & 3) { > case 0: val = (buf[0] << 2) | (buf[4] & 3); break; > case 1: val = (buf[1] << 2) | ((buf[4] >> 2) & 3); > break; > case 2: val = (buf[2] << 2) | ((buf[4] >> 4) & 3); > break; > default: val = (buf[3] << 2) | ((buf[4] >> 6) & 3); > > > All of those agree with Sakari's update that the first pixel's LSBits > are in bits 1..0 of byte 5, 2nd pixel in bits 3..2, etc. > > Regards, > Dave > (working on the Pi CSI2 receiver V4L2 driver as there is now sufficient > data in the public domain to do it. I'll be wanting these formats!) > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml index a8cc102..747822b 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml @@ -47,10 +47,10 @@ <entry>G<subscript>01high</subscript></entry> <entry>B<subscript>02high</subscript></entry> <entry>G<subscript>03high</subscript></entry> - <entry>B<subscript>00low</subscript>(bits 7--6) - G<subscript>01low</subscript>(bits 5--4) - B<subscript>02low</subscript>(bits 3--2) - G<subscript>03low</subscript>(bits 1--0) + <entry>G<subscript>03low</subscript>(bits 7--6) + B<subscript>02low</subscript>(bits 5--4) + G<subscript>01low</subscript>(bits 3--2) + B<subscript>00low</subscript>(bits 1--0) </entry> </row> <row> @@ -59,10 +59,10 @@ <entry>R<subscript>11high</subscript></entry> <entry>G<subscript>12high</subscript></entry> <entry>R<subscript>13high</subscript></entry> - <entry>G<subscript>10low</subscript>(bits 7--6) - R<subscript>11low</subscript>(bits 5--4) - G<subscript>12low</subscript>(bits 3--2) - R<subscript>13low</subscript>(bits 1--0) + <entry>R<subscript>13low</subscript>(bits 7--6) + G<subscript>12low</subscript>(bits 5--4) + R<subscript>11low</subscript>(bits 3--2) + G<subscript>10low</subscript>(bits 1--0) </entry> </row> <row> @@ -71,10 +71,10 @@ <entry>G<subscript>21high</subscript></entry> <entry>B<subscript>22high</subscript></entry> <entry>G<subscript>23high</subscript></entry> - <entry>B<subscript>20low</subscript>(bits 7--6) - G<subscript>21low</subscript>(bits 5--4) - B<subscript>22low</subscript>(bits 3--2) - G<subscript>23low</subscript>(bits 1--0) + <entry>G<subscript>23low</subscript>(bits 7--6) + B<subscript>22low</subscript>(bits 5--4) + G<subscript>21low</subscript>(bits 3--2) + B<subscript>20low</subscript>(bits 1--0) </entry> </row> <row> @@ -83,10 +83,10 @@ <entry>R<subscript>31high</subscript></entry> <entry>G<subscript>32high</subscript></entry> <entry>R<subscript>33high</subscript></entry> - <entry>G<subscript>30low</subscript>(bits 7--6) - R<subscript>31low</subscript>(bits 5--4) - G<subscript>32low</subscript>(bits 3--2) - R<subscript>33low</subscript>(bits 1--0) + <entry>R<subscript>33low</subscript>(bits 7--6) + G<subscript>32low</subscript>(bits 5--4) + R<subscript>31low</subscript>(bits 3--2) + G<subscript>30low</subscript>(bits 1--0) </entry> </row> </tbody>
The 10-bit packed raw bayer format documented that the data of the first pixel of a four-pixel group was found in the first byte and the two highest bits of the fifth byte. This was not entirely correct. The two bits in the fifth byte are the two lowest bits. The second pixel occupies the second byte and third and fourth least significant bits and so on. Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> --- .../DocBook/media/v4l/pixfmt-srggb10p.xml | 32 +++++++++++----------- 1 file changed, 16 insertions(+), 16 deletions(-)