[FFmpeg-user] Does converting to yuv444p by default make sense?

[thljcl]

Carl Lindqvist wrote
> It's quite easy to see that no YCbCr 444 can't be one to one with RGB,
> even when the full values of Y (0-255 instead of 16-235) are used.
> 
> Think of a Y value of 0. Cb and Cr can have 256x256=65536 different
> combination of values, but they all represent the same black color in
> RGB: 0,0,0
> 
> So there MUST be some loss of color information when converting between
> the two.
> _______________________________________________
> ffmpeg-user mailing list

> ffmpeg-user@

> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

What you said sounds reasonable, except that you forgot about one thing: you
cannot simply assign a real number and tried to use the inverse
transformation matrix on YCbCr. The operation is only well-defined for a set
of 16,777,216 input values. As I said before, the YCbCr itself is defined as
an affine map from an absolute color space, not necessarily sRGB, but I
always cite sRGB as an example.
If you want to which numbers are valid for such operation, you have to
transform from sRGB  YCbCr first, after getting the output value; you can
then use the output value as input value and apply the inverse
transformation on it, of course what you got is the original input value
from the first operation, assuming that your calculation is accurate enough
to avoid rounding-off error problem.
The set of valid input values is not define as equal to the set of positive
integers, for your information. I’m using 24-bit color space as an example
in this case. But you can easily see that the argument is still valid for
other bit depths, such as 30 bits. Only if the bit depth is larger, the
number of valid input values also increases accordingly.



--
View this message in context: http://ffmpeg-users.933282.n4.nabble.com/Does-converting-to-yuv444p-by-default-make-sense-tp4660219p4660385.html
Sent from the FFmpeg-users mailing list archive at Nabble.com.