From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751633AbcGPN7S (ORCPT ); Sat, 16 Jul 2016 09:59:18 -0400 Received: from lb1-smtp-cloud6.xs4all.net ([194.109.24.24]:59463 "EHLO lb1-smtp-cloud6.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751448AbcGPN7P (ORCPT ); Sat, 16 Jul 2016 09:59:15 -0400 Subject: Re: [PATCH v2 2/6] [media] Documentation: Add HSV format To: Laurent Pinchart References: <1468599199-5902-1-git-send-email-ricardo.ribalda@gmail.com> <7843924.z0DslKFWcx@avalon> <50772055-a856-0574-d89b-cc6665454252@xs4all.nl> <1704928.3gI88ec2Bn@avalon> 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@vger.kernel.org, linux-kernel@vger.kernel.org From: Hans Verkuil Message-ID: Date: Sat, 16 Jul 2016 15:59:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <1704928.3gI88ec2Bn@avalon> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >>>> --- >>>> >>>> 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