* [PATCH v2 0/6] Add HSV format
@ 2016-07-15 16:13 Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 1/6] [media] videodev2.h Add HSV formats Ricardo Ribalda Delgado
` (5 more replies)
0 siblings, 6 replies; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v2 1/6] [media] videodev2.h Add HSV formats
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
@ 2016-07-15 16:13 ` Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado
` (4 subsequent siblings)
5 siblings, 0 replies; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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.
Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
---
drivers/media/v4l2-core/v4l2-ioctl.c | 2 ++
include/uapi/linux/videodev2.h | 4 ++++
2 files changed, 6 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c
index 28e5be2c2eef..4b67ad06efb7 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1238,6 +1238,8 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt)
case V4L2_PIX_FMT_TM6000: descr = "A/V + VBI Mux Packet"; break;
case V4L2_PIX_FMT_CIT_YYVYUY: descr = "GSPCA CIT YYVYUY"; break;
case V4L2_PIX_FMT_KONICA420: descr = "GSPCA KONICA420"; break;
+ case V4L2_PIX_FMT_HSV24: descr = "24-bit HSV 8-8-8"; break;
+ case V4L2_PIX_FMT_HSV32: descr = "32-bit XHSV 8-8-8-8"; break;
case V4L2_SDR_FMT_CU8: descr = "Complex U8"; break;
case V4L2_SDR_FMT_CU16LE: descr = "Complex U16LE"; break;
case V4L2_SDR_FMT_CS8: descr = "Complex S8"; break;
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 724f43e69d03..c7fb760386cf 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -580,6 +580,10 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_SRGGB12 v4l2_fourcc('R', 'G', '1', '2') /* 12 RGRG.. GBGB.. */
#define V4L2_PIX_FMT_SBGGR16 v4l2_fourcc('B', 'Y', 'R', '2') /* 16 BGBG.. GRGR.. */
+/* HSV formats */
+#define V4L2_PIX_FMT_HSV24 v4l2_fourcc('H', 'S', 'V', '3')
+#define V4L2_PIX_FMT_HSV32 v4l2_fourcc('H', 'S', 'V', '4')
+
/* compressed formats */
#define V4L2_PIX_FMT_MJPEG v4l2_fourcc('M', 'J', 'P', 'G') /* Motion-JPEG */
#define V4L2_PIX_FMT_JPEG v4l2_fourcc('J', 'P', 'E', 'G') /* JFIF JPEG */
--
2.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 1/6] [media] videodev2.h Add HSV formats Ricardo Ribalda Delgado
@ 2016-07-15 16:13 ` Ricardo Ribalda Delgado
2016-07-15 18:11 ` Laurent Pinchart
2016-07-15 16:13 ` [PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda Ricardo Ribalda Delgado
` (3 subsequent siblings)
5 siblings, 1 reply; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 1/6] [media] videodev2.h Add HSV formats Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado
@ 2016-07-15 16:13 ` Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 4/6] [media] vivid: code refactor for color representation Ricardo Ribalda Delgado
` (2 subsequent siblings)
5 siblings, 0 replies; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v2 4/6] [media] vivid: code refactor for color representation
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
` (2 preceding siblings ...)
2016-07-15 16:13 ` [PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda Ricardo Ribalda Delgado
@ 2016-07-15 16:13 ` Ricardo Ribalda Delgado
2016-07-15 17:58 ` Hans Verkuil
2016-07-15 18:28 ` Hans Verkuil
2016-07-15 16:13 ` [PATCH v2 5/6] [media] vivid: Add support for HSV formats Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 6/6] [media] vivid: Rename variable Ricardo Ribalda Delgado
5 siblings, 2 replies; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v2 5/6] [media] vivid: Add support for HSV formats
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
` (3 preceding siblings ...)
2016-07-15 16:13 ` [PATCH v2 4/6] [media] vivid: code refactor for color representation Ricardo Ribalda Delgado
@ 2016-07-15 16:13 ` Ricardo Ribalda Delgado
2016-07-15 18:29 ` Hans Verkuil
2016-07-15 16:13 ` [PATCH v2 6/6] [media] vivid: Rename variable Ricardo Ribalda Delgado
5 siblings, 1 reply; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* [PATCH v2 6/6] [media] vivid: Rename variable
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
` (4 preceding siblings ...)
2016-07-15 16:13 ` [PATCH v2 5/6] [media] vivid: Add support for HSV formats Ricardo Ribalda Delgado
@ 2016-07-15 16:13 ` Ricardo Ribalda Delgado
5 siblings, 0 replies; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-15 16:13 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
Cc: Ricardo Ribalda Delgado
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation
2016-07-15 16:13 ` [PATCH v2 4/6] [media] vivid: code refactor for color representation Ricardo Ribalda Delgado
@ 2016-07-15 17:58 ` Hans Verkuil
2016-07-15 18:12 ` Hans Verkuil
2016-07-15 18:28 ` Hans Verkuil
1 sibling, 1 reply; 22+ messages in thread
From: Hans Verkuil @ 2016-07-15 17:58 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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;
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-15 16:13 ` [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado
@ 2016-07-15 18:11 ` Laurent Pinchart
2016-07-16 8:19 ` Hans Verkuil
2016-07-16 8:22 ` Ricardo Ribalda Delgado
0 siblings, 2 replies; 22+ messages in thread
From: Laurent Pinchart @ 2016-07-15 18:11 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation
2016-07-15 17:58 ` Hans Verkuil
@ 2016-07-15 18:12 ` Hans Verkuil
0 siblings, 0 replies; 22+ messages in thread
From: Hans Verkuil @ 2016-07-15 18:12 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 4/6] [media] vivid: code refactor for color representation
2016-07-15 16:13 ` [PATCH v2 4/6] [media] vivid: code refactor for color representation Ricardo Ribalda Delgado
2016-07-15 17:58 ` Hans Verkuil
@ 2016-07-15 18:28 ` Hans Verkuil
1 sibling, 0 replies; 22+ messages in thread
From: Hans Verkuil @ 2016-07-15 18:28 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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.
>
> 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
> @@ -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,
This should be != TGP_COLOR_REPRESENTATION_YUV.
Otherwise HSV would map to limited range by default, which is probably wrong.
Regards,
Hans
> tpg->colorspace, tpg->real_ycbcr_enc);
>
> tpg_precalculate_colors(tpg);
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 5/6] [media] vivid: Add support for HSV formats
2016-07-15 16:13 ` [PATCH v2 5/6] [media] vivid: Add support for HSV formats Ricardo Ribalda Delgado
@ 2016-07-15 18:29 ` Hans Verkuil
0 siblings, 0 replies; 22+ messages in thread
From: Hans Verkuil @ 2016-07-15 18:29 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-15 18:11 ` Laurent Pinchart
@ 2016-07-16 8:19 ` Hans Verkuil
2016-07-16 12:38 ` Laurent Pinchart
2016-07-16 8:22 ` Ricardo Ribalda Delgado
1 sibling, 1 reply; 22+ messages in thread
From: Hans Verkuil @ 2016-07-16 8:19 UTC (permalink / raw)
To: Laurent Pinchart, Ricardo Ribalda Delgado
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Sakari Ailus,
Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-15 18:11 ` Laurent Pinchart
2016-07-16 8:19 ` Hans Verkuil
@ 2016-07-16 8:22 ` Ricardo Ribalda Delgado
1 sibling, 0 replies; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-16 8:22 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Hans Verkuil, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, LKML
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 8:19 ` Hans Verkuil
@ 2016-07-16 12:38 ` Laurent Pinchart
2016-07-16 13:59 ` Hans Verkuil
0 siblings, 1 reply; 22+ messages in thread
From: Laurent Pinchart @ 2016-07-16 12:38 UTC (permalink / raw)
To: Hans Verkuil
Cc: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 12:38 ` Laurent Pinchart
@ 2016-07-16 13:59 ` Hans Verkuil
2016-07-16 14:12 ` Laurent Pinchart
0 siblings, 1 reply; 22+ messages in thread
From: Hans Verkuil @ 2016-07-16 13:59 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 13:59 ` Hans Verkuil
@ 2016-07-16 14:12 ` Laurent Pinchart
2016-07-16 14:32 ` Ricardo Ribalda Delgado
2016-07-16 15:19 ` Hans Verkuil
0 siblings, 2 replies; 22+ messages in thread
From: Laurent Pinchart @ 2016-07-16 14:12 UTC (permalink / raw)
To: Hans Verkuil
Cc: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 14:12 ` Laurent Pinchart
@ 2016-07-16 14:32 ` Ricardo Ribalda Delgado
2016-07-16 15:28 ` Hans Verkuil
2016-07-16 15:19 ` Hans Verkuil
1 sibling, 1 reply; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-16 14:32 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Hans Verkuil, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, LKML
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
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 14:12 ` Laurent Pinchart
2016-07-16 14:32 ` Ricardo Ribalda Delgado
@ 2016-07-16 15:19 ` Hans Verkuil
1 sibling, 0 replies; 22+ messages in thread
From: Hans Verkuil @ 2016-07-16 15:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Ricardo Ribalda Delgado, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, linux-kernel
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 14:32 ` Ricardo Ribalda Delgado
@ 2016-07-16 15:28 ` Hans Verkuil
2016-07-16 15:57 ` Ricardo Ribalda Delgado
0 siblings, 1 reply; 22+ messages in thread
From: Hans Verkuil @ 2016-07-16 15:28 UTC (permalink / raw)
To: Ricardo Ribalda Delgado, Laurent Pinchart
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Sakari Ailus,
Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, LKML
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!
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 15:28 ` Hans Verkuil
@ 2016-07-16 15:57 ` Ricardo Ribalda Delgado
2016-07-16 16:14 ` Hans Verkuil
0 siblings, 1 reply; 22+ messages in thread
From: Ricardo Ribalda Delgado @ 2016-07-16 15:57 UTC (permalink / raw)
To: Hans Verkuil
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, LKML
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
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 2/6] [media] Documentation: Add HSV format
2016-07-16 15:57 ` Ricardo Ribalda Delgado
@ 2016-07-16 16:14 ` Hans Verkuil
0 siblings, 0 replies; 22+ messages in thread
From: Hans Verkuil @ 2016-07-16 16:14 UTC (permalink / raw)
To: Ricardo Ribalda Delgado
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Laurent Pinchart,
Sakari Ailus, Antti Palosaari, Guennadi Liakhovetski,
Helen Mae Koike Fornazier, Philipp Zabel, Shuah Khan,
linux-media, LKML
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
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-07-16 16:14 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-15 16:13 [PATCH v2 0/6] Add HSV format Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 1/6] [media] videodev2.h Add HSV formats Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 2/6] [media] Documentation: Add HSV format Ricardo Ribalda Delgado
2016-07-15 18:11 ` Laurent Pinchart
2016-07-16 8:19 ` Hans Verkuil
2016-07-16 12:38 ` Laurent Pinchart
2016-07-16 13:59 ` Hans Verkuil
2016-07-16 14:12 ` Laurent Pinchart
2016-07-16 14:32 ` Ricardo Ribalda Delgado
2016-07-16 15:28 ` Hans Verkuil
2016-07-16 15:57 ` Ricardo Ribalda Delgado
2016-07-16 16:14 ` Hans Verkuil
2016-07-16 15:19 ` Hans Verkuil
2016-07-16 8:22 ` Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 3/6] [media] Documentation: Add Ricardo Ribalda Ricardo Ribalda Delgado
2016-07-15 16:13 ` [PATCH v2 4/6] [media] vivid: code refactor for color representation Ricardo Ribalda Delgado
2016-07-15 17:58 ` Hans Verkuil
2016-07-15 18:12 ` Hans Verkuil
2016-07-15 18:28 ` Hans Verkuil
2016-07-15 16:13 ` [PATCH v2 5/6] [media] vivid: Add support for HSV formats Ricardo Ribalda Delgado
2016-07-15 18:29 ` Hans Verkuil
2016-07-15 16:13 ` [PATCH v2 6/6] [media] vivid: Rename variable Ricardo Ribalda Delgado
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.