[FFmpeg-devel] xvYCC Conversion to Wide Gamut RGB with FFmpeg

[yellowsblog]

Thomas, thanks for the  response, currently I'm using FFmpeg to do the
decompressing only, via FFmpegSource2 plugin and Avisynth to look at the
YCbCr levels, then 96bit precision 3D LUTS to do the conversion to RGB and
various interpolation methods. This I feel is giving me results that are not
in some way affected such as using Quicktime for the decompress.

With regard to whether a camera shoots xvYCC or not I think it may be an
aside to the main query I'm asking and that is based on the assumption that
there is quite a range of colours that can be generated in the YCbCr to RGB
conversion that fall outside of the sRGB gamut and therefore gamut clipped.
Probably especially true in consumer cameras / usage where a 'Professional'
would calibrate and ensure capture within certain range. I'm looking at it
from a capture as much 8bit data as possible, then break that out into a
gamut that can hold the wider range of colours, then look at gamut mapping /
natural tone mapping algorithms back into an sRGB gamut for web / DVD /
BluRay delivery, or stay wider gamut ie: digital cinema and film print.

When I offered the .MOV file I did mention that "at the very least colours
outside of sRGB gamut". The Gold.MOV I specifically shot badly white
balanced and with cheap gold content as these colours are more likely gamut
clipped. But I have other examples of DSLR video where wider colour range
has been captured, music gigs and inside events with dark interiors and
bright neon lighting. Non of these may be xvYCC but have a captured range
that appear to exceed sRGB gamut. And as you say with certain camera curves
more chance of exceeding sRGB.

To be honest I don't think Canon DSLR's capture xvYCC, that is with regard
to the Cb & Cr channels but certainly luma does. That doesn't mean that
there is not colour information being gamut clipped.

Although it wasn't me who posted about Blackmagic, the info you mention is
useful, Kdenlive a OSS NLE has implemented Blackmagic Intensity support for
capture so I'll pass on the information.



On 1 April 2011 23:32, Thomas Worth <dev at rarevision.com> wrote:

> On Fri, Apr 1, 2011 at 5:19 AM, yellowsblog
> <yellowsblog at blueyonder.co.uk> wrote:
> > My understanding is that any YCbCr source with captured data in range
> > outside 16 - 235/240 and sRGB colour primaries may well be xvYCC or at
> the
> > very least have colour information beyond sRGB gamut, so I can give you a
> > link to a h264AVC .MOV source shot from a Canon HD DSLR and a discussion
> > thread on Doom9:
> >
> > Link to file:
> >
> > http://www.yellowspace.webspace.virginmedia.com/Gold.aMOV
> >
> > Link to Discussion:
> >
> > http://forum.doom9.org/showthread.php?t=159915
> >
> > The thread also discusses yCMS 3D LUT system which has recently had xvYCC
> > support added.
>
> Are you sure Canon DLSRs use xvYCC? I thought this was a Sony thing.
> If you want to check you can download our tool, 5DtoRGB, and convert a
> clip using "none" as the decoding matrix. This will show you raw pixel
> values for Y, Cb, and Cr copied straight from the H.264 file prior to
> being decoded. I don't know if Canon use values outside 16-240 for
> chroma, but it's possible. Some tests with a color chart and jacking
> up the saturation in a Picture Style may help determine this.
>
> Grab it here: http://rarevision.com/5dtorgb/
>
> By the way, the post you made mentioned Blackmagic Design hardware not
> supporting values outside 16-235 / 64-940. This isn't necessarily the
> case. The problem with BMD is their software, specifically in this
> case their Directshow filters. It is the FILTERS that are clamping the
> output to 16-235, NOT the hardware. I have written software with their
> SDK that lets you access the hardware directly, and I can say that the
> hardware will indeed support full range data. This makes sense, since
> timing info must be present and it is usually carried in values under
> or above 16-240. So if you feel like writing your own capture app in
> C++, you can do it. :-)
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>