[Cin] xvYCC

[Andrew Randrianasulu]

https://en.m.wikipedia.org/wiki/XvYCC

there is another interesting standartized hack for wider-gamut color space

====


The BT.709 YCbCr signal has unused code space, a limitation imposed for
broadcasting purposes. In particular only 16-240 is used for the color
Cb/Cr channels out of the 0-255 digital values available for 8 bit data
encoding. xvYCC makes use of this portion of the signal to store extended
gamut color data by using code values 1-15 and 241-254 in the Cb/Cr
channels for gamut-extension.

====

not sure how (if at all) ffmpeg supports this, let alone players under
Linux .....

https://fanrestore.com/thread-1961-post-85235.html#pid85235

some convolved way via avisynth and x264 (windows by default, but
vapoursynth/zscale-enabled ffmpeg exist under linux)


=== copypasta =====

deleted user Wrote: <https://fanrestore.com/post-70888.html#pid70888>Ok for
anyone who's wondering how to encode xvYCC, I might have found out. First,
you need to start out with some color space that has a big gamut to begin
with. Let's say Rec 2020. It doesn't have to be HDR, you can just do a
normal Rec2020 Gamma 2.4. This ensures that your source has all the colors
you want to preserve. So work in and/or render out in Rec2020. If you are
working in After Effects for example, in 32 bit floating point mode, then
your working color space can be Rec709, you just have to set Rec2020 for
the output, since the gamut gets preserved thanks to the ability of the 32
bit floating point data to hold negative values. Otherwise you likely have
to work immediately in Rec2020.

Load your source in AVISynth and perform the following command:
Code:
z_ConvertFormat(colorspace_op="2020:709:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16")
Note that you have to adapt the part before "=>" to your own input. The
above example would be for a YUV Rec2020 Gamma 2.4 file with Limited range.
The reason I put "709" there is because that's the transfer characteristic
for Gamma 2.4. It doesn't look elegant but it works.

Now let's say you're encoding straight from a HDR source, then you'd do:
Code:
z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>709:xvycc:709:l",pixel_type="YUV444P16")
This probably isn't a great idea though because converting straight from
HDR without any tonemapping will lead to clipped highlights.

An alternate approach that would allow for tonemapping:
Code:
z_ConvertFormat(colorspace_op="2020ncl:st2084:2020:l=>rgb:linear:2020:f",pixel_type="RGBPS")
// First convert to linear floating point Rec2020
// Do tonemapping here with whatever method you like. It needs to accept
the "RGBPS" color space, which is a 32 bit floating point planar RGB color
space. I believe the DGHable functions and such accept that.
z_ConvertFormat(colorspace_op="rgb:linear:2020:f=>709:xvycc:709:l",pixel_type="YUV444P16")
// Now finally to xvYCC, while preserving as wide of a gamut as possible

For these commands to work, you need this plugin:
http://avisynth.nl/index.php/Avsresize

Now finally, I did a test loading such a script in VirtualDub and encoding
to x264 with the internal x264 encoder. I loaded that back into AVISynth
and I'm happy to say that the data was preserved. I tested it with some
very saturated scenes.

So now the data gets preserved, but the player still won't know that it's
dealing with xvYCC data. I can't say with 100% certainty that the following
will work, but it does produce the proper metadata in the MediaInfo. Simply
use the following x264 parameters instead of the usual:
Code:
--transfer="iec61966-2-4" --colormatrix="bt709" --colorprim="bt709"

To my knowledge, colorprim and colormatrix stay the same, but the transfer
characteristic is different. When you encode it like this, the resulting
file will show "xvYCC" as the Transfer characteristic. I think that should
do the trick, but it would take someone with a compatible TV to try. I can
definitely see a difference in MPC-HC, however I haven't attempted to
verify that it looks "correct".

If anyone wants a sample encode with 2 frames (one in xvycc and one in
rec709), PM me. It's just 100KB.

Note: This will also work with DCI-P3 as the source for example. The only
requirement really is that z_ConvertFormat supports the source color space
you are feeding into it and you give it the correct info about it.

With that said .... now you have no more excuses for not having wide gamut
colors in your projects. [image: Wink] These files are compatible with
normal Rec709 as far as I know.

==== end of copypaste ====
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240903/f2b11711/attachment.htm>