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

[Ricardo Ribalda Delgado]

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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxx>
>> ---
>>  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