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


Groups > linux.kernel > #1408068

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format

From Hans Verkuil <hverkuil@xs4all.nl>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format
Date 2016-05-27 15:20 +0200
Message-ID <rDpQd-3Uj-17@gated-at.bofh.it> (permalink)
References <rv8tb-86C-3@gated-at.bofh.it> <rv8tb-86C-1@gated-at.bofh.it> <rDpdw-3qH-17@gated-at.bofh.it> <rDpwS-3xK-47@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 05/27/2016 02:52 PM, Nick Dyer wrote:
> On 27/05/2016 13:38, Hans Verkuil wrote:
>> On 05/04/2016 07:07 PM, Nick Dyer wrote:
>>> +    <refname><constant>V4L2_PIX_FMT_YS16</constant></refname>
>>> +    <refpurpose>Grey-scale image</refpurpose>
>>> +  </refnamediv>
>>> +  <refsect1>
>>> +    <title>Description</title>
>>> +
>>> +    <para>This is a signed grey-scale image with a depth of 16 bits per
>>> +pixel. The most significant byte is stored at higher memory addresses
>>> +(little-endian).</para>
>>
>> I'm not sure this should be described in terms of grey-scale, since negative
>> values make no sense for that. How are these values supposed to be interpreted
>> if you want to display them? -32768 == black and 32767 is white?
> 
> We have written a utility to display this data and it is able to display
> the values mapped to grayscale or color:
> https://github.com/ndyer/heatmap/blob/master/src/display.c#L44
> 
> An example of the output is here:
> https://www.youtube.com/watch?v=Uj4T6fUCySw
> 
> The data is intrinsically signed because that's how the low level touch
> controller treats it. I'm happy to change it to "Signed image" if you think
> that would be better.

A V4L2_PIX_FMT_ definition must specify the format unambiguously. So it is not
enough to just say that the data is a signed 16 bit value, you need to document
exactly how it should be interpreted. Looking at the code it seems that the
signed values are within a certain range and are normalized to 0-max by this line:

ssize_t gray = (data[i] - cfg->min) * max / (cfg->max - cfg->min);

Are the min/max values defined by the hardware? Because in that case this pixel
format has to be a hardware-specific define (e.g. V4L2_PIX_FMT_FOO_S16).

Only if the min/max values are -32768 and 32767 can you really use YS16 (not sure
yet about that name, but that's another issue).

Regards,

	Hans

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format Hans Verkuil <hverkuil@xs4all.nl> - 2016-05-27 14:40 +0200
  Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format Nick Dyer <nick.dyer@itdev.co.uk> - 2016-05-27 15:00 +0200
    Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format Hans Verkuil <hverkuil@xs4all.nl> - 2016-05-27 15:20 +0200
      Re: [PATCH v2 2/8] [media] Add signed 16-bit pixel format Nick Dyer <nick.dyer@itdev.co.uk> - 2016-05-27 15:40 +0200

csiph-web