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-u...@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
_______________________________________________
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
