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

[Hans Verkuil <hverkuil@xs4all.nl>]

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