From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga04.intel.com ([192.55.52.120]:7953 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751628AbcASNTn (ORCPT ); Tue, 19 Jan 2016 08:19:43 -0500 Subject: Re: [PATCH v2] V4L: add Y12I, Y8I and Z16 pixel format documentation To: Guennadi Liakhovetski , Linux Media Mailing List Cc: Aviv Greenberg , Hans Verkuil , Laurent Pinchart References: From: Sakari Ailus Message-ID: <569E37E6.9080802@linux.intel.com> Date: Tue, 19 Jan 2016 15:19:34 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: Hi Guennadi, Guennadi Liakhovetski wrote: > Add documentation for 3 formats, used by RealSense cameras like R200. > > Signed-off-by: Guennadi Liakhovetski > --- > Documentation/DocBook/media/v4l/pixfmt-y12i.xml | 49 +++++++++++++++ > Documentation/DocBook/media/v4l/pixfmt-y8i.xml | 80 ++++++++++++++++++++++++ > Documentation/DocBook/media/v4l/pixfmt-z16.xml | 81 +++++++++++++++++++++++++ > Documentation/DocBook/media/v4l/pixfmt.xml | 10 +++ > 4 files changed, 220 insertions(+) > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y12i.xml > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y8i.xml > create mode 100644 Documentation/DocBook/media/v4l/pixfmt-z16.xml > > diff --git a/Documentation/DocBook/media/v4l/pixfmt-y12i.xml b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml > new file mode 100644 > index 0000000..4a2d1e5 > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml > @@ -0,0 +1,49 @@ > + > + > + V4L2_PIX_FMT_Y12I ('Y12I') > + &manvol; > + > + > + V4L2_PIX_FMT_Y12I > + Interleaved grey-scale image, e.g. from a stereo-pair > + > + > + Description > + > + This is a grey-scale image with a depth of 12 bits per pixel, but with > +pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a > +24-bit word in the little-endian order. On a little-endian machine these pixels > +can be deinterlaced using > + > + > + > +__u8 *buf; > +left0 = 0xfff & *(__u16 *)buf; > +right0 = *(__u16 *)(buf + 1) >> 4; > + > + > + > + > + <constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes > + > + > + Bit-packed representation > + pixels cross the byte boundary and have a ratio of 3 bytes for each > + interleaved pixel. > + > + > + > + > + > + Y'0left[7:0] > + Y'0right[3:0]Y'0left[11:8] > + Y'0right[11:4] > + > + > + > + > + > + > + > + > + > diff --git a/Documentation/DocBook/media/v4l/pixfmt-y8i.xml b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml > new file mode 100644 > index 0000000..99f389d > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml > @@ -0,0 +1,80 @@ > + > + > + V4L2_PIX_FMT_Y8I ('Y8I ') > + &manvol; > + > + > + V4L2_PIX_FMT_Y8I > + Interleaved grey-scale image, e.g. from a stereo-pair > + > + > + Description > + > + This is a grey-scale image with a depth of 8 bits per pixel, but with > +pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g. > +the R200 RealSense camera stores pixel from the left sensor in lower and from > +the right sensor in the higher 8 bits. > + > + > + <constant>V4L2_PIX_FMT_Y8I</constant> 4 × 4 > +pixel image > + > + > + Byte Order. > + Each cell is one byte. > + > + > + > + > + > + start + 0: > + Y'00left > + Y'00right > + Y'01left > + Y'01right > + Y'02left > + Y'02right > + Y'03left > + Y'03right > + > + > + start + 8: > + Y'10left > + Y'10right > + Y'11left > + Y'11right > + Y'12left > + Y'12right > + Y'13left > + Y'13right > + > + > + start + 16: > + Y'20left > + Y'20right > + Y'21left > + Y'21right > + Y'22left > + Y'22right > + Y'23left > + Y'23right > + > + > + start + 24: > + Y'30left > + Y'30right > + Y'31left > + Y'31right > + Y'32left > + Y'32right > + Y'33left > + Y'33right > + > + > + > + > + > + > + > + > + > diff --git a/Documentation/DocBook/media/v4l/pixfmt-z16.xml b/Documentation/DocBook/media/v4l/pixfmt-z16.xml > new file mode 100644 > index 0000000..3d87e4b > --- /dev/null > +++ b/Documentation/DocBook/media/v4l/pixfmt-z16.xml > @@ -0,0 +1,81 @@ > + > + > + V4L2_PIX_FMT_Z16 ('Z16 ') > + &manvol; > + > + > + V4L2_PIX_FMT_Z16 > + Interleaved grey-scale image, e.g. from a stereo-pair > + > + > + Description > + > + This is a 16-bit format, representing depth data. Each pixel is a > +distance to the respective point in the image coordinates. Distance unit can > +vary and has to be negotiated with the device separately. Each pixel is stored > +in a 16-bit word in the little endian byte order. I think we really need a way to convey the unit (and prefix) information to the user. Considering the same should be done to controls, it'd be logical to do that at the same time with the controls. Acked-by: Sakari Ailus I'd like to have Hans's and/or Laurent's ack on this as well. Unless the original patch requires changes, it could be re-applied if no changes are requested to it. My understanding is that the issue mainly was the missing documentation, i.e. this patch. > + > + > + > + <constant>V4L2_PIX_FMT_Z16</constant> 4 × 4 > +pixel image > + > + > + Byte Order. > + Each cell is one byte. > + > + > + > + > + > + start + 0: > + Z00low > + Z00high > + Z01low > + Z01high > + Z02low > + Z02high > + Z03low > + Z03high > + > + > + start + 8: > + Z10low > + Z10high > + Z11low > + Z11high > + Z12low > + Z12high > + Z13low > + Z13high > + > + > + start + 16: > + Z20low > + Z20high > + Z21low > + Z21high > + Z22low > + Z22high > + Z23low > + Z23high > + > + > + start + 24: > + Z30low > + Z30high > + Z31low > + Z31high > + Z32low > + Z32high > + Z33low > + Z33high > + > + > + > + > + > + > + > + > + > diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml > index d871245..9924732 100644 > --- a/Documentation/DocBook/media/v4l/pixfmt.xml > +++ b/Documentation/DocBook/media/v4l/pixfmt.xml > @@ -1620,6 +1620,8 @@ information. > &sub-y10b; > &sub-y16; > &sub-y16-be; > + &sub-y8i; > + &sub-y12i; > &sub-uv8; > &sub-yuyv; > &sub-uyvy; > @@ -1641,6 +1643,14 @@ information. > &sub-m420; > > > +
> + Depth Formats > + Depth data provides distance to points, mapped onto the image plane > + > + > + &sub-z16; > +
> + >
> Compressed Formats > > -- Kind regards, Sakari Ailus sakari.ailus@linux.intel.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mga02.intel.com ([134.134.136.20]:35282 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757526AbcAYRIh (ORCPT ); Mon, 25 Jan 2016 12:08:37 -0500 Subject: Re: [PATCH v2] V4L: add Y12I, Y8I and Z16 pixel format documentation To: Guennadi Liakhovetski Cc: Linux Media Mailing List , Aviv Greenberg , Hans Verkuil , Laurent Pinchart References: <569E37E6.9080802@linux.intel.com> From: Sakari Ailus Message-ID: <56A6564A.1040207@linux.intel.com> Date: Mon, 25 Jan 2016 19:07:22 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-media-owner@vger.kernel.org List-ID: Hi Guennadi, Guennadi Liakhovetski wrote: > Hi Sakari, > > On Tue, 19 Jan 2016, Sakari Ailus wrote: > >> Hi Guennadi, >> >> Guennadi Liakhovetski wrote: >>> Add documentation for 3 formats, used by RealSense cameras like R200. >>> >>> Signed-off-by: Guennadi Liakhovetski >>> --- > > [snip] > >>> + This is a 16-bit format, representing depth data. Each pixel is a >>> +distance to the respective point in the image coordinates. Distance unit can >>> +vary and has to be negotiated with the device separately. Each pixel is stored >>> +in a 16-bit word in the little endian byte order. >> >> I think we really need a way to convey the unit (and prefix) information >> to the user. Considering the same should be done to controls, it'd be >> logical to do that at the same time with the controls. > > Do I understand you correctly, that you'd like to add a control to specify > distance units for this format? If yes - I don't think you want a separate > control just for this format, right? And you mention, you also want to be Considering there are no other depth formats defined, it should be generic I think, but so far with a single user. > able to specify units for other controls. But I would've thought, that > controls themselves should define, what unit they are using. E.g. > V4L2_CID_EXPOSURE_ABSOLUTE specifies, that it's unit is 100us. I would > expect the same from other controls too. "Legacy" controls like > V4L2_CID_EXPOSURE don't specify units, so, I would expect, that their use > should be discouraged. Would you create a new control whenever someone needs a new unit for a control? That's the very problem I think --- currently applications have no means to know what's the unit for the control. I've always wondered why we had V4L2_CID_EXPOSURE_ABSOLUTE as V4L2_CID_EXPOSURE already existed. :-) The smiapp driver, for instance, uses V4L2_CID_EXPOSURE, and the unit is lines. There's a fine exposure control as well implemented by many sensors but the driver currently does not expose that capability. >> Acked-by: Sakari Ailus >> >> I'd like to have Hans's and/or Laurent's ack on this as well. >> >> Unless the original patch requires changes, it could be re-applied if no >> changes are requested to it. My understanding is that the issue mainly >> was the missing documentation, i.e. this patch. > > Yes, I'll repost both patches as a series, maybe let's try to get some > understanding on the units question first. -- Regards, Sakari Ailus sakari.ailus@linux.intel.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.gmx.net ([212.227.15.19]:59162 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755037AbcAROdF (ORCPT ); Mon, 18 Jan 2016 09:33:05 -0500 Date: Mon, 18 Jan 2016 15:32:55 +0100 (CET) From: Guennadi Liakhovetski To: Linux Media Mailing List cc: Sakari Ailus , Aviv Greenberg , Hans Verkuil Subject: [PATCH v2] V4L: add Y12I, Y8I and Z16 pixel format documentation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-media-owner@vger.kernel.org List-ID: Add documentation for 3 formats, used by RealSense cameras like R200. Signed-off-by: Guennadi Liakhovetski --- Documentation/DocBook/media/v4l/pixfmt-y12i.xml | 49 +++++++++++++++ Documentation/DocBook/media/v4l/pixfmt-y8i.xml | 80 ++++++++++++++++++++++++ Documentation/DocBook/media/v4l/pixfmt-z16.xml | 81 +++++++++++++++++++++++++ Documentation/DocBook/media/v4l/pixfmt.xml | 10 +++ 4 files changed, 220 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y12i.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-y8i.xml create mode 100644 Documentation/DocBook/media/v4l/pixfmt-z16.xml diff --git a/Documentation/DocBook/media/v4l/pixfmt-y12i.xml b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml new file mode 100644 index 0000000..4a2d1e5 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y12i.xml @@ -0,0 +1,49 @@ + + + V4L2_PIX_FMT_Y12I ('Y12I') + &manvol; + + + V4L2_PIX_FMT_Y12I + Interleaved grey-scale image, e.g. from a stereo-pair + + + Description + + This is a grey-scale image with a depth of 12 bits per pixel, but with +pixels from 2 sources interleaved and bit-packed. Each pixel is stored in a +24-bit word in the little-endian order. On a little-endian machine these pixels +can be deinterlaced using + + + +__u8 *buf; +left0 = 0xfff & *(__u16 *)buf; +right0 = *(__u16 *)(buf + 1) >> 4; + + + + + <constant>V4L2_PIX_FMT_Y12I</constant> 2 pixel data stream taking 3 bytes + + + Bit-packed representation + pixels cross the byte boundary and have a ratio of 3 bytes for each + interleaved pixel. + + + + + + Y'0left[7:0] + Y'0right[3:0]Y'0left[11:8] + Y'0right[11:4] + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-y8i.xml b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml new file mode 100644 index 0000000..99f389d --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-y8i.xml @@ -0,0 +1,80 @@ + + + V4L2_PIX_FMT_Y8I ('Y8I ') + &manvol; + + + V4L2_PIX_FMT_Y8I + Interleaved grey-scale image, e.g. from a stereo-pair + + + Description + + This is a grey-scale image with a depth of 8 bits per pixel, but with +pixels from 2 sources interleaved. Each pixel is stored in a 16-bit word. E.g. +the R200 RealSense camera stores pixel from the left sensor in lower and from +the right sensor in the higher 8 bits. + + + <constant>V4L2_PIX_FMT_Y8I</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00left + Y'00right + Y'01left + Y'01right + Y'02left + Y'02right + Y'03left + Y'03right + + + start + 8: + Y'10left + Y'10right + Y'11left + Y'11right + Y'12left + Y'12right + Y'13left + Y'13right + + + start + 16: + Y'20left + Y'20right + Y'21left + Y'21right + Y'22left + Y'22right + Y'23left + Y'23right + + + start + 24: + Y'30left + Y'30right + Y'31left + Y'31right + Y'32left + Y'32right + Y'33left + Y'33right + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt-z16.xml b/Documentation/DocBook/media/v4l/pixfmt-z16.xml new file mode 100644 index 0000000..3d87e4b --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-z16.xml @@ -0,0 +1,81 @@ + + + V4L2_PIX_FMT_Z16 ('Z16 ') + &manvol; + + + V4L2_PIX_FMT_Z16 + Interleaved grey-scale image, e.g. from a stereo-pair + + + Description + + This is a 16-bit format, representing depth data. Each pixel is a +distance to the respective point in the image coordinates. Distance unit can +vary and has to be negotiated with the device separately. Each pixel is stored +in a 16-bit word in the little endian byte order. + + + + <constant>V4L2_PIX_FMT_Z16</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Z00low + Z00high + Z01low + Z01high + Z02low + Z02high + Z03low + Z03high + + + start + 8: + Z10low + Z10high + Z11low + Z11high + Z12low + Z12high + Z13low + Z13high + + + start + 16: + Z20low + Z20high + Z21low + Z21high + Z22low + Z22high + Z23low + Z23high + + + start + 24: + Z30low + Z30high + Z31low + Z31high + Z32low + Z32high + Z33low + Z33high + + + + + + + + + diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index d871245..9924732 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -1620,6 +1620,8 @@ information. &sub-y10b; &sub-y16; &sub-y16-be; + &sub-y8i; + &sub-y12i; &sub-uv8; &sub-yuyv; &sub-uyvy; @@ -1641,6 +1643,14 @@ information. &sub-m420;
+
+ Depth Formats + Depth data provides distance to points, mapped onto the image plane + + + &sub-z16; +
+
Compressed Formats -- 1.9.3 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mout.gmx.net ([212.227.17.21]:56463 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932678AbcAYQQM (ORCPT ); Mon, 25 Jan 2016 11:16:12 -0500 Date: Mon, 25 Jan 2016 17:15:54 +0100 (CET) From: Guennadi Liakhovetski To: Sakari Ailus cc: Linux Media Mailing List , Aviv Greenberg , Hans Verkuil , Laurent Pinchart Subject: Re: [PATCH v2] V4L: add Y12I, Y8I and Z16 pixel format documentation In-Reply-To: <569E37E6.9080802@linux.intel.com> Message-ID: References: <569E37E6.9080802@linux.intel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-media-owner@vger.kernel.org List-ID: Hi Sakari, On Tue, 19 Jan 2016, Sakari Ailus wrote: > Hi Guennadi, > > Guennadi Liakhovetski wrote: > > Add documentation for 3 formats, used by RealSense cameras like R200. > > > > Signed-off-by: Guennadi Liakhovetski > > --- [snip] > > + This is a 16-bit format, representing depth data. Each pixel is a > > +distance to the respective point in the image coordinates. Distance unit can > > +vary and has to be negotiated with the device separately. Each pixel is stored > > +in a 16-bit word in the little endian byte order. > > I think we really need a way to convey the unit (and prefix) information > to the user. Considering the same should be done to controls, it'd be > logical to do that at the same time with the controls. Do I understand you correctly, that you'd like to add a control to specify distance units for this format? If yes - I don't think you want a separate control just for this format, right? And you mention, you also want to be able to specify units for other controls. But I would've thought, that controls themselves should define, what unit they are using. E.g. V4L2_CID_EXPOSURE_ABSOLUTE specifies, that it's unit is 100us. I would expect the same from other controls too. "Legacy" controls like V4L2_CID_EXPOSURE don't specify units, so, I would expect, that their use should be discouraged. > Acked-by: Sakari Ailus > > I'd like to have Hans's and/or Laurent's ack on this as well. > > Unless the original patch requires changes, it could be re-applied if no > changes are requested to it. My understanding is that the issue mainly > was the missing documentation, i.e. this patch. Yes, I'll repost both patches as a series, maybe let's try to get some understanding on the units question first. Thanks Guennadi