Re: [Cellar] Colour Format proposal

Thanks for your detailed proposal.
It is a lot of items, I am not expert in all domains but I have some 
comments:

Le 05/01/2016 22:12, Frank Galligan a écrit :
> Hello all,
>
> I would like to bring up the discussion again about better 
> representing the color format of video. It looks like the discussion 
> was started here [1] on matroska-devel list. I think we need to add 
> some Colour elements so Matroska files can (potentially) more 
> faithfully represent the video source on many devices. Here is a 
> proposal I created to start from:
>
>
> Element Name: Colour
> Level:        4
> ID:           [55][A0]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         m
> Description:  Settings describing the colour format.
>
>
> Element Name: ColourMatrix
> Level:        5
> ID:           [55][A1]
> Mandatory:    ma
> Multiple:     -
> Default:      2
> Type:         u
> Description:  ColourMatrix of the video. (0: IEC 61966-2-1 (sRGB), 1: 
> BT709,
>               2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: 
> SMPTE 170M,
>               7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance,
>               10: BT2020 Constant Luminance)

Name: MatrixCoefficients (or Matrix. You don't use "Colour" with 
"Primaries" element, so I would not use it here too)
See my comment about FFmpeg values at the end of the email.

>
>
> Element Name: BitsPerChannel
> Level:        5
> ID:           [55][A2]
> Mandatory:    ma
> Multiple:     -
> Default:      8
> Type:         u
> Description:  Number of bits per channel. This number may be less for 
> specific
>               channels depending on the ColourFormat and 
> ChromaSubsampling.


BitsPerChannel is misleading, used to be the technical count of bits.
I propose QuantizationBits or ValidBitsPerChannel
Not mandatory, not default (this value is often unknown)

>
>
> Element Name: ChromaSubsampling
> Level:        5
> ID:           [55][A3]
> Mandatory:    ma
> Multiple:     -
> Default:      0
> Type:         u
> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)

FFV1, for example, permits "weird" chroma values, more possibilities.
And the following chroma values were seen at least once in some specs:
4:4:4
4:2:2
4:2:1
4:1:1
4:2:0
4:1:0
3:1:1

So having a list is maybe not the solution.
I like the way it is done in FFV1, except the power of 2 (so 3 can not 
be expressed).
I propose to find a way for describing Chroma subsampling (e.g. 
h_chroma_subsample and v_chroma_subsample; a ratio per plane with any 
number of plane, think to alpha channel with a subsampling).

Or to remove entirely this element, because it is a technical piece of 
information and raw stream must contain it somewhere else (else it is 
not decodable)
(I am aware it is not the case for uncompresse data, but we need the 4CC 
in that case for the order of pixel, so we get chroma subsamping this way)

>
>
> Element Name: ColourRange
> Level:        5
> ID:           [55][A4]
> Mandatory:    ma
> Multiple:     -
> Default:      1
> Type:         u
> Description:  (0: Unspecified, 1: Defined by 
> ColourMatrix/TransferFunction,
>               2: Full range)

I don't understand the 1 value.
in at least AVC and HEVC, range is orthogonal to 
ColourMatrix/TransferFunction.
I propose 0: unspecified 1: Broadcast range 1: Full range
and Default:0

>
>
> Element Name: TransferFunction
> Level:        5
> ID:           [55][A6]
> Mandatory:    ma
> Multiple:     -
> Default:      2
> Type:         u
> Description:  Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: 
> Unspecified,
>               4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M,
>               7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
>               11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,
>               13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
>               15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
>               17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))

See my comment about FFmpeg values at the end of the email.

>
>
> Element Name: Primaries
> Level:        5
> Mandatory:    -
> Multiple:     -
> ID:           [55][A7]
> Default:      2
> Description:  (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R 
> BT.470M,
>                5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,
>                9: ITU-R BT.2020, 10: SMPTE ST 428-1)

See my comment about FFmpeg values at the end of the email.

>
>
> Element Name: MaxCLL
> Level:        5
> ID:           [55][A8]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         u
> Description:  Maximum brightness of a single pixel in candelas per square
>               meter (cd/m²).
>
>
> Element Name: MaxFALL
> Level:        5
> ID:           [55][A9]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         u
> Description:  Maximum brightness of a single full frame in candelas 
> per square
>               meter (cd/m²).
>
>
> Element Name: MasteringMetadata
> Level:        5
> ID:           [55][B0]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         m
> Description:  SMPTE 2086 mastering data.
>
>
> Element Name: PrimaryRChromaticityX
> Level:        6
> ID:           [55][B1]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: PrimaryRChromaticityY
> Level:        6
> ID:           [55][B2]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: PrimaryGChromaticityX
> Level:        6
> ID:           [55][B3]
> Mandatory:    -
> Multiple:     -
> Default:      -
> f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: PrimaryGChromaticityY
> Level:        6
> ID:           [55][B4]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: PrimaryBChromaticityX
> Level:        6
> ID:           [55][B5]
> Mandatory:    -
> Multiple:     -
> Default:      -
> f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: PrimaryBChromaticityY
> Level:        6
> ID:           [55][B6]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: WhitePointChromaticityX
> Level:        6
> ID:           [55][B7]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: WhitePointChromaticityY
> Level:        6
> ID:           [55][B8]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Valid value is in the range 0 <= f <= 1.
>
>
> Element Name: LuminanceMax
> Level:        6
> ID:           [55][B9]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Maximum luminance. Shall be represented in candelas per 
> square
>               meter (cd/m²). Valid value is in the range 0 <= f <= 9999.99
>
>
> Element Name: LuminanceMin
> Level:        6
> ID:           [55][BA]
> Mandatory:    -
> Multiple:     -
> Default:      -
> Type:         f
> Description:  Minimum luminance. Shall be represented in candelas per 
> square
>               meter (cd/m²). Valid value is in the range 0 <= f <= 
> 999.9999


I got requests for having information about "Capture Gamma Equation" (or 
"Tone Curve"), e.g. "same as transfer characteristic", Scene Linear, 
S-Log, Cine-Log, Log-C...
I am not an expert of this domain, but looks like it is sometimes important.
there are also other colour ideas with e.g. EBU Tech 3349.

>
>
>
> I can post a link to a formatted document if that would be easier. For 
> Matrix, Range, and Primaries, I'm pretty much using values that map 
> directly to values defined in FFmpeg.

I don't like the idea to use the source code of a piece of software for 
lists. Too much subjective, may have historical flaws.
Lists from FFmpeg are nearly same as the ones in H.26x, I think I prefer 
we base our list on their list (I don't think there are copyright issues 
with such list) directly. Or that we have a prefix with the origin of 
the list (e.g. ARIB STD-B67, from Japan, is not in ITU/ISO list, a 18 
will be used in the future for something in ITU/ISO)

Jérôme

_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel