[Cin] Surprizes in YUV->RGB conversion

[Andrew Randrianasulu]

I was using artificial test source from ffmpeg, yuvtestsrc.

It sounds very simple

 ffmpeg -f lavfi -color_range 2 -i yuvtestsrc -color_range 2 -frames 2
/dev/shm/yuv-pc-yuv444.y4m

but here lies dragons, at least when roundtrip to RGB is needed.

This old BBC article explained to me for the first time that YUV as color
space fundamentally bigger than RGB!

https://web.archive.org/web/20200719051405/http://downloads.bbc.co.uk/rd/pubs/reports/1987-22.pdf

By way stuff defined normal calculations can give you negative RGB values!

An normally those are clipped to either min or max allowed channel value.

But result is ...unintuitive, at least for me

Here is online calculator:

 https://kdashg.github.io/misc/colors/from-coeffs.html

if you enter RGB 601, narrow range
Y=16, Cb=100 Cr=100
R=-44.68875 (minus 44!)
G=33.73244
B=-56.4825 (minus 56!)

so, if both negative channels will be clipped to 0 we will have  visually
purely green pixel ?!

This probably explains some STRANGE results I was seeing in compositor and
vectoroscope, because even if timeline set to YUV- for display values
converted to RGB, and scope also works in RGB ?

There was another patent paper from broadcom aimed at fixing this issue

https://patents.google.com/patent/EP1560417A2/en
"System and method for clipping values of pixels in one color space so not
to exceed the limits of a second color space
Abstract
A system and method that detects when pixels from one color space would
exceed the range of a second color space, and restrict the range of the
pixels without distorting their brightness, while preserving their color.
The method may provide the ability to restrict the range of pixels in the
first color space that may ordinarily transform to "illegal" values with
erroneous brightness in the second color space, to a sub-space containing
the entire second color space, while preserving the brightness of the
pixels. The parameters used to define the sub-space may be programmable.
The first color space may be YCrCb and the second color space may be RGB."

=====

so, while in theory this problem is combatable in practice I do not think
we have any out of the box plugin for dealing with this?

So .... back to hunting for relevant test image, may be rgbtestsrc stored
as y4m will do?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240915/35ecafca/attachment.htm>