вт, 3 сент. 2024 г., 22:13 Andrew Randrianasulu <[email protected]>:
> 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 ==== > this patchwork page indicates that xvycc support was added to vf_colorspace plugin in 2016, so may be it works already, just need x264 profile tune? https://patchwork.ffmpeg.org/project/ffmpeg/patch/[email protected]/
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
