[FFmpeg-user] datascope 16-bit

[Michael Koch]

Am 22.11.2022 um 02:15 schrieb Jim DeLaHunt:
> On 2022-11-20 00:15, Michael Koch wrote:
>
>> Am 20.11.2022 um 02:39 schrieb list+ffmpeg-user at jdlh.com:
>>>
>>> On 2022-11-19 07:34, Michael Koch wrote:
>>>> Am 03.11.2022 um 10:10 schrieb Paul B Mahol:
>>>>>
>>>>> Some things in sea of myriad others:
>>>>> [...]
>>>>> Why you claim that datascope does not support >8 bit formats where in
>>>>> fact it does support it?
>>>>
>>>> In some cases datascope works with 16-bit data, but not in all cases.
>>>> Here is an example where it doesn't work:
>>>>
>>>> ffmpeg -f lavfi -i color=black:s=32x32,format=gray10le -lavfi 
>>>> geq=lum='X+32*Y',format=gray10le -frames 1 -y test.png
>>>>
>>>> ffmpeg -i test.png -vf 
>>>> format=rgb48,showinfo,datascope=s=1280x1152:mode=color2:format=hex 
>>>> -y out.png
>>>>
>>> Perhaps clarify what you observe as "doesn't work", and what 
>>> behaviour you expect?
>>>
>>> Both those commands run for me without error, and I can view both 
>>> test.png and out.png without problem. out.png has a cascade of 32 
>>> 2-digit hex numbers on the left half, and solid black on the right 
>>> half. The hex numbers run from 00 to 7F, in white on a black to grey 
>>> gradient background, and from 80 to FF, in black on a grey to white 
>>> background.
>>
>> I would expect 4-digit hex numbers, because the rgb48 pixel format is 
>> 16-bit per channel.
>> For example, it works fine if "rgb48" is replaced by "gray16".
>
> The phrase "works fine" appeals to some notion of what is "correct" 
> behaviour. It seems that you have your own idea of "correct" behaviour 
> for this filter. But it seems more helpful for communication on this 
> list to use FFmpeg's idea of "correct" behaviour. And the best source 
> we have for FFmpeg's idea of "correct" is the filter documentation 
> <https://ffmpeg.org/ffmpeg-all.html#datascope>: "Video data analysis 
> filter. This filter shows hexadecimal pixel values of part of video."
>
> I think the description in the documentation is incomplete and 
> unclear. I wish FFmpeg had a better description. But the actual 
> behaviour does not conflict with this incomplete description. The 
> description does not promise that the datascope filter shows the 
> full-precision, untruncated pixel values. It might be (I did not 
> check) that the 8-bit values which datascope displays for an rgb48 
> input image are the correct upper 8 bits of 16-bit pixel values.
>
> So, you said, "In some cases datascope works with 16-bit data, but not 
> in all cases."  If you had instead said, "In some cases datascope 
> gives useful results with 16-bit data, but not in all cases", then I 
> would be completely with you. It is clear that truncated 8 bit values 
> for an rbg48 input are not as helpful as full-precision, untruncated 
> 16-bit pixel values.
>
> But the sad reality is the FFmpeg only does not always document its 
> intended behaviour clearly, and does not seem to have a goal of always 
> providing the most helpful behaviour. The culture here understands 
> "doesn't support" or "doesn't work" to mean, "ffmpeg terminates 
> prematurely with an error" or "ffmpeg fails to generate output". If 
> you use those phrases when your objection is actually, "runs to 
> completion and generates output, but output is not as helpful as it 
> could be", then your message gets diluted by misunderstanding.

Sorry for describing the issue not clear enough.
In ticket #10057 it should be clear.

Michael