[FFmpeg-user] [Cin] FranceBB's LUT collection

[Mark Filipak]

I had asked:
>> Is it all right to 'talk' about the picture stream? For the various
>> permutations of OETF (in camera), what comes out the decoder? I assume that
>> for BT2020 SMPTE2084 it's HDR10 PQ, and for BT2100 it's either HDR10 PQ or
>> HDR10 HLG. In other words, the decoder just makes pictures but doesn't do
>> color transforms. To the best of your knowledge, is that correct?

On 19/05/2025 01.57, Erik Dobberkau wrote:
> It depends. For 'raw' streams (not meaning the camera .RAW format here),
> one should not assume the stream to carry metadata about the encoding
> characteristics, it's just pixel data. ... I have not yet come across a decoder which would
> automatically apply a color transformation ...

Hmmm... I meant FFmpeg's decoders. If a coded source was HDR10 PQ, for example, will the decoded 
picture stream (processing pipeline, whatever) be HDR10 PQ? I'm assuming it would.

I have a UHD m2ts that FFmpeg identifies "yuv420p10le(tv, bt2020nc/bt2020/smpte2084)". To the best 
of my knowledge that means so-called "yuv420" format, planar pixel matrices, 10 bits-per-primary, 
little-endian bytes, with limited black..white range and -- now I have to guess -- 
colorspace=bt2020nc, primaries=bt2020 (i.e. RGB to YUV formula), transfer=smpte2084 (i.e. HDR using 
PQ transfer function). Is all that correct?

I'm going to assume that's all correct for what follows.

In "bt2020nc", what does "nc" signify?

Why is 'colorspace' there at all? Doesn't 'primaries' together with 'transfer' tell the whole story?

I understand it's important-imperative to linearize to gbrpf32le and strip it down (i.e. convert) to 
SDR in order to prepare the pictures for encoding. To your knowledge, are the various CinGG 
color-LUTs bypassing linearization by going directly from HDR-PQ or -HLG to SDR, for example?

The fish are swimming around in my brain and they're beginning to eat each other.