Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1444412 > unrolled thread

[PATCH v2 0/6] Add HSV format

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-15 18:20 +0200
    [PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-15 18:20 +0200
    [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-15 18:20 +0200
      Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-07-15 20:20 +0200
        Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-16 10:20 +0200
          Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-07-16 14:40 +0200
            Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-16 16:00 +0200
              Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2016-07-16 16:20 +0200
                Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-16 16:40 +0200
                  Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-16 17:30 +0200
                    Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-16 18:00 +0200
                      Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-16 18:20 +0200
                Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-16 17:20 +0200
        Re: [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-16 10:30 +0200
    [PATCH v2 6/6] [media] vivid: Rename variable Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-15 18:20 +0200
    [PATCH v2 5/6] [media] vivid: Add support for HSV formats Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-15 18:20 +0200
      Re: [PATCH v2 5/6] [media] vivid: Add support for HSV formats Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-15 20:30 +0200
    [PATCH v2 4/6] [media] vivid: code refactor for color representation Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> - 2016-07-15 18:20 +0200
      Re: [PATCH v2 4/6] [media] vivid: code refactor for color  representation Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-15 20:00 +0200
        Re: [PATCH v2 4/6] [media] vivid: code refactor for color  representation Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-15 20:20 +0200
      Re: [PATCH v2 4/6] [media] vivid: code refactor for color  representation Hans Verkuil <hverkuil@xs4all.nl> - 2016-07-15 20:30 +0200

Page 1 of 2  [1] 2  Next page →

#1444412 — [PATCH v2 0/6] Add HSV format

HSV formats are extremely useful for image segmentation. This set of
patches makes v4l2 aware of this kind of formats.

Vivid changes have been divided in three to ease the reviewing process.

We are working on patches for Gstreamer and OpenCV that will make use
of these formats.

Thanks!

Changelog
v2: Suggested by Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
-Rebase on top of docs-next (port documentation to .rst)
@mchehab, You were right, there was no conflict after the rebase, Thanks!

Ricardo Ribalda Delgado (6):
  [media] videodev2.h Add HSV formats
  [media] Documentation: Add HSV format
  [media] Documentation: Add Ricardo Ribalda
  [media] vivid: code refactor for color representation
  [media] vivid: Add support for HSV formats
  [media] vivid: Rename variable

 Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++++++++++++++
 Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
 Documentation/media/uapi/v4l/v4l2.rst              |   9 +
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c      | 341 ++++++++++++++-------
 drivers/media/platform/vivid/vivid-core.h          |   2 +-
 drivers/media/platform/vivid/vivid-vid-common.c    |  66 ++--
 drivers/media/v4l2-core/v4l2-ioctl.c               |   2 +
 include/media/v4l2-tpg.h                           |   8 +-
 include/uapi/linux/videodev2.h                     |   4 +
 10 files changed, 558 insertions(+), 147 deletions(-)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

-- 
2.8.1

[toc] | [next] | [standalone]

#1444416 — [PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda

My initials were on the Changelog, but there was no link to my name.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
 Documentation/media/uapi/v4l/v4l2.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/media/uapi/v4l/v4l2.rst b/Documentation/media/uapi/v4l/v4l2.rst
index 6d23bc987f51..330674a0f553 100644
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -64,6 +64,10 @@ Authors, in alphabetical order:
 
   - SDR API.
 
+- Ribalda, Ricardo
+
+  - Introduce HSV formats and other minor changes.
+
 - Rubli, Martin
 
   - Designed and documented the VIDIOC_ENUM_FRAMESIZES and VIDIOC_ENUM_FRAMEINTERVALS ioctls.
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444417 — [PATCH v2 2/6] [media] Documentation: Add HSV format

Describe the HSV formats

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
 Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++++++++++++++++++++
 Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
 Documentation/media/uapi/v4l/v4l2.rst              |   5 +
 4 files changed, 278 insertions(+)
 create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
 create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst

diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst b/Documentation/media/uapi/v4l/hsv-formats.rst
new file mode 100644
index 000000000000..f0f2615eaa95
--- /dev/null
+++ b/Documentation/media/uapi/v4l/hsv-formats.rst
@@ -0,0 +1,19 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _hsv-formats:
+
+***********
+HSV Formats
+***********
+
+These formats store the color information of the image
+in a geometrical representation. The colors are mapped into a
+cylinder, where the angle is the HUE, the height is the VALUE
+and the distance to the center is the SATURATION. This is a very
+useful format for image segmentation algorithms.
+
+
+.. toctree::
+    :maxdepth: 1
+
+    pixfmt-packed-hsv
diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
new file mode 100644
index 000000000000..b297aa4f7ba6
--- /dev/null
+++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
@@ -0,0 +1,253 @@
+.. -*- coding: utf-8; mode: rst -*-
+
+.. _packed-hsv:
+
+******************
+Packed HSV formats
+******************
+
+*man Packed HSV formats(2)*
+
+Packed HSV formats
+
+
+Description
+===========
+
+The HUE (h) is meassured in degrees, one LSB represents two degrees.
+The SATURATION (s) and the VALUE (v) are measured in percentage of the
+cylinder: 0 being the smallest value and 255 the maximum.
+
+
+The values are packed in 24 or 32 bit formats.
+
+
+.. flat-table:: Packed HSV Image Formats
+    :header-rows:  2
+    :stub-columns: 0
+
+
+    -  .. row 1
+
+       -  Identifier
+
+       -  Code
+
+       -
+       -  :cspan:`7` Byte 0 in memory
+
+       -
+       -  :cspan:`7` Byte 1
+
+       -
+       -  :cspan:`7` Byte 2
+
+       -
+       -  :cspan:`7` Byte 3
+
+    -  .. row 2
+
+       -
+       -
+       -  Bit
+
+       -  7
+
+       -  6
+
+       -  5
+
+       -  4
+
+       -  3
+
+       -  2
+
+       -  1
+
+       -  0
+
+       -
+       -  7
+
+       -  6
+
+       -  5
+
+       -  4
+
+       -  3
+
+       -  2
+
+       -  1
+
+       -  0
+
+       -
+       -  7
+
+       -  6
+
+       -  5
+
+       -  4
+
+       -  3
+
+       -  2
+
+       -  1
+
+       -  0
+
+       -
+       -  7
+
+       -  6
+
+       -  5
+
+       -  4
+
+       -  3
+
+       -  2
+
+       -  1
+
+       -  0
+
+    -  .. _V4L2-PIX-FMT-HSV32:
+
+       -  ``V4L2_PIX_FMT_HSV32``
+
+       -  'HSV4'
+
+       -
+       -  -
+
+       -  -
+
+       -  -
+
+       -  -
+
+       -  -
+
+       -  -
+
+       -  -
+
+       -  -
+
+       -
+       -  h\ :sub:`7`
+
+       -  h\ :sub:`6`
+
+       -  h\ :sub:`5`
+
+       -  h\ :sub:`4`
+
+       -  h\ :sub:`3`
+
+       -  h\ :sub:`2`
+
+       -  h\ :sub:`1`
+
+       -  h\ :sub:`0`
+
+       -
+       -  s\ :sub:`7`
+
+       -  s\ :sub:`6`
+
+       -  s\ :sub:`5`
+
+       -  s\ :sub:`4`
+
+       -  s\ :sub:`3`
+
+       -  s\ :sub:`2`
+
+       -  s\ :sub:`1`
+
+       -  s\ :sub:`0`
+
+       -
+       -  v\ :sub:`7`
+
+       -  v\ :sub:`6`
+
+       -  v\ :sub:`5`
+
+       -  v\ :sub:`4`
+
+       -  v\ :sub:`3`
+
+       -  v\ :sub:`2`
+
+       -  v\ :sub:`1`
+
+       -  v\ :sub:`0`
+
+    -  .. _V4L2-PIX-FMT-HSV24:
+
+       -  ``V4L2_PIX_FMT_HSV24``
+
+       -  'HSV3'
+
+       -
+       -  h\ :sub:`7`
+
+       -  h\ :sub:`6`
+
+       -  h\ :sub:`5`
+
+       -  h\ :sub:`4`
+
+       -  h\ :sub:`3`
+
+       -  h\ :sub:`2`
+
+       -  h\ :sub:`1`
+
+       -  h\ :sub:`0`
+
+       -
+       -  s\ :sub:`7`
+
+       -  s\ :sub:`6`
+
+       -  s\ :sub:`5`
+
+       -  s\ :sub:`4`
+
+       -  s\ :sub:`3`
+
+       -  s\ :sub:`2`
+
+       -  s\ :sub:`1`
+
+       -  s\ :sub:`0`
+
+       -
+       -  v\ :sub:`7`
+
+       -  v\ :sub:`6`
+
+       -  v\ :sub:`5`
+
+       -  v\ :sub:`4`
+
+       -  v\ :sub:`3`
+
+       -  v\ :sub:`2`
+
+       -  v\ :sub:`1`
+
+       -  v\ :sub:`0`
+
+
+Bit 7 is the most significant bit.
diff --git a/Documentation/media/uapi/v4l/pixfmt.rst b/Documentation/media/uapi/v4l/pixfmt.rst
index 81222a99f7ce..1d2270422345 100644
--- a/Documentation/media/uapi/v4l/pixfmt.rst
+++ b/Documentation/media/uapi/v4l/pixfmt.rst
@@ -29,6 +29,7 @@ see also :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`.)
     pixfmt-indexed
     pixfmt-rgb
     yuv-formats
+    hsv-formats
     depth-formats
     pixfmt-013
     sdr-formats
diff --git a/Documentation/media/uapi/v4l/v4l2.rst b/Documentation/media/uapi/v4l/v4l2.rst
index c0859ebc88ee..6d23bc987f51 100644
--- a/Documentation/media/uapi/v4l/v4l2.rst
+++ b/Documentation/media/uapi/v4l/v4l2.rst
@@ -85,6 +85,11 @@ part can be used and distributed without restrictions.
 Revision History
 ****************
 
+:revision: 4.8 / 2016-07-15 (*rr*)
+
+Introduce HSV formats.
+
+
 :revision: 4.5 / 2015-10-29 (*rr*)
 
 Extend VIDIOC_G_EXT_CTRLS;. Replace ctrl_class with a new union with
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444498 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

Hi Ricardo,

Thank you for the patch.

On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
> Describe the HSV formats
> 
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
>  Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 ++++++++++++++++++
>  Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
>  Documentation/media/uapi/v4l/v4l2.rst              |   5 +
>  4 files changed, 278 insertions(+)
>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> 
> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
> index 000000000000..f0f2615eaa95
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
> @@ -0,0 +1,19 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _hsv-formats:
> +
> +***********
> +HSV Formats
> +***********
> +
> +These formats store the color information of the image
> +in a geometrical representation. The colors are mapped into a
> +cylinder, where the angle is the HUE, the height is the VALUE
> +and the distance to the center is the SATURATION. This is a very
> +useful format for image segmentation algorithms.
> +
> +
> +.. toctree::
> +    :maxdepth: 1
> +
> +    pixfmt-packed-hsv
> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
> index 000000000000..b297aa4f7ba6
> --- /dev/null
> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> @@ -0,0 +1,253 @@
> +.. -*- coding: utf-8; mode: rst -*-
> +
> +.. _packed-hsv:
> +
> +******************
> +Packed HSV formats
> +******************
> +
> +*man Packed HSV formats(2)*
> +
> +Packed HSV formats
> +
> +
> +Description
> +===========
> +
> +The HUE (h) is meassured in degrees, one LSB represents two degrees.

Is this common ? I have a device that can handle HSV data, I need to check how 
it maps the hue values to binary, but I'm pretty sure they cover the full 
0-255 range. We would then have to support the two formats. Separate 4CCs are 
an option, but reporting the range separately (possibly through the colorspace 
API) might be better. Any thought on that ?

> +The SATURATION (s) and the VALUE (v) are measured in percentage of the
> +cylinder: 0 being the smallest value and 255 the maximum.
> +
> +
> +The values are packed in 24 or 32 bit formats.
> +
> +
> +.. flat-table:: Packed HSV Image Formats
> +    :header-rows:  2
> +    :stub-columns: 0
> +
> +
> +    -  .. row 1
> +
> +       -  Identifier
> +
> +       -  Code
> +
> +       -
> +       -  :cspan:`7` Byte 0 in memory
> +

Do we really need all those blank lines ?

[snip]

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1444772 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
> Hi Ricardo,
> 
> Thank you for the patch.
> 
> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
>> Describe the HSV formats
>>
>> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>> ---
>>  Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
>>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 ++++++++++++++++++
>>  Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
>>  Documentation/media/uapi/v4l/v4l2.rst              |   5 +
>>  4 files changed, 278 insertions(+)
>>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
>> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
>> index 000000000000..f0f2615eaa95
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
>> @@ -0,0 +1,19 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _hsv-formats:
>> +
>> +***********
>> +HSV Formats
>> +***********
>> +
>> +These formats store the color information of the image
>> +in a geometrical representation. The colors are mapped into a
>> +cylinder, where the angle is the HUE, the height is the VALUE
>> +and the distance to the center is the SATURATION. This is a very
>> +useful format for image segmentation algorithms.
>> +
>> +
>> +.. toctree::
>> +    :maxdepth: 1
>> +
>> +    pixfmt-packed-hsv
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
>> index 000000000000..b297aa4f7ba6
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> @@ -0,0 +1,253 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _packed-hsv:
>> +
>> +******************
>> +Packed HSV formats
>> +******************
>> +
>> +*man Packed HSV formats(2)*
>> +
>> +Packed HSV formats
>> +
>> +
>> +Description
>> +===========
>> +
>> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
> 
> Is this common ? I have a device that can handle HSV data, I need to check how 
> it maps the hue values to binary, but I'm pretty sure they cover the full 
> 0-255 range. We would then have to support the two formats. Separate 4CCs are 
> an option, but reporting the range separately (possibly through the colorspace 
> API) might be better. Any thought on that ?

It's either a separate 4cc or we do something with the ycbcr_enc field (reinterpreted
as hsv_enc). I'm not sure, I would have to think some more about that.

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1444827 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

Hi Hans,

On Saturday 16 Jul 2016 10:19:29 Hans Verkuil wrote:
> On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
> > On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
> >> Describe the HSV formats
> >> 
> >> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> >> ---
> >> 
> >>  Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
> >>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++++++++++++++
> >>  Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
> >>  Documentation/media/uapi/v4l/v4l2.rst              |   5 +
> >>  4 files changed, 278 insertions(+)
> >>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
> >>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> >> 
> >> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
> >> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
> >> index 000000000000..f0f2615eaa95
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
> >> @@ -0,0 +1,19 @@
> >> +.. -*- coding: utf-8; mode: rst -*-
> >> +
> >> +.. _hsv-formats:
> >> +
> >> +***********
> >> +HSV Formats
> >> +***********
> >> +
> >> +These formats store the color information of the image
> >> +in a geometrical representation. The colors are mapped into a
> >> +cylinder, where the angle is the HUE, the height is the VALUE
> >> +and the distance to the center is the SATURATION. This is a very
> >> +useful format for image segmentation algorithms.
> >> +
> >> +
> >> +.. toctree::
> >> +    :maxdepth: 1
> >> +
> >> +    pixfmt-packed-hsv
> >> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> >> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
> >> index 000000000000..b297aa4f7ba6
> >> --- /dev/null
> >> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
> >> @@ -0,0 +1,253 @@
> >> +.. -*- coding: utf-8; mode: rst -*-
> >> +
> >> +.. _packed-hsv:
> >> +
> >> +******************
> >> +Packed HSV formats
> >> +******************
> >> +
> >> +*man Packed HSV formats(2)*
> >> +
> >> +Packed HSV formats
> >> +
> >> +
> >> +Description
> >> +===========
> >> +
> >> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
> > 
> > Is this common ? I have a device that can handle HSV data, I need to check
> > how it maps the hue values to binary, but I'm pretty sure they cover the
> > full 0-255 range. We would then have to support the two formats. Separate
> > 4CCs are an option, but reporting the range separately (possibly through
> > the colorspace API) might be better. Any thought on that ?
> 
> It's either a separate 4cc or we do something with the ycbcr_enc field
> (reinterpreted as hsv_enc). I'm not sure, I would have to think some more
> about that.

I'm inclined to use the ycbcr_enc field, especially given that a similar usage 
could be useful for RGB as well (don't ask me what it's supposed to be used 
for, but I have hardware that support limiting the RGB values range to 
16-235).

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1444834 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

On 07/16/2016 02:38 PM, Laurent Pinchart wrote:
> Hi Hans,
> 
> On Saturday 16 Jul 2016 10:19:29 Hans Verkuil wrote:
>> On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
>>> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
>>>> Describe the HSV formats
>>>>
>>>> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>>>> ---
>>>>
>>>>  Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
>>>>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 +++++++++++++++
>>>>  Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
>>>>  Documentation/media/uapi/v4l/v4l2.rst              |   5 +
>>>>  4 files changed, 278 insertions(+)
>>>>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>>>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>>>
>>>> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
>>>> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
>>>> index 000000000000..f0f2615eaa95
>>>> --- /dev/null
>>>> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
>>>> @@ -0,0 +1,19 @@
>>>> +.. -*- coding: utf-8; mode: rst -*-
>>>> +
>>>> +.. _hsv-formats:
>>>> +
>>>> +***********
>>>> +HSV Formats
>>>> +***********
>>>> +
>>>> +These formats store the color information of the image
>>>> +in a geometrical representation. The colors are mapped into a
>>>> +cylinder, where the angle is the HUE, the height is the VALUE
>>>> +and the distance to the center is the SATURATION. This is a very
>>>> +useful format for image segmentation algorithms.
>>>> +
>>>> +
>>>> +.. toctree::
>>>> +    :maxdepth: 1
>>>> +
>>>> +    pixfmt-packed-hsv
>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>>> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
>>>> index 000000000000..b297aa4f7ba6
>>>> --- /dev/null
>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>>> @@ -0,0 +1,253 @@
>>>> +.. -*- coding: utf-8; mode: rst -*-
>>>> +
>>>> +.. _packed-hsv:
>>>> +
>>>> +******************
>>>> +Packed HSV formats
>>>> +******************
>>>> +
>>>> +*man Packed HSV formats(2)*
>>>> +
>>>> +Packed HSV formats
>>>> +
>>>> +
>>>> +Description
>>>> +===========
>>>> +
>>>> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
>>>
>>> Is this common ? I have a device that can handle HSV data, I need to check
>>> how it maps the hue values to binary, but I'm pretty sure they cover the
>>> full 0-255 range. We would then have to support the two formats. Separate
>>> 4CCs are an option, but reporting the range separately (possibly through
>>> the colorspace API) might be better. Any thought on that ?
>>
>> It's either a separate 4cc or we do something with the ycbcr_enc field
>> (reinterpreted as hsv_enc). I'm not sure, I would have to think some more
>> about that.
> 
> I'm inclined to use the ycbcr_enc field, especially given that a similar usage 
> could be useful for RGB as well (don't ask me what it's supposed to be used 
> for, but I have hardware that support limiting the RGB values range to 
> 16-235).

Limited vs full range quantization is handled by the quantization field. It's
there already.

Limited range RGB is needed for HDMI due to a brain-dead spec when dealing with
certain kinds of TVs and configurations. Don't ask, it's horrible.

Anyway, I am inclined to use ycbcr_enc as well.

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1444836 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

Hi Hans,

On Saturday 16 Jul 2016 15:59:08 Hans Verkuil wrote:
> On 07/16/2016 02:38 PM, Laurent Pinchart wrote:
>> On Saturday 16 Jul 2016 10:19:29 Hans Verkuil wrote:
>>> On 07/15/2016 08:11 PM, Laurent Pinchart wrote:
>>>> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
>>>>> Describe the HSV formats
>>>>> 
>>>>> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>>>>> ---
>>>>> 
>>>>>  Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
>>>>>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253
>>>>>  +++++++++++++++
>>>>>  Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
>>>>>  Documentation/media/uapi/v4l/v4l2.rst              |   5 +
>>>>>  4 files changed, 278 insertions(+)
>>>>>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>>>>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>>>> 
>>>>> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
>>>>> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
>>>>> index 000000000000..f0f2615eaa95
>>>>> --- /dev/null
>>>>> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
>>>>> @@ -0,0 +1,19 @@
>>>>> +.. -*- coding: utf-8; mode: rst -*-
>>>>> +
>>>>> +.. _hsv-formats:
>>>>> +
>>>>> +***********
>>>>> +HSV Formats
>>>>> +***********
>>>>> +
>>>>> +These formats store the color information of the image
>>>>> +in a geometrical representation. The colors are mapped into a
>>>>> +cylinder, where the angle is the HUE, the height is the VALUE
>>>>> +and the distance to the center is the SATURATION. This is a very
>>>>> +useful format for image segmentation algorithms.
>>>>> +
>>>>> +
>>>>> +.. toctree::
>>>>> +    :maxdepth: 1
>>>>> +
>>>>> +    pixfmt-packed-hsv
>>>>> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>>>> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode
>>>>> 100644
>>>>> index 000000000000..b297aa4f7ba6
>>>>> --- /dev/null
>>>>> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>>>> @@ -0,0 +1,253 @@
>>>>> +.. -*- coding: utf-8; mode: rst -*-
>>>>> +
>>>>> +.. _packed-hsv:
>>>>> +
>>>>> +******************
>>>>> +Packed HSV formats
>>>>> +******************
>>>>> +
>>>>> +*man Packed HSV formats(2)*
>>>>> +
>>>>> +Packed HSV formats
>>>>> +
>>>>> +
>>>>> +Description
>>>>> +===========
>>>>> +
>>>>> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
>>>> 
>>>> Is this common ? I have a device that can handle HSV data, I need to
>>>> check how it maps the hue values to binary, but I'm pretty sure they
>>>> cover the full 0-255 range. We would then have to support the two
>>>> formats. Separate 4CCs are an option, but reporting the range separately
>>>> (possibly through the colorspace API) might be better. Any thought on
>>>> that ?
>>> 
>>> It's either a separate 4cc or we do something with the ycbcr_enc field
>>> (reinterpreted as hsv_enc). I'm not sure, I would have to think some more
>>> about that.
>> 
>> I'm inclined to use the ycbcr_enc field, especially given that a similar
>> usage could be useful for RGB as well (don't ask me what it's supposed to
>> be used for, but I have hardware that support limiting the RGB values
>> range to 16-235).
> 
> Limited vs full range quantization is handled by the quantization field.
> It's there already.

Right. I wonder how we'll deal with that when someone will come up with more 
than one limited range quantizations, have you thought about it ?

> Limited range RGB is needed for HDMI due to a brain-dead spec when dealing
> with certain kinds of TVs and configurations. Don't ask, it's horrible.

I'd still like to know about it for my personal information :-)

> Anyway, I am inclined to use ycbcr_enc as well.

I'm glad we agree.

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1444840 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

Hi

On Sat, Jul 16, 2016 at 4:12 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:

> I'd still like to know about it for my personal information :-)

Maybe it is just a very cheap gamma.

>
>> Anyway, I am inclined to use ycbcr_enc as well.
>
> I'm glad we agree.
>

Are you thinking about something like this:


diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c7fb760386cf..3e613fba1b20 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -330,6 +330,16 @@ enum v4l2_ycbcr_encoding {
        V4L2_YCBCR_ENC_SMPTE240M      = 8,
 };

+enum v4l2_hsv_encoding {
+       V4L2_HSV_ENC_180        = 16,
+       V4L2_HSV_ENC_256        = 17,
+};
+
+enum v4l2_rgb_encoding {
+       V4L2_RGB_ENC_FULL       = 32,
+       V4L2_HSV_ENC_16_235     = 33,
+};
+
 /*
  * Determine how YCBCR_ENC_DEFAULT should map to a proper Y'CbCr encoding.
  * This depends on the colorspace.
@@ -455,7 +465,11 @@ struct v4l2_pix_format {
        __u32                   colorspace;     /* enum v4l2_colorspace */
        __u32                   priv;           /* private data,
depends on pixelformat */
        __u32                   flags;          /* format flags
(V4L2_PIX_FMT_FLAG_*) */
-       __u32                   ycbcr_enc;      /* enum v4l2_ycbcr_encoding */
+       union {
+               __u32                   ycbcr_enc;      /* enum
v4l2_ycbcr_encoding */
+               __u32                   hsv_enc;        /* enum
v4l2_hsv_encoding */
+               __u32                   rgb_enc;        /* enum
v4l2_rgb_encoding */
+       };
        __u32                   quantization;   /* enum v4l2_quantization */
        __u32                   xfer_func;      /* enum v4l2_xfer_func */
 };
@@ -1988,7 +2002,11 @@ struct v4l2_pix_format_mplane {
        struct v4l2_plane_pix_format    plane_fmt[VIDEO_MAX_PLANES];
        __u8                            num_planes;
        __u8                            flags;
-       __u8                            ycbcr_enc;
+       union {
+               __u8                    ycbcr_enc;      /* enum
v4l2_ycbcr_encoding */
+               __u8                    hsv_enc;        /* enum
v4l2_hsv_encoding */
+               __u8                    rgb_enc;        /* enum
v4l2_rgb_encoding */
+       };
        __u8                            quantization;
        __u8                            xfer_func;
        __u8                            reserved[7];

> --


Best regards!

-- 
Ricardo Ribalda

[toc] | [prev] | [next] | [standalone]

#1444868 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

On 07/16/2016 04:32 PM, Ricardo Ribalda Delgado wrote:
> Hi
> 
> On Sat, Jul 16, 2016 at 4:12 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
> 
>> I'd still like to know about it for my personal information :-)
> 
> Maybe it is just a very cheap gamma.
> 
>>
>>> Anyway, I am inclined to use ycbcr_enc as well.
>>
>> I'm glad we agree.
>>
> 
> Are you thinking about something like this:
> 
> 
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index c7fb760386cf..3e613fba1b20 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -330,6 +330,16 @@ enum v4l2_ycbcr_encoding {
>         V4L2_YCBCR_ENC_SMPTE240M      = 8,
>  };
> 
> +enum v4l2_hsv_encoding {
> +       V4L2_HSV_ENC_180        = 16,
> +       V4L2_HSV_ENC_256        = 17,
> +};

Yes.

> +
> +enum v4l2_rgb_encoding {
> +       V4L2_RGB_ENC_FULL       = 32,
> +       V4L2_HSV_ENC_16_235     = 33,
> +};

No.

The starting point is RGB, so there is nothing to encode. YCbCr and HSV
are transformations from RGB (or R'G'B' to be precise).

The basic chain is:

XYZ -> colorspace conversion -> RGB -> transfer function -> R'G'B'

and after this there is an optional step that converts R'G'B' to
Y'CbCr or HSV (ycbcr_enc or hsv_enc). The final step is the quantization
step where you end up with the actual color component values.

There doesn't seem to be something like limited range HSV, so I'd say it's
full range only.

Regards,

	Hans

> +
>  /*
>   * Determine how YCBCR_ENC_DEFAULT should map to a proper Y'CbCr encoding.
>   * This depends on the colorspace.
> @@ -455,7 +465,11 @@ struct v4l2_pix_format {
>         __u32                   colorspace;     /* enum v4l2_colorspace */
>         __u32                   priv;           /* private data,
> depends on pixelformat */
>         __u32                   flags;          /* format flags
> (V4L2_PIX_FMT_FLAG_*) */
> -       __u32                   ycbcr_enc;      /* enum v4l2_ycbcr_encoding */
> +       union {
> +               __u32                   ycbcr_enc;      /* enum
> v4l2_ycbcr_encoding */
> +               __u32                   hsv_enc;        /* enum
> v4l2_hsv_encoding */
> +               __u32                   rgb_enc;        /* enum
> v4l2_rgb_encoding */
> +       };
>         __u32                   quantization;   /* enum v4l2_quantization */
>         __u32                   xfer_func;      /* enum v4l2_xfer_func */
>  };
> @@ -1988,7 +2002,11 @@ struct v4l2_pix_format_mplane {
>         struct v4l2_plane_pix_format    plane_fmt[VIDEO_MAX_PLANES];
>         __u8                            num_planes;
>         __u8                            flags;
> -       __u8                            ycbcr_enc;
> +       union {
> +               __u8                    ycbcr_enc;      /* enum
> v4l2_ycbcr_encoding */
> +               __u8                    hsv_enc;        /* enum
> v4l2_hsv_encoding */
> +               __u8                    rgb_enc;        /* enum
> v4l2_rgb_encoding */
> +       };
>         __u8                            quantization;
>         __u8                            xfer_func;
>         __u8                            reserved[7];
> 
>> --
> 
> 
> Best regards!
> 

[toc] | [prev] | [next] | [standalone]

#1444869 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

Hi Hans

On Sat, Jul 16, 2016 at 5:28 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:

>
>> +
>> +enum v4l2_rgb_encoding {
>> +       V4L2_RGB_ENC_FULL       = 32,
>> +       V4L2_HSV_ENC_16_235     = 33,
>> +};
>
> No.

I was trying to fit also Laurent special 16-235 RGB format. I will
remove it on future versions.


Can I make this change as 2 new patches on my vivid-hsv patchset?

1) Add hsv_encoding
2) Add support for vivid hsv_encoding


?


Best Regards

[toc] | [prev] | [next] | [standalone]

#1444876 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

On 07/16/2016 05:57 PM, Ricardo Ribalda Delgado wrote:
> Hi Hans
> 
> On Sat, Jul 16, 2016 at 5:28 PM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> 
>>
>>> +
>>> +enum v4l2_rgb_encoding {
>>> +       V4L2_RGB_ENC_FULL       = 32,
>>> +       V4L2_HSV_ENC_16_235     = 33,
>>> +};
>>
>> No.
> 
> I was trying to fit also Laurent special 16-235 RGB format. I will
> remove it on future versions.
> 
> 
> Can I make this change as 2 new patches on my vivid-hsv patchset?
> 
> 1) Add hsv_encoding
> 2) Add support for vivid hsv_encoding

Yes. I prefer them last in the series, since I am not quite 100% certain yet.

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1444865 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

On 07/16/2016 04:12 PM, Laurent Pinchart wrote:
>> Limited vs full range quantization is handled by the quantization field.
>> It's there already.
> 
> Right. I wonder how we'll deal with that when someone will come up with more 
> than one limited range quantizations, have you thought about it ?

There is just limited and full range. Limited range is basically a left-over
from analog TV.

>> Limited range RGB is needed for HDMI due to a brain-dead spec when dealing
>> with certain kinds of TVs and configurations. Don't ask, it's horrible.
> 
> I'd still like to know about it for my personal information :-)

RGB video over HDMI is limited range for CE timings (i.e. 720p, 1080p, 4k)
unless signaled otherwise through the AVI InfoFrame. And you can only
signal that if the sink supports it in the EDID (and doesn't lie about it).

Typically TVs follow CE timings, so hooking up a PC to a TV may very well
cause problems (and often does).

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1444777 — Re: [PATCH v2 2/6] [media] Documentation: Add HSV format

Hi Laurent

It is actually a very good comment. :) In our case we have implemented
the format ourselves in the FPGA and we support both 0-255 and 0-179
Hue ranges.

After some weeks of use, only the 0-179 range is used in userpace. The
reasons for this is mainly that it is the format used by OpenCV
http://docs.opencv.org/3.1.0/de/d25/imgproc_color_conversions.html#color_convert_rgb_hsv&gsc.tab=0
, but also because it is very efficient to convert from 0-360 to 0-180
and the lose of color resolution (256/180) does not lead to (human)
perceptible differences.

All that said, I would not mind to implement also the 0-255 range, but
I do not know which API should be the best way to do it. quantization?
it looks nice, but it is not really a quantization... a control? a bit
messy.... fourcc? seems good...

I am open to anything :), but I am not the right guy for making the
decision. Hans, could you help me?


Thanks!

On Fri, Jul 15, 2016 at 8:11 PM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> Hi Ricardo,
>
> Thank you for the patch.
>
> On Friday 15 Jul 2016 18:13:15 Ricardo Ribalda Delgado wrote:
>> Describe the HSV formats
>>
>> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
>> ---
>>  Documentation/media/uapi/v4l/hsv-formats.rst       |  19 ++
>>  Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst | 253 ++++++++++++++++++
>>  Documentation/media/uapi/v4l/pixfmt.rst            |   1 +
>>  Documentation/media/uapi/v4l/v4l2.rst              |   5 +
>>  4 files changed, 278 insertions(+)
>>  create mode 100644 Documentation/media/uapi/v4l/hsv-formats.rst
>>  create mode 100644 Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>>
>> diff --git a/Documentation/media/uapi/v4l/hsv-formats.rst
>> b/Documentation/media/uapi/v4l/hsv-formats.rst new file mode 100644
>> index 000000000000..f0f2615eaa95
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/hsv-formats.rst
>> @@ -0,0 +1,19 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _hsv-formats:
>> +
>> +***********
>> +HSV Formats
>> +***********
>> +
>> +These formats store the color information of the image
>> +in a geometrical representation. The colors are mapped into a
>> +cylinder, where the angle is the HUE, the height is the VALUE
>> +and the distance to the center is the SATURATION. This is a very
>> +useful format for image segmentation algorithms.
>> +
>> +
>> +.. toctree::
>> +    :maxdepth: 1
>> +
>> +    pixfmt-packed-hsv
>> diff --git a/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst new file mode 100644
>> index 000000000000..b297aa4f7ba6
>> --- /dev/null
>> +++ b/Documentation/media/uapi/v4l/pixfmt-packed-hsv.rst
>> @@ -0,0 +1,253 @@
>> +.. -*- coding: utf-8; mode: rst -*-
>> +
>> +.. _packed-hsv:
>> +
>> +******************
>> +Packed HSV formats
>> +******************
>> +
>> +*man Packed HSV formats(2)*
>> +
>> +Packed HSV formats
>> +
>> +
>> +Description
>> +===========
>> +
>> +The HUE (h) is meassured in degrees, one LSB represents two degrees.
>
> Is this common ? I have a device that can handle HSV data, I need to check how
> it maps the hue values to binary, but I'm pretty sure they cover the full
> 0-255 range. We would then have to support the two formats. Separate 4CCs are
> an option, but reporting the range separately (possibly through the colorspace
> API) might be better. Any thought on that ?
>
>> +The SATURATION (s) and the VALUE (v) are measured in percentage of the
>> +cylinder: 0 being the smallest value and 255 the maximum.
>> +
>> +
>> +The values are packed in 24 or 32 bit formats.
>> +
>> +
>> +.. flat-table:: Packed HSV Image Formats
>> +    :header-rows:  2
>> +    :stub-columns: 0
>> +
>> +
>> +    -  .. row 1
>> +
>> +       -  Identifier
>> +
>> +       -  Code
>> +
>> +       -
>> +       -  :cspan:`7` Byte 0 in memory
>> +
>
> Do we really need all those blank lines ?
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>



-- 
Ricardo Ribalda

[toc] | [prev] | [next] | [standalone]

#1444423 — [PATCH v2 6/6] [media] vivid: Rename variable

r_y and g_u now also contain the H and V components on the HSV formats.
Rename the variables to reflect this.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 209 +++++++++++++-------------
 1 file changed, 105 insertions(+), 104 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index 85b9c1925dd9..dba6656082d8 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -1012,7 +1012,7 @@ static void gen_twopix(struct tpg_data *tpg,
 {
 	unsigned offset = odd * tpg->twopixelsize[0] / 2;
 	u8 alpha = tpg->alpha_component;
-	u8 r_y, g_u, b_v;
+	u8 r_y_h, g_u_s, b_v;
 
 	if (tpg->alpha_red_only && color != TPG_COLOR_CSC_RED &&
 				   color != TPG_COLOR_100_RED &&
@@ -1020,161 +1020,161 @@ static void gen_twopix(struct tpg_data *tpg,
 		alpha = 0;
 	if (color == TPG_COLOR_RANDOM)
 		precalculate_color(tpg, color);
-	r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
-	g_u = tpg->colors[color][1]; /* G or precalculated U, V */
+	r_y_h = tpg->colors[color][0]; /* R or precalculated Y, H */
+	g_u_s = tpg->colors[color][1]; /* G or precalculated U, V */
 	b_v = tpg->colors[color][2]; /* B or precalculated V */
 
 	switch (tpg->fourcc) {
 	case V4L2_PIX_FMT_GREY:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		break;
 	case V4L2_PIX_FMT_Y16:
 		/*
-		 * Ideally both bytes should be set to r_y, but then you won't
+		 * Ideally both bytes should be set to r_y_h, but then you won't
 		 * be able to detect endian problems. So keep it 0 except for
-		 * the corner case where r_y is 0xff so white really will be
+		 * the corner case where r_y_h is 0xff so white really will be
 		 * white (0xffff).
 		 */
-		buf[0][offset] = r_y == 0xff ? r_y : 0;
-		buf[0][offset+1] = r_y;
+		buf[0][offset] = r_y_h == 0xff ? r_y_h : 0;
+		buf[0][offset+1] = r_y_h;
 		break;
 	case V4L2_PIX_FMT_Y16_BE:
 		/* See comment for V4L2_PIX_FMT_Y16 above */
-		buf[0][offset] = r_y;
-		buf[0][offset+1] = r_y == 0xff ? r_y : 0;
+		buf[0][offset] = r_y_h;
+		buf[0][offset+1] = r_y_h == 0xff ? r_y_h : 0;
 		break;
 	case V4L2_PIX_FMT_YUV422M:
 	case V4L2_PIX_FMT_YUV422P:
 	case V4L2_PIX_FMT_YUV420:
 	case V4L2_PIX_FMT_YUV420M:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		if (odd) {
-			buf[1][0] = (buf[1][0] + g_u) / 2;
+			buf[1][0] = (buf[1][0] + g_u_s) / 2;
 			buf[2][0] = (buf[2][0] + b_v) / 2;
 			buf[1][1] = buf[1][0];
 			buf[2][1] = buf[2][0];
 			break;
 		}
-		buf[1][0] = g_u;
+		buf[1][0] = g_u_s;
 		buf[2][0] = b_v;
 		break;
 	case V4L2_PIX_FMT_YVU422M:
 	case V4L2_PIX_FMT_YVU420:
 	case V4L2_PIX_FMT_YVU420M:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		if (odd) {
 			buf[1][0] = (buf[1][0] + b_v) / 2;
-			buf[2][0] = (buf[2][0] + g_u) / 2;
+			buf[2][0] = (buf[2][0] + g_u_s) / 2;
 			buf[1][1] = buf[1][0];
 			buf[2][1] = buf[2][0];
 			break;
 		}
 		buf[1][0] = b_v;
-		buf[2][0] = g_u;
+		buf[2][0] = g_u_s;
 		break;
 
 	case V4L2_PIX_FMT_NV12:
 	case V4L2_PIX_FMT_NV12M:
 	case V4L2_PIX_FMT_NV16:
 	case V4L2_PIX_FMT_NV16M:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		if (odd) {
-			buf[1][0] = (buf[1][0] + g_u) / 2;
+			buf[1][0] = (buf[1][0] + g_u_s) / 2;
 			buf[1][1] = (buf[1][1] + b_v) / 2;
 			break;
 		}
-		buf[1][0] = g_u;
+		buf[1][0] = g_u_s;
 		buf[1][1] = b_v;
 		break;
 	case V4L2_PIX_FMT_NV21:
 	case V4L2_PIX_FMT_NV21M:
 	case V4L2_PIX_FMT_NV61:
 	case V4L2_PIX_FMT_NV61M:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		if (odd) {
 			buf[1][0] = (buf[1][0] + b_v) / 2;
-			buf[1][1] = (buf[1][1] + g_u) / 2;
+			buf[1][1] = (buf[1][1] + g_u_s) / 2;
 			break;
 		}
 		buf[1][0] = b_v;
-		buf[1][1] = g_u;
+		buf[1][1] = g_u_s;
 		break;
 
 	case V4L2_PIX_FMT_YUV444M:
-		buf[0][offset] = r_y;
-		buf[1][offset] = g_u;
+		buf[0][offset] = r_y_h;
+		buf[1][offset] = g_u_s;
 		buf[2][offset] = b_v;
 		break;
 
 	case V4L2_PIX_FMT_YVU444M:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		buf[1][offset] = b_v;
-		buf[2][offset] = g_u;
+		buf[2][offset] = g_u_s;
 		break;
 
 	case V4L2_PIX_FMT_NV24:
-		buf[0][offset] = r_y;
-		buf[1][2 * offset] = g_u;
+		buf[0][offset] = r_y_h;
+		buf[1][2 * offset] = g_u_s;
 		buf[1][2 * offset + 1] = b_v;
 		break;
 
 	case V4L2_PIX_FMT_NV42:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		buf[1][2 * offset] = b_v;
-		buf[1][2 * offset + 1] = g_u;
+		buf[1][2 * offset + 1] = g_u_s;
 		break;
 
 	case V4L2_PIX_FMT_YUYV:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		if (odd) {
-			buf[0][1] = (buf[0][1] + g_u) / 2;
+			buf[0][1] = (buf[0][1] + g_u_s) / 2;
 			buf[0][3] = (buf[0][3] + b_v) / 2;
 			break;
 		}
-		buf[0][1] = g_u;
+		buf[0][1] = g_u_s;
 		buf[0][3] = b_v;
 		break;
 	case V4L2_PIX_FMT_UYVY:
-		buf[0][offset + 1] = r_y;
+		buf[0][offset + 1] = r_y_h;
 		if (odd) {
-			buf[0][0] = (buf[0][0] + g_u) / 2;
+			buf[0][0] = (buf[0][0] + g_u_s) / 2;
 			buf[0][2] = (buf[0][2] + b_v) / 2;
 			break;
 		}
-		buf[0][0] = g_u;
+		buf[0][0] = g_u_s;
 		buf[0][2] = b_v;
 		break;
 	case V4L2_PIX_FMT_YVYU:
-		buf[0][offset] = r_y;
+		buf[0][offset] = r_y_h;
 		if (odd) {
 			buf[0][1] = (buf[0][1] + b_v) / 2;
-			buf[0][3] = (buf[0][3] + g_u) / 2;
+			buf[0][3] = (buf[0][3] + g_u_s) / 2;
 			break;
 		}
 		buf[0][1] = b_v;
-		buf[0][3] = g_u;
+		buf[0][3] = g_u_s;
 		break;
 	case V4L2_PIX_FMT_VYUY:
-		buf[0][offset + 1] = r_y;
+		buf[0][offset + 1] = r_y_h;
 		if (odd) {
 			buf[0][0] = (buf[0][0] + b_v) / 2;
-			buf[0][2] = (buf[0][2] + g_u) / 2;
+			buf[0][2] = (buf[0][2] + g_u_s) / 2;
 			break;
 		}
 		buf[0][0] = b_v;
-		buf[0][2] = g_u;
+		buf[0][2] = g_u_s;
 		break;
 	case V4L2_PIX_FMT_RGB332:
-		buf[0][offset] = (r_y << 5) | (g_u << 2) | b_v;
+		buf[0][offset] = (r_y_h << 5) | (g_u_s << 2) | b_v;
 		break;
 	case V4L2_PIX_FMT_YUV565:
 	case V4L2_PIX_FMT_RGB565:
-		buf[0][offset] = (g_u << 5) | b_v;
-		buf[0][offset + 1] = (r_y << 3) | (g_u >> 3);
+		buf[0][offset] = (g_u_s << 5) | b_v;
+		buf[0][offset + 1] = (r_y_h << 3) | (g_u_s >> 3);
 		break;
 	case V4L2_PIX_FMT_RGB565X:
-		buf[0][offset] = (r_y << 3) | (g_u >> 3);
-		buf[0][offset + 1] = (g_u << 5) | b_v;
+		buf[0][offset] = (r_y_h << 3) | (g_u_s >> 3);
+		buf[0][offset + 1] = (g_u_s << 5) | b_v;
 		break;
 	case V4L2_PIX_FMT_RGB444:
 	case V4L2_PIX_FMT_XRGB444:
@@ -1182,8 +1182,8 @@ static void gen_twopix(struct tpg_data *tpg,
 		/* fall through */
 	case V4L2_PIX_FMT_YUV444:
 	case V4L2_PIX_FMT_ARGB444:
-		buf[0][offset] = (g_u << 4) | b_v;
-		buf[0][offset + 1] = (alpha & 0xf0) | r_y;
+		buf[0][offset] = (g_u_s << 4) | b_v;
+		buf[0][offset + 1] = (alpha & 0xf0) | r_y_h;
 		break;
 	case V4L2_PIX_FMT_RGB555:
 	case V4L2_PIX_FMT_XRGB555:
@@ -1191,32 +1191,33 @@ static void gen_twopix(struct tpg_data *tpg,
 		/* fall through */
 	case V4L2_PIX_FMT_YUV555:
 	case V4L2_PIX_FMT_ARGB555:
-		buf[0][offset] = (g_u << 5) | b_v;
-		buf[0][offset + 1] = (alpha & 0x80) | (r_y << 2) | (g_u >> 3);
+		buf[0][offset] = (g_u_s << 5) | b_v;
+		buf[0][offset + 1] = (alpha & 0x80) | (r_y_h << 2)
+						    | (g_u_s >> 3);
 		break;
 	case V4L2_PIX_FMT_RGB555X:
 	case V4L2_PIX_FMT_XRGB555X:
 		alpha = 0;
 		/* fall through */
 	case V4L2_PIX_FMT_ARGB555X:
-		buf[0][offset] = (alpha & 0x80) | (r_y << 2) | (g_u >> 3);
-		buf[0][offset + 1] = (g_u << 5) | b_v;
+		buf[0][offset] = (alpha & 0x80) | (r_y_h << 2) | (g_u_s >> 3);
+		buf[0][offset + 1] = (g_u_s << 5) | b_v;
 		break;
 	case V4L2_PIX_FMT_RGB24:
 	case V4L2_PIX_FMT_HSV24:
-		buf[0][offset] = r_y;
-		buf[0][offset + 1] = g_u;
+		buf[0][offset] = r_y_h;
+		buf[0][offset + 1] = g_u_s;
 		buf[0][offset + 2] = b_v;
 		break;
 	case V4L2_PIX_FMT_BGR24:
 		buf[0][offset] = b_v;
-		buf[0][offset + 1] = g_u;
-		buf[0][offset + 2] = r_y;
+		buf[0][offset + 1] = g_u_s;
+		buf[0][offset + 2] = r_y_h;
 		break;
 	case V4L2_PIX_FMT_BGR666:
-		buf[0][offset] = (b_v << 2) | (g_u >> 4);
-		buf[0][offset + 1] = (g_u << 4) | (r_y >> 2);
-		buf[0][offset + 2] = r_y << 6;
+		buf[0][offset] = (b_v << 2) | (g_u_s >> 4);
+		buf[0][offset + 1] = (g_u_s << 4) | (r_y_h >> 2);
+		buf[0][offset + 2] = r_y_h << 6;
 		buf[0][offset + 3] = 0;
 		break;
 	case V4L2_PIX_FMT_RGB32:
@@ -1227,8 +1228,8 @@ static void gen_twopix(struct tpg_data *tpg,
 	case V4L2_PIX_FMT_YUV32:
 	case V4L2_PIX_FMT_ARGB32:
 		buf[0][offset] = alpha;
-		buf[0][offset + 1] = r_y;
-		buf[0][offset + 2] = g_u;
+		buf[0][offset + 1] = r_y_h;
+		buf[0][offset + 2] = g_u_s;
 		buf[0][offset + 3] = b_v;
 		break;
 	case V4L2_PIX_FMT_BGR32:
@@ -1237,87 +1238,87 @@ static void gen_twopix(struct tpg_data *tpg,
 		/* fall through */
 	case V4L2_PIX_FMT_ABGR32:
 		buf[0][offset] = b_v;
-		buf[0][offset + 1] = g_u;
-		buf[0][offset + 2] = r_y;
+		buf[0][offset + 1] = g_u_s;
+		buf[0][offset + 2] = r_y_h;
 		buf[0][offset + 3] = alpha;
 		break;
 	case V4L2_PIX_FMT_SBGGR8:
-		buf[0][offset] = odd ? g_u : b_v;
-		buf[1][offset] = odd ? r_y : g_u;
+		buf[0][offset] = odd ? g_u_s : b_v;
+		buf[1][offset] = odd ? r_y_h : g_u_s;
 		break;
 	case V4L2_PIX_FMT_SGBRG8:
-		buf[0][offset] = odd ? b_v : g_u;
-		buf[1][offset] = odd ? g_u : r_y;
+		buf[0][offset] = odd ? b_v : g_u_s;
+		buf[1][offset] = odd ? g_u_s : r_y_h;
 		break;
 	case V4L2_PIX_FMT_SGRBG8:
-		buf[0][offset] = odd ? r_y : g_u;
-		buf[1][offset] = odd ? g_u : b_v;
+		buf[0][offset] = odd ? r_y_h : g_u_s;
+		buf[1][offset] = odd ? g_u_s : b_v;
 		break;
 	case V4L2_PIX_FMT_SRGGB8:
-		buf[0][offset] = odd ? g_u : r_y;
-		buf[1][offset] = odd ? b_v : g_u;
+		buf[0][offset] = odd ? g_u_s : r_y_h;
+		buf[1][offset] = odd ? b_v : g_u_s;
 		break;
 	case V4L2_PIX_FMT_SBGGR10:
-		buf[0][offset] = odd ? g_u << 2 : b_v << 2;
-		buf[0][offset + 1] = odd ? g_u >> 6 : b_v >> 6;
-		buf[1][offset] = odd ? r_y << 2 : g_u << 2;
-		buf[1][offset + 1] = odd ? r_y >> 6 : g_u >> 6;
+		buf[0][offset] = odd ? g_u_s << 2 : b_v << 2;
+		buf[0][offset + 1] = odd ? g_u_s >> 6 : b_v >> 6;
+		buf[1][offset] = odd ? r_y_h << 2 : g_u_s << 2;
+		buf[1][offset + 1] = odd ? r_y_h >> 6 : g_u_s >> 6;
 		buf[0][offset] |= (buf[0][offset] >> 2) & 3;
 		buf[1][offset] |= (buf[1][offset] >> 2) & 3;
 		break;
 	case V4L2_PIX_FMT_SGBRG10:
-		buf[0][offset] = odd ? b_v << 2 : g_u << 2;
-		buf[0][offset + 1] = odd ? b_v >> 6 : g_u >> 6;
-		buf[1][offset] = odd ? g_u << 2 : r_y << 2;
-		buf[1][offset + 1] = odd ? g_u >> 6 : r_y >> 6;
+		buf[0][offset] = odd ? b_v << 2 : g_u_s << 2;
+		buf[0][offset + 1] = odd ? b_v >> 6 : g_u_s >> 6;
+		buf[1][offset] = odd ? g_u_s << 2 : r_y_h << 2;
+		buf[1][offset + 1] = odd ? g_u_s >> 6 : r_y_h >> 6;
 		buf[0][offset] |= (buf[0][offset] >> 2) & 3;
 		buf[1][offset] |= (buf[1][offset] >> 2) & 3;
 		break;
 	case V4L2_PIX_FMT_SGRBG10:
-		buf[0][offset] = odd ? r_y << 2 : g_u << 2;
-		buf[0][offset + 1] = odd ? r_y >> 6 : g_u >> 6;
-		buf[1][offset] = odd ? g_u << 2 : b_v << 2;
-		buf[1][offset + 1] = odd ? g_u >> 6 : b_v >> 6;
+		buf[0][offset] = odd ? r_y_h << 2 : g_u_s << 2;
+		buf[0][offset + 1] = odd ? r_y_h >> 6 : g_u_s >> 6;
+		buf[1][offset] = odd ? g_u_s << 2 : b_v << 2;
+		buf[1][offset + 1] = odd ? g_u_s >> 6 : b_v >> 6;
 		buf[0][offset] |= (buf[0][offset] >> 2) & 3;
 		buf[1][offset] |= (buf[1][offset] >> 2) & 3;
 		break;
 	case V4L2_PIX_FMT_SRGGB10:
-		buf[0][offset] = odd ? g_u << 2 : r_y << 2;
-		buf[0][offset + 1] = odd ? g_u >> 6 : r_y >> 6;
-		buf[1][offset] = odd ? b_v << 2 : g_u << 2;
-		buf[1][offset + 1] = odd ? b_v >> 6 : g_u >> 6;
+		buf[0][offset] = odd ? g_u_s << 2 : r_y_h << 2;
+		buf[0][offset + 1] = odd ? g_u_s >> 6 : r_y_h >> 6;
+		buf[1][offset] = odd ? b_v << 2 : g_u_s << 2;
+		buf[1][offset + 1] = odd ? b_v >> 6 : g_u_s >> 6;
 		buf[0][offset] |= (buf[0][offset] >> 2) & 3;
 		buf[1][offset] |= (buf[1][offset] >> 2) & 3;
 		break;
 	case V4L2_PIX_FMT_SBGGR12:
-		buf[0][offset] = odd ? g_u << 4 : b_v << 4;
-		buf[0][offset + 1] = odd ? g_u >> 4 : b_v >> 4;
-		buf[1][offset] = odd ? r_y << 4 : g_u << 4;
-		buf[1][offset + 1] = odd ? r_y >> 4 : g_u >> 4;
+		buf[0][offset] = odd ? g_u_s << 4 : b_v << 4;
+		buf[0][offset + 1] = odd ? g_u_s >> 4 : b_v >> 4;
+		buf[1][offset] = odd ? r_y_h << 4 : g_u_s << 4;
+		buf[1][offset + 1] = odd ? r_y_h >> 4 : g_u_s >> 4;
 		buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
 		buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
 		break;
 	case V4L2_PIX_FMT_SGBRG12:
-		buf[0][offset] = odd ? b_v << 4 : g_u << 4;
-		buf[0][offset + 1] = odd ? b_v >> 4 : g_u >> 4;
-		buf[1][offset] = odd ? g_u << 4 : r_y << 4;
-		buf[1][offset + 1] = odd ? g_u >> 4 : r_y >> 4;
+		buf[0][offset] = odd ? b_v << 4 : g_u_s << 4;
+		buf[0][offset + 1] = odd ? b_v >> 4 : g_u_s >> 4;
+		buf[1][offset] = odd ? g_u_s << 4 : r_y_h << 4;
+		buf[1][offset + 1] = odd ? g_u_s >> 4 : r_y_h >> 4;
 		buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
 		buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
 		break;
 	case V4L2_PIX_FMT_SGRBG12:
-		buf[0][offset] = odd ? r_y << 4 : g_u << 4;
-		buf[0][offset + 1] = odd ? r_y >> 4 : g_u >> 4;
-		buf[1][offset] = odd ? g_u << 4 : b_v << 4;
-		buf[1][offset + 1] = odd ? g_u >> 4 : b_v >> 4;
+		buf[0][offset] = odd ? r_y_h << 4 : g_u_s << 4;
+		buf[0][offset + 1] = odd ? r_y_h >> 4 : g_u_s >> 4;
+		buf[1][offset] = odd ? g_u_s << 4 : b_v << 4;
+		buf[1][offset + 1] = odd ? g_u_s >> 4 : b_v >> 4;
 		buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
 		buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
 		break;
 	case V4L2_PIX_FMT_SRGGB12:
-		buf[0][offset] = odd ? g_u << 4 : r_y << 4;
-		buf[0][offset + 1] = odd ? g_u >> 4 : r_y >> 4;
-		buf[1][offset] = odd ? b_v << 4 : g_u << 4;
-		buf[1][offset + 1] = odd ? b_v >> 4 : g_u >> 4;
+		buf[0][offset] = odd ? g_u_s << 4 : r_y_h << 4;
+		buf[0][offset + 1] = odd ? g_u_s >> 4 : r_y_h >> 4;
+		buf[1][offset] = odd ? b_v << 4 : g_u_s << 4;
+		buf[1][offset + 1] = odd ? b_v >> 4 : g_u_s >> 4;
 		buf[0][offset] |= (buf[0][offset] >> 4) & 0xf;
 		buf[1][offset] |= (buf[1][offset] >> 4) & 0xf;
 		break;
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444424 — [PATCH v2 5/6] [media] vivid: Add support for HSV formats

This patch adds support for V4L2_PIX_FMT_HSV24 and V4L2_PIX_FMT_HSV32.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 94 +++++++++++++++++++++++--
 drivers/media/platform/vivid/vivid-vid-common.c | 14 ++++
 include/media/v4l2-tpg.h                        |  1 +
 3 files changed, 105 insertions(+), 4 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index acf0e6854832..85b9c1925dd9 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -318,6 +318,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->hmask[0] = ~1;
 		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
+	case V4L2_PIX_FMT_HSV24:
+	case V4L2_PIX_FMT_HSV32:
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_HSV;
+		break;
 	default:
 		return false;
 	}
@@ -351,6 +355,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		break;
 	case V4L2_PIX_FMT_RGB24:
 	case V4L2_PIX_FMT_BGR24:
+	case V4L2_PIX_FMT_HSV24:
 		tpg->twopixelsize[0] = 2 * 3;
 		break;
 	case V4L2_PIX_FMT_BGR666:
@@ -361,6 +366,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 	case V4L2_PIX_FMT_ARGB32:
 	case V4L2_PIX_FMT_ABGR32:
 	case V4L2_PIX_FMT_YUV32:
+	case V4L2_PIX_FMT_HSV32:
 		tpg->twopixelsize[0] = 2 * 4;
 		break;
 	case V4L2_PIX_FMT_NV12:
@@ -408,6 +414,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->twopixelsize[1] = 4;
 		break;
 	}
+
 	return true;
 }
 EXPORT_SYMBOL_GPL(tpg_s_fourcc);
@@ -490,6 +497,64 @@ static inline int linear_to_rec709(int v)
 	return tpg_linear_to_rec709[v];
 }
 
+static void color_to_hsv(struct tpg_data *tpg, int r, int g, int b,
+			   int *h, int *s, int *v)
+{
+	int max_rgb, min_rgb, diff_rgb;
+	int aux;
+	int third;
+
+	r >>= 4;
+	g >>= 4;
+	b >>= 4;
+
+	/*V*/
+	max_rgb = max3(r, g, b);
+	*v = max_rgb;
+	if (!max_rgb) {
+		*h = 0;
+		*s = 0;
+		return;
+	}
+
+	/*S*/
+	min_rgb = min3(r, g, b);
+	diff_rgb = max_rgb - min_rgb;
+	aux = 255 * diff_rgb;
+	aux += max_rgb / 2;
+	aux /= max_rgb;
+	*s = aux;
+	if (!aux) {
+		*h = 0;
+		return;
+	}
+
+	/*H*/
+	if (max_rgb == r) {
+		aux =  g - b;
+		third = 0;
+	} else if (max_rgb == g) {
+		aux =  b - r;
+		third = 60;
+	} else {
+		aux =  r - g;
+		third = 120;
+	}
+
+	aux *= 30;
+	aux += diff_rgb / 2;
+	aux /= diff_rgb;
+	aux += third;
+
+	/*Clamp H*/
+	if (aux < 0)
+		aux += 180;
+	else if (aux > 180)
+		aux -= 180;
+	*h = aux;
+
+}
+
 static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
 			int y_offset, int *y, int *cb, int *cr)
 {
@@ -829,7 +894,19 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 		ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
 	}
 
-	if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
+	switch (tpg->color_representation) {
+	case TGP_COLOR_REPRESENTATION_HSV:
+	{
+		int h, s, v;
+
+		color_to_hsv(tpg, r, g, b, &h, &s, &v);
+		tpg->colors[k][0] = h;
+		tpg->colors[k][1] = s;
+		tpg->colors[k][2] = v;
+		break;
+	}
+	case TGP_COLOR_REPRESENTATION_YUV:
+	{
 		/* Convert to YCbCr */
 		int y, cb, cr;
 
@@ -863,7 +940,10 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 		tpg->colors[k][0] = y;
 		tpg->colors[k][1] = cb;
 		tpg->colors[k][2] = cr;
-	} else {
+		break;
+	}
+	case TGP_COLOR_REPRESENTATION_RGB:
+	{
 		if (tpg->real_quantization == V4L2_QUANTIZATION_LIM_RANGE) {
 			r = (r * 219) / 255 + (16 << 4);
 			g = (g * 219) / 255 + (16 << 4);
@@ -913,6 +993,8 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 		tpg->colors[k][0] = r;
 		tpg->colors[k][1] = g;
 		tpg->colors[k][2] = b;
+		break;
+	}
 	}
 }
 
@@ -938,8 +1020,8 @@ static void gen_twopix(struct tpg_data *tpg,
 		alpha = 0;
 	if (color == TPG_COLOR_RANDOM)
 		precalculate_color(tpg, color);
-	r_y = tpg->colors[color][0]; /* R or precalculated Y */
-	g_u = tpg->colors[color][1]; /* G or precalculated U */
+	r_y = tpg->colors[color][0]; /* R or precalculated Y, H */
+	g_u = tpg->colors[color][1]; /* G or precalculated U, V */
 	b_v = tpg->colors[color][2]; /* B or precalculated V */
 
 	switch (tpg->fourcc) {
@@ -1121,6 +1203,7 @@ static void gen_twopix(struct tpg_data *tpg,
 		buf[0][offset + 1] = (g_u << 5) | b_v;
 		break;
 	case V4L2_PIX_FMT_RGB24:
+	case V4L2_PIX_FMT_HSV24:
 		buf[0][offset] = r_y;
 		buf[0][offset + 1] = g_u;
 		buf[0][offset + 2] = b_v;
@@ -1138,6 +1221,7 @@ static void gen_twopix(struct tpg_data *tpg,
 		break;
 	case V4L2_PIX_FMT_RGB32:
 	case V4L2_PIX_FMT_XRGB32:
+	case V4L2_PIX_FMT_HSV32:
 		alpha = 0;
 		/* fall through */
 	case V4L2_PIX_FMT_YUV32:
@@ -1896,6 +1980,8 @@ static const char *tpg_color_representation_str(enum tgp_color_representation
 {
 	switch (color_representation) {
 
+	case TGP_COLOR_REPRESENTATION_HSV:
+		return "HSV";
 	case TGP_COLOR_REPRESENTATION_YUV:
 		return "YCbCr";
 	case TGP_COLOR_REPRESENTATION_RGB:
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c
index 314799111cf7..cc985685ed05 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -445,6 +445,20 @@ struct vivid_fmt vivid_formats[] = {
 		.planes   = 1,
 		.buffers = 1,
 	},
+	{
+		.fourcc   = V4L2_PIX_FMT_HSV24, /* HSV 24bits */
+		.vdownsampling = { 1 },
+		.bit_depth = { 24 },
+		.planes   = 1,
+		.buffers = 1,
+	},
+	{
+		.fourcc   = V4L2_PIX_FMT_HSV32, /* HSV 32bits */
+		.vdownsampling = { 1 },
+		.bit_depth = { 32 },
+		.planes   = 1,
+		.buffers = 1,
+	},
 
 	/* Multiplanar formats */
 
diff --git a/include/media/v4l2-tpg.h b/include/media/v4l2-tpg.h
index 13ea42bb9530..17a257d12941 100644
--- a/include/media/v4l2-tpg.h
+++ b/include/media/v4l2-tpg.h
@@ -90,6 +90,7 @@ enum tpg_move_mode {
 enum tgp_color_representation {
 	TGP_COLOR_REPRESENTATION_RGB,
 	TGP_COLOR_REPRESENTATION_YUV,
+	TGP_COLOR_REPRESENTATION_HSV,
 };
 
 extern const char * const tpg_aspect_strings[];
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444506 — Re: [PATCH v2 5/6] [media] vivid: Add support for HSV formats

On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
> This patch adds support for V4L2_PIX_FMT_HSV24 and V4L2_PIX_FMT_HSV32.
> 
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 94 +++++++++++++++++++++++--
>  drivers/media/platform/vivid/vivid-vid-common.c | 14 ++++
>  include/media/v4l2-tpg.h                        |  1 +
>  3 files changed, 105 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index acf0e6854832..85b9c1925dd9 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -318,6 +318,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->hmask[0] = ~1;
>  		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
> +	case V4L2_PIX_FMT_HSV24:
> +	case V4L2_PIX_FMT_HSV32:
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_HSV;
> +		break;
>  	default:
>  		return false;
>  	}
> @@ -351,6 +355,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		break;
>  	case V4L2_PIX_FMT_RGB24:
>  	case V4L2_PIX_FMT_BGR24:
> +	case V4L2_PIX_FMT_HSV24:
>  		tpg->twopixelsize[0] = 2 * 3;
>  		break;
>  	case V4L2_PIX_FMT_BGR666:
> @@ -361,6 +366,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  	case V4L2_PIX_FMT_ARGB32:
>  	case V4L2_PIX_FMT_ABGR32:
>  	case V4L2_PIX_FMT_YUV32:
> +	case V4L2_PIX_FMT_HSV32:
>  		tpg->twopixelsize[0] = 2 * 4;
>  		break;
>  	case V4L2_PIX_FMT_NV12:
> @@ -408,6 +414,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->twopixelsize[1] = 4;
>  		break;
>  	}
> +
>  	return true;
>  }
>  EXPORT_SYMBOL_GPL(tpg_s_fourcc);
> @@ -490,6 +497,64 @@ static inline int linear_to_rec709(int v)
>  	return tpg_linear_to_rec709[v];
>  }
>  
> +static void color_to_hsv(struct tpg_data *tpg, int r, int g, int b,
> +			   int *h, int *s, int *v)
> +{
> +	int max_rgb, min_rgb, diff_rgb;
> +	int aux;
> +	int third;
> +
> +	r >>= 4;
> +	g >>= 4;
> +	b >>= 4;
> +
> +	/*V*/

Please add a space after /* and before */.
I also think it is better to write Value, Saturation, Hue instead of
V, S, H.

> +	max_rgb = max3(r, g, b);
> +	*v = max_rgb;
> +	if (!max_rgb) {
> +		*h = 0;
> +		*s = 0;
> +		return;
> +	}
> +
> +	/*S*/
> +	min_rgb = min3(r, g, b);
> +	diff_rgb = max_rgb - min_rgb;
> +	aux = 255 * diff_rgb;
> +	aux += max_rgb / 2;
> +	aux /= max_rgb;
> +	*s = aux;
> +	if (!aux) {
> +		*h = 0;
> +		return;
> +	}
> +
> +	/*H*/
> +	if (max_rgb == r) {
> +		aux =  g - b;
> +		third = 0;
> +	} else if (max_rgb == g) {
> +		aux =  b - r;
> +		third = 60;
> +	} else {
> +		aux =  r - g;
> +		third = 120;
> +	}
> +
> +	aux *= 30;
> +	aux += diff_rgb / 2;
> +	aux /= diff_rgb;
> +	aux += third;
> +
> +	/*Clamp H*/
> +	if (aux < 0)
> +		aux += 180;
> +	else if (aux > 180)
> +		aux -= 180;
> +	*h = aux;
> +
> +}
> +
>  static void rgb2ycbcr(const int m[3][3], int r, int g, int b,
>  			int y_offset, int *y, int *cb, int *cr)
>  {
> @@ -829,7 +894,19 @@ static void precalculate_color(struct tpg_data *tpg, int k)
>  		ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
>  	}
>  
> -	if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
> +	switch (tpg->color_representation) {
> +	case TGP_COLOR_REPRESENTATION_HSV:
> +	{
> +		int h, s, v;
> +
> +		color_to_hsv(tpg, r, g, b, &h, &s, &v);
> +		tpg->colors[k][0] = h;
> +		tpg->colors[k][1] = s;
> +		tpg->colors[k][2] = v;

Would quantization (limited/full range) be relevant here? I don't know if limited
range would make sense (or what those limits would be).

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

#1444425 — [PATCH v2 4/6] [media] vivid: code refactor for color representation

Replace is_yuv with color_representation. Which can be used by HSV
formats.

This change should ease the review of the following patches.

Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 44 ++++++++++++++-------
 drivers/media/platform/vivid/vivid-core.h       |  2 +-
 drivers/media/platform/vivid/vivid-vid-common.c | 52 ++++++++++++-------------
 include/media/v4l2-tpg.h                        |  7 +++-
 4 files changed, 63 insertions(+), 42 deletions(-)

diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
index cf1dadd0be9e..acf0e6854832 100644
--- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
+++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
@@ -237,13 +237,13 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 	case V4L2_PIX_FMT_GREY:
 	case V4L2_PIX_FMT_Y16:
 	case V4L2_PIX_FMT_Y16_BE:
-		tpg->is_yuv = false;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_RGB;
 		break;
 	case V4L2_PIX_FMT_YUV444:
 	case V4L2_PIX_FMT_YUV555:
 	case V4L2_PIX_FMT_YUV565:
 	case V4L2_PIX_FMT_YUV32:
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_YUV420M:
 	case V4L2_PIX_FMT_YVU420M:
@@ -256,7 +256,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->hdownsampling[1] = 2;
 		tpg->hdownsampling[2] = 2;
 		tpg->planes = 3;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_YUV422M:
 	case V4L2_PIX_FMT_YVU422M:
@@ -268,7 +268,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->hdownsampling[1] = 2;
 		tpg->hdownsampling[2] = 2;
 		tpg->planes = 3;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_NV16M:
 	case V4L2_PIX_FMT_NV61M:
@@ -280,7 +280,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->hdownsampling[1] = 1;
 		tpg->hmask[1] = ~1;
 		tpg->planes = 2;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_NV12M:
 	case V4L2_PIX_FMT_NV21M:
@@ -292,7 +292,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->hdownsampling[1] = 1;
 		tpg->hmask[1] = ~1;
 		tpg->planes = 2;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_YUV444M:
 	case V4L2_PIX_FMT_YVU444M:
@@ -302,21 +302,21 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
 		tpg->vdownsampling[2] = 1;
 		tpg->hdownsampling[1] = 1;
 		tpg->hdownsampling[2] = 1;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_NV24:
 	case V4L2_PIX_FMT_NV42:
 		tpg->vdownsampling[1] = 1;
 		tpg->hdownsampling[1] = 1;
 		tpg->planes = 2;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	case V4L2_PIX_FMT_YUYV:
 	case V4L2_PIX_FMT_UYVY:
 	case V4L2_PIX_FMT_YVYU:
 	case V4L2_PIX_FMT_VYUY:
 		tpg->hmask[0] = ~1;
-		tpg->is_yuv = true;
+		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
 		break;
 	default:
 		return false;
@@ -820,7 +820,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 
 		cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / (128 * 128);
 		cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / (128 * 128);
-		if (tpg->is_yuv) {
+		if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
 			tpg->colors[k][0] = clamp(y >> 4, 1, 254);
 			tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
 			tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
@@ -829,7 +829,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
 		ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
 	}
 
-	if (tpg->is_yuv) {
+	if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
 		/* Convert to YCbCr */
 		int y, cb, cr;
 
@@ -1842,7 +1842,9 @@ static void tpg_recalc(struct tpg_data *tpg)
 
 		if (tpg->quantization == V4L2_QUANTIZATION_DEFAULT)
 			tpg->real_quantization =
-				V4L2_MAP_QUANTIZATION_DEFAULT(!tpg->is_yuv,
+				V4L2_MAP_QUANTIZATION_DEFAULT(
+					tpg->color_representation ==
+						TGP_COLOR_REPRESENTATION_RGB,
 					tpg->colorspace, tpg->real_ycbcr_enc);
 
 		tpg_precalculate_colors(tpg);
@@ -1889,11 +1891,25 @@ static int tpg_pattern_avg(const struct tpg_data *tpg,
 	return -1;
 }
 
+static const char *tpg_color_representation_str(enum tgp_color_representation
+						 color_representation)
+{
+	switch (color_representation) {
+
+	case TGP_COLOR_REPRESENTATION_YUV:
+		return "YCbCr";
+	case TGP_COLOR_REPRESENTATION_RGB:
+	default:
+		return "RGB";
+
+	}
+}
+
 void tpg_log_status(struct tpg_data *tpg)
 {
 	pr_info("tpg source WxH: %ux%u (%s)\n",
-			tpg->src_width, tpg->src_height,
-			tpg->is_yuv ? "YCbCr" : "RGB");
+		tpg->src_width, tpg->src_height,
+		tpg_color_representation_str(tpg->color_representation));
 	pr_info("tpg field: %u\n", tpg->field);
 	pr_info("tpg crop: %ux%u@%dx%d\n", tpg->crop.width, tpg->crop.height,
 			tpg->crop.left, tpg->crop.top);
diff --git a/drivers/media/platform/vivid/vivid-core.h b/drivers/media/platform/vivid/vivid-core.h
index a7daa40d0a49..191ba679ad65 100644
--- a/drivers/media/platform/vivid/vivid-core.h
+++ b/drivers/media/platform/vivid/vivid-core.h
@@ -80,7 +80,7 @@ extern unsigned vivid_debug;
 
 struct vivid_fmt {
 	u32	fourcc;          /* v4l2 format id */
-	bool	is_yuv;
+	enum tgp_color_representation color_representation;
 	bool	can_do_overlay;
 	u8	vdownsampling[TPG_MAX_PLANES];
 	u32	alpha_mask;
diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c
index fcda3ae4e6b0..314799111cf7 100644
--- a/drivers/media/platform/vivid/vivid-vid-common.c
+++ b/drivers/media/platform/vivid/vivid-vid-common.c
@@ -48,7 +48,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YUYV,
 		.vdownsampling = { 1 },
 		.bit_depth = { 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 		.data_offset = { PLANE0_DATA_OFFSET },
@@ -57,7 +57,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_UYVY,
 		.vdownsampling = { 1 },
 		.bit_depth = { 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 	},
@@ -65,7 +65,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YVYU,
 		.vdownsampling = { 1 },
 		.bit_depth = { 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 	},
@@ -73,7 +73,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_VYUY,
 		.vdownsampling = { 1 },
 		.bit_depth = { 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 	},
@@ -81,7 +81,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YUV422P,
 		.vdownsampling = { 1, 1, 1 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 1,
 	},
@@ -89,7 +89,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YUV420,
 		.vdownsampling = { 1, 2, 2 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 1,
 	},
@@ -97,7 +97,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YVU420,
 		.vdownsampling = { 1, 2, 2 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 1,
 	},
@@ -105,7 +105,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV12,
 		.vdownsampling = { 1, 2 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 1,
 	},
@@ -113,7 +113,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV21,
 		.vdownsampling = { 1, 2 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 1,
 	},
@@ -121,7 +121,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV16,
 		.vdownsampling = { 1, 1 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 1,
 	},
@@ -129,7 +129,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV61,
 		.vdownsampling = { 1, 1 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 1,
 	},
@@ -137,7 +137,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV24,
 		.vdownsampling = { 1, 1 },
 		.bit_depth = { 8, 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 1,
 	},
@@ -145,7 +145,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV42,
 		.vdownsampling = { 1, 1 },
 		.bit_depth = { 8, 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 1,
 	},
@@ -184,7 +184,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_GREY,
 		.vdownsampling = { 1 },
 		.bit_depth = { 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 	},
@@ -192,7 +192,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_Y16,
 		.vdownsampling = { 1 },
 		.bit_depth = { 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 	},
@@ -200,7 +200,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_Y16_BE,
 		.vdownsampling = { 1 },
 		.bit_depth = { 16 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 1,
 		.buffers = 1,
 	},
@@ -452,7 +452,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV16M,
 		.vdownsampling = { 1, 1 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 2,
 		.data_offset = { PLANE0_DATA_OFFSET, 0 },
@@ -461,7 +461,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV61M,
 		.vdownsampling = { 1, 1 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 2,
 		.data_offset = { 0, PLANE0_DATA_OFFSET },
@@ -470,7 +470,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YUV420M,
 		.vdownsampling = { 1, 2, 2 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 3,
 	},
@@ -478,7 +478,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YVU420M,
 		.vdownsampling = { 1, 2, 2 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 3,
 	},
@@ -486,7 +486,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV12M,
 		.vdownsampling = { 1, 2 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 2,
 	},
@@ -494,7 +494,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_NV21M,
 		.vdownsampling = { 1, 2 },
 		.bit_depth = { 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 2,
 		.buffers = 2,
 	},
@@ -502,7 +502,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YUV422M,
 		.vdownsampling = { 1, 1, 1 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 3,
 	},
@@ -510,7 +510,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YVU422M,
 		.vdownsampling = { 1, 1, 1 },
 		.bit_depth = { 8, 4, 4 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 3,
 	},
@@ -518,7 +518,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YUV444M,
 		.vdownsampling = { 1, 1, 1 },
 		.bit_depth = { 8, 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 3,
 	},
@@ -526,7 +526,7 @@ struct vivid_fmt vivid_formats[] = {
 		.fourcc   = V4L2_PIX_FMT_YVU444M,
 		.vdownsampling = { 1, 1, 1 },
 		.bit_depth = { 8, 8, 8 },
-		.is_yuv   = true,
+		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
 		.planes   = 3,
 		.buffers = 3,
 	},
diff --git a/include/media/v4l2-tpg.h b/include/media/v4l2-tpg.h
index 329bebfa930c..13ea42bb9530 100644
--- a/include/media/v4l2-tpg.h
+++ b/include/media/v4l2-tpg.h
@@ -87,6 +87,11 @@ enum tpg_move_mode {
 	TPG_MOVE_POS_FAST,
 };
 
+enum tgp_color_representation {
+	TGP_COLOR_REPRESENTATION_RGB,
+	TGP_COLOR_REPRESENTATION_YUV,
+};
+
 extern const char * const tpg_aspect_strings[];
 
 #define TPG_MAX_PLANES 3
@@ -119,7 +124,7 @@ struct tpg_data {
 	u8				saturation;
 	s16				hue;
 	u32				fourcc;
-	bool				is_yuv;
+	enum tgp_color_representation	color_representation;
 	u32				colorspace;
 	u32				xfer_func;
 	u32				ycbcr_enc;
-- 
2.8.1

[toc] | [prev] | [next] | [standalone]

#1444493 — Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation

On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
> Replace is_yuv with color_representation. Which can be used by HSV
> formats.
> 
> This change should ease the review of the following patches.

It's a bit of a mouthful. How about calling this color_enc and TPG_COLOR_ENC_?
(i.e. color encoding).

I would also like to have a TPG_COLOR_ENC_LUMA for the greyscale formats.
This patch is a good opportunity to add that.

Regards,

	Hans

> 
> Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
> ---
>  drivers/media/common/v4l2-tpg/v4l2-tpg-core.c   | 44 ++++++++++++++-------
>  drivers/media/platform/vivid/vivid-core.h       |  2 +-
>  drivers/media/platform/vivid/vivid-vid-common.c | 52 ++++++++++++-------------
>  include/media/v4l2-tpg.h                        |  7 +++-
>  4 files changed, 63 insertions(+), 42 deletions(-)
> 
> diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> index cf1dadd0be9e..acf0e6854832 100644
> --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c
> @@ -237,13 +237,13 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  	case V4L2_PIX_FMT_GREY:
>  	case V4L2_PIX_FMT_Y16:
>  	case V4L2_PIX_FMT_Y16_BE:
> -		tpg->is_yuv = false;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_RGB;
>  		break;
>  	case V4L2_PIX_FMT_YUV444:
>  	case V4L2_PIX_FMT_YUV555:
>  	case V4L2_PIX_FMT_YUV565:
>  	case V4L2_PIX_FMT_YUV32:
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_YUV420M:
>  	case V4L2_PIX_FMT_YVU420M:
> @@ -256,7 +256,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->hdownsampling[1] = 2;
>  		tpg->hdownsampling[2] = 2;
>  		tpg->planes = 3;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_YUV422M:
>  	case V4L2_PIX_FMT_YVU422M:
> @@ -268,7 +268,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->hdownsampling[1] = 2;
>  		tpg->hdownsampling[2] = 2;
>  		tpg->planes = 3;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_NV16M:
>  	case V4L2_PIX_FMT_NV61M:
> @@ -280,7 +280,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->hdownsampling[1] = 1;
>  		tpg->hmask[1] = ~1;
>  		tpg->planes = 2;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_NV12M:
>  	case V4L2_PIX_FMT_NV21M:
> @@ -292,7 +292,7 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->hdownsampling[1] = 1;
>  		tpg->hmask[1] = ~1;
>  		tpg->planes = 2;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_YUV444M:
>  	case V4L2_PIX_FMT_YVU444M:
> @@ -302,21 +302,21 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
>  		tpg->vdownsampling[2] = 1;
>  		tpg->hdownsampling[1] = 1;
>  		tpg->hdownsampling[2] = 1;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_NV24:
>  	case V4L2_PIX_FMT_NV42:
>  		tpg->vdownsampling[1] = 1;
>  		tpg->hdownsampling[1] = 1;
>  		tpg->planes = 2;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	case V4L2_PIX_FMT_YUYV:
>  	case V4L2_PIX_FMT_UYVY:
>  	case V4L2_PIX_FMT_YVYU:
>  	case V4L2_PIX_FMT_VYUY:
>  		tpg->hmask[0] = ~1;
> -		tpg->is_yuv = true;
> +		tpg->color_representation = TGP_COLOR_REPRESENTATION_YUV;
>  		break;
>  	default:
>  		return false;
> @@ -820,7 +820,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
>  
>  		cb = (128 << 4) + (tmp_cb * tpg->contrast * tpg->saturation) / (128 * 128);
>  		cr = (128 << 4) + (tmp_cr * tpg->contrast * tpg->saturation) / (128 * 128);
> -		if (tpg->is_yuv) {
> +		if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
>  			tpg->colors[k][0] = clamp(y >> 4, 1, 254);
>  			tpg->colors[k][1] = clamp(cb >> 4, 1, 254);
>  			tpg->colors[k][2] = clamp(cr >> 4, 1, 254);
> @@ -829,7 +829,7 @@ static void precalculate_color(struct tpg_data *tpg, int k)
>  		ycbcr_to_color(tpg, y, cb, cr, &r, &g, &b);
>  	}
>  
> -	if (tpg->is_yuv) {
> +	if (tpg->color_representation == TGP_COLOR_REPRESENTATION_YUV) {
>  		/* Convert to YCbCr */
>  		int y, cb, cr;
>  
> @@ -1842,7 +1842,9 @@ static void tpg_recalc(struct tpg_data *tpg)
>  
>  		if (tpg->quantization == V4L2_QUANTIZATION_DEFAULT)
>  			tpg->real_quantization =
> -				V4L2_MAP_QUANTIZATION_DEFAULT(!tpg->is_yuv,
> +				V4L2_MAP_QUANTIZATION_DEFAULT(
> +					tpg->color_representation ==
> +						TGP_COLOR_REPRESENTATION_RGB,
>  					tpg->colorspace, tpg->real_ycbcr_enc);
>  
>  		tpg_precalculate_colors(tpg);
> @@ -1889,11 +1891,25 @@ static int tpg_pattern_avg(const struct tpg_data *tpg,
>  	return -1;
>  }
>  
> +static const char *tpg_color_representation_str(enum tgp_color_representation
> +						 color_representation)
> +{
> +	switch (color_representation) {
> +
> +	case TGP_COLOR_REPRESENTATION_YUV:
> +		return "YCbCr";
> +	case TGP_COLOR_REPRESENTATION_RGB:
> +	default:
> +		return "RGB";
> +
> +	}
> +}
> +
>  void tpg_log_status(struct tpg_data *tpg)
>  {
>  	pr_info("tpg source WxH: %ux%u (%s)\n",
> -			tpg->src_width, tpg->src_height,
> -			tpg->is_yuv ? "YCbCr" : "RGB");
> +		tpg->src_width, tpg->src_height,
> +		tpg_color_representation_str(tpg->color_representation));
>  	pr_info("tpg field: %u\n", tpg->field);
>  	pr_info("tpg crop: %ux%u@%dx%d\n", tpg->crop.width, tpg->crop.height,
>  			tpg->crop.left, tpg->crop.top);
> diff --git a/drivers/media/platform/vivid/vivid-core.h b/drivers/media/platform/vivid/vivid-core.h
> index a7daa40d0a49..191ba679ad65 100644
> --- a/drivers/media/platform/vivid/vivid-core.h
> +++ b/drivers/media/platform/vivid/vivid-core.h
> @@ -80,7 +80,7 @@ extern unsigned vivid_debug;
>  
>  struct vivid_fmt {
>  	u32	fourcc;          /* v4l2 format id */
> -	bool	is_yuv;
> +	enum tgp_color_representation color_representation;
>  	bool	can_do_overlay;
>  	u8	vdownsampling[TPG_MAX_PLANES];
>  	u32	alpha_mask;
> diff --git a/drivers/media/platform/vivid/vivid-vid-common.c b/drivers/media/platform/vivid/vivid-vid-common.c
> index fcda3ae4e6b0..314799111cf7 100644
> --- a/drivers/media/platform/vivid/vivid-vid-common.c
> +++ b/drivers/media/platform/vivid/vivid-vid-common.c
> @@ -48,7 +48,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YUYV,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  		.data_offset = { PLANE0_DATA_OFFSET },
> @@ -57,7 +57,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_UYVY,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  	},
> @@ -65,7 +65,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YVYU,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  	},
> @@ -73,7 +73,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_VYUY,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  	},
> @@ -81,7 +81,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YUV422P,
>  		.vdownsampling = { 1, 1, 1 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 1,
>  	},
> @@ -89,7 +89,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YUV420,
>  		.vdownsampling = { 1, 2, 2 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 1,
>  	},
> @@ -97,7 +97,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YVU420,
>  		.vdownsampling = { 1, 2, 2 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 1,
>  	},
> @@ -105,7 +105,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV12,
>  		.vdownsampling = { 1, 2 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 1,
>  	},
> @@ -113,7 +113,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV21,
>  		.vdownsampling = { 1, 2 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 1,
>  	},
> @@ -121,7 +121,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV16,
>  		.vdownsampling = { 1, 1 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 1,
>  	},
> @@ -129,7 +129,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV61,
>  		.vdownsampling = { 1, 1 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 1,
>  	},
> @@ -137,7 +137,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV24,
>  		.vdownsampling = { 1, 1 },
>  		.bit_depth = { 8, 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 1,
>  	},
> @@ -145,7 +145,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV42,
>  		.vdownsampling = { 1, 1 },
>  		.bit_depth = { 8, 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 1,
>  	},
> @@ -184,7 +184,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_GREY,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  	},
> @@ -192,7 +192,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_Y16,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  	},
> @@ -200,7 +200,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_Y16_BE,
>  		.vdownsampling = { 1 },
>  		.bit_depth = { 16 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 1,
>  		.buffers = 1,
>  	},
> @@ -452,7 +452,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV16M,
>  		.vdownsampling = { 1, 1 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 2,
>  		.data_offset = { PLANE0_DATA_OFFSET, 0 },
> @@ -461,7 +461,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV61M,
>  		.vdownsampling = { 1, 1 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 2,
>  		.data_offset = { 0, PLANE0_DATA_OFFSET },
> @@ -470,7 +470,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YUV420M,
>  		.vdownsampling = { 1, 2, 2 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 3,
>  	},
> @@ -478,7 +478,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YVU420M,
>  		.vdownsampling = { 1, 2, 2 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 3,
>  	},
> @@ -486,7 +486,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV12M,
>  		.vdownsampling = { 1, 2 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 2,
>  	},
> @@ -494,7 +494,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_NV21M,
>  		.vdownsampling = { 1, 2 },
>  		.bit_depth = { 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 2,
>  		.buffers = 2,
>  	},
> @@ -502,7 +502,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YUV422M,
>  		.vdownsampling = { 1, 1, 1 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 3,
>  	},
> @@ -510,7 +510,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YVU422M,
>  		.vdownsampling = { 1, 1, 1 },
>  		.bit_depth = { 8, 4, 4 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 3,
>  	},
> @@ -518,7 +518,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YUV444M,
>  		.vdownsampling = { 1, 1, 1 },
>  		.bit_depth = { 8, 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 3,
>  	},
> @@ -526,7 +526,7 @@ struct vivid_fmt vivid_formats[] = {
>  		.fourcc   = V4L2_PIX_FMT_YVU444M,
>  		.vdownsampling = { 1, 1, 1 },
>  		.bit_depth = { 8, 8, 8 },
> -		.is_yuv   = true,
> +		.color_representation = TGP_COLOR_REPRESENTATION_YUV,
>  		.planes   = 3,
>  		.buffers = 3,
>  	},
> diff --git a/include/media/v4l2-tpg.h b/include/media/v4l2-tpg.h
> index 329bebfa930c..13ea42bb9530 100644
> --- a/include/media/v4l2-tpg.h
> +++ b/include/media/v4l2-tpg.h
> @@ -87,6 +87,11 @@ enum tpg_move_mode {
>  	TPG_MOVE_POS_FAST,
>  };
>  
> +enum tgp_color_representation {
> +	TGP_COLOR_REPRESENTATION_RGB,
> +	TGP_COLOR_REPRESENTATION_YUV,
> +};
> +
>  extern const char * const tpg_aspect_strings[];
>  
>  #define TPG_MAX_PLANES 3
> @@ -119,7 +124,7 @@ struct tpg_data {
>  	u8				saturation;
>  	s16				hue;
>  	u32				fourcc;
> -	bool				is_yuv;
> +	enum tgp_color_representation	color_representation;
>  	u32				colorspace;
>  	u32				xfer_func;
>  	u32				ycbcr_enc;
> 

[toc] | [prev] | [next] | [standalone]

#1444497 — Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation

On 07/15/2016 07:58 PM, Hans Verkuil wrote:
> On 07/15/2016 06:13 PM, Ricardo Ribalda Delgado wrote:
>> Replace is_yuv with color_representation. Which can be used by HSV
>> formats.
>>
>> This change should ease the review of the following patches.
> 
> It's a bit of a mouthful. How about calling this color_enc and TPG_COLOR_ENC_?
> (i.e. color encoding).
> 
> I would also like to have a TPG_COLOR_ENC_LUMA for the greyscale formats.
> This patch is a good opportunity to add that.

Also note that docs-next is older than the master branch w.r.t. the tpg.
You're missing two is_yuv checks is docs-next that are present in the master.

Also:

>> +static const char *tpg_color_representation_str(enum tgp_color_representation
>> +						 color_representation)
>> +{
>> +	switch (color_representation) {
>> +

Drop empty line.

>> +	case TGP_COLOR_REPRESENTATION_YUV:
>> +		return "YCbCr";
>> +	case TGP_COLOR_REPRESENTATION_RGB:
>> +	default:
>> +		return "RGB";
>> +
>> +	}
>> +}

Regards,

	Hans

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web