xvYCC for x264

[nightstalkerpoet]

Has anyone really worked with the x264 xvYCC color transfer setting? For a specific example - I am unimpressed with HDR on lower end TVs. It tends to leave a very dull picture, which is very disappointing when dropping money on UHD discs. With more UHD discs becoming available as sources, I was wondering if anyone has tried to take, lets use Harry Potter as an example, the 4k UHD, and reencode to a 1080p xvYCC bluray compatible file. That way, we get the color benefits of 10 bit without the somewhat unbalanced HDR implementations.

I ask mostly because everywhere I read says using transfer characteristics in x264 is frequently pointless.

[spoRv]

AFAIK xyYCC on blu-ray (the ones who recognize it) uses 8 bit, but 0-255 levels instead the usual 16-235...

[deleted user]

Definitely doesn't use 10-bit, because to my knowledge there aren't even any mainstream 10 bit h264 decoders.

[nightstalkerpoet]

Even that benefit should show visible difference on a 10 bit display. From what I'm reading, XVYCC is a strange creature not tied to specific bit definitions, but is intended as an 8 bit work around to display all colors visible to the human eye.

[spoRv]

YUV "TV" 16-240 = 225x225x225 = 11390625
xvYCC 0-255 = 256x256x256 = 16777216

[nightstalkerpoet]

https://www.researchgate.net/publication...olor_Space

First time I've found this.

[zoidberg]

Anyone remember the 'Mastered in 4K' Sony Blu rays with the expanded colour space (if you had the right Sony display)?

[nightstalkerpoet]

I actually haven't tried those discs in the correct setup.

Apparently, if you convert 10 bit video to Unclipped sRGB, you can use the standard color conversion matrix used between RGB and YCbCr, and it should map correctly to xvYCC, which can then be piped into x264 (making sure to set 709 primaries and xvycc transfer characteristics).

[deleted user]

I learned today that AVISynth using the z_ConvertFormat plugin is able to convert to and from xvYCC apparently. This would make it possible in theory to convert any older SDR Blu Rays mastered in xvYCC or whatever they called it into, say, Rec2020, to make it possible to view in a more standardized manner. The z_ConvertFormat command can do this apparently, from any color space into any other color space.

Tested conversion of HDR Rec2020 content to Rec709 and also xvYCC, and back to HDR again and then did side by side comparisons including to the original source. Both naturally clipped highlights, but whilst Rec709 lost a bit of color fidelity in highly saturated scenes, the same areas stayed unaffected in the xvYCC version. Neat stuff. Might also be an interesting way of sharing fanres projects that are meant to be accessible to a wide audience - render out of your editing software in Rec2020 (non HDR one, just for the wider colorspace), then use AVISynth to convert that to xvYCC. And you end up with the same result for the most part, except that anyone with an xvYCC capable system actually gets a bit of an extra color depth in areas of high color saturation.

[deleted user]

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. These files are compatible with normal Rec709 as far as I know.