[Cin] xvYCC

[Andrew Randrianasulu]

вт, 3 сент. 2024 г., 22:13 Andrew Randrianasulu <randrianasulu at gmail.com>:

> 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 ====
>


interesting, here is sample where mediainfo shows xvycc:

https://forum.videohelp.com/attachments/31711-1431757037/C0126.MP4

found via ffmpeg bugtracker referencing our bugtracker ;)

https://trac.ffmpeg.org/ticket/6793

one idea is to use videoscope to see if data goes above 235-240?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240904/09400bfe/attachment.htm>