Quote:
Originally Posted by TheSkiller
Thanks natt, I have wondered why RGB<->YV24 conversions were not lossless color wise using chromaresample=point - now I know why.
However, I'm not sure though and can't test it now but if memory serves me right there also was something fishy going on if doing an (interlaced) YV12<->YUY2/YV16 conversion using pointresize, meaning converting back and forth is not lossless as one would expect.
|
But Natt was referring specifically to Y'CbCr conversions (YV12<=>YV24), not RGB<=>Y'CbCr conversions like the OP was referring to.
Y'CbCr <=> RGB conversions are lossy for other reasons beside chroma sampling. Y'CbCr and RGB are non overlapping color models. You can have out of range gamut even with Rec1361 wide gamut RGB transfer function. Also there are rounding errors - worse when the calculations are done in 8-bit. So even if you disregard chroma up/downscaling algorithms there are other reasons for loss
In practical terms, many programs use RGB/A internally, but very few use Y'CbCr 4:2:0 , and even fewer Y'CbCr 4:4:4. So it would benefit many people to find optimal way with minimal losses for Y'CbCr <=> RGB conversions. Right now you choose trade offs between chroma blurring vs aliasing and "blocky" color edges.