Re: [Cellar] Colour Format proposal

On Tue, Feb 16, 2016 at 11:14 AM, Dave Rice <[email protected]> wrote:

>
> On Feb 16, 2016, at 2:01 PM, Frank Galligan <[email protected]>
> wrote:
>
>
>
> On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice <[email protected]> wrote:
>
>> Hi,
>>
>>
>> Element Name: Colour
>> Level:        4
>> ID:           [55][B0]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         m
>> Description:  Settings describing the colour format.
>>
>>
>> Element Name: Matrix
>>
>>
>> To align better with ISO/IEC 23001-8, could this be labelled as
>> MatrixCoefficients?
>>
> Done
>
>
>>
>> Level:        5
>> ID:           [55][B1]
>> Mandatory:    -
>> Multiple:     -
>> Default:      2
>> Type:         u
>> Description:  ColourMatrix of the video. See ISO/IEC 23001-8 for more
>>              information on enumerations. (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)
>>
>>
>> Suggested description edit:
>> The Matrix Coefficients of the video used to derive luma and chroma
>> values from reg, green, and blue color primaries. For clarity, the value
>> and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC
>> 23001-8:2013/DCOR1. (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)
>>
> Done
>
>>
>> Question:
>> Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix
>> coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as RGB".
>> Should value 0 = RGB?
>>
> I changed it to GBR to match 23001-8.
>
>
>> Add footnote:
>> [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media
>> description code points", 2013, <
>> http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-8_2013.zip
>> >.
>>
>> Element Name: BitsPerChannel
>> Level:        5
>> ID:           [55][B2]
>> Mandatory:    -
>> Multiple:     -
>> Default:      0
>> Type:         u
>> Description:  Number of decoded bits per channel. This number may be less
>> for
>>              specific channels depending on the Matrix and
>> ChromaSubsampling. A
>>              value of 0 is unspecified.
>>
>>
>> It may be fine, but I don't understand "This number may be less for
>> specific channels depending on the Matrix and ChromaSubsampling." Is the
>> value is less for specific channels, then it seems as if the value would
>> different among channels, but only one BitsPerChannel is stored for a
>> multi-channel video.
>>
> So we could have separate bits per channel, but then we would have to
> define rgb and yuv. Most people know what this is. Basically the
> information needed is, will the decoded video be 8 bits, 10 bits, 12 bits,
> 16 bits, ... Maybe I was just trying to be a little too pedantic. I'm fine
> with removing this sentence.
>
>
> +1 for removing it.
>
Done


>
> if any of the ChromaSubsampling elements are set then that implies that
> one or more channels will have a different value.
>
>
> Ah, I had been presuming that you meant bits per channel of a channel's
> sample, rather than the total of the bits per channel (all samples/pixels
> of a frame).
>
> So how about we just remove this sentence?
>
>
>> I suggest changing the last line to: A value of 0 indicates that the
>> BitsPerChannel is unspecified.
>>
> Done
>
>>
>> Element Name: ChromaSubsamplingHorz
>> Level:        5
>> ID:           [55][B3]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         u
>> Description:  The amount of chrominance pixels to remove for every
>> chrominance
>>              pixel not removed horizontally.
>>
>>
>> For these subsampling elements, we may need a statement to say when they
>> should be used. For instance in QuickTime's TN2162
>> https://developer.apple.com/library/mac/technotes/tn2162/_index.html it
>> mandates the use of many values to better describe uncompressed video. When
>> would these chroma subsampling elements be suggested?
>>
> I'm not really sure I follow. If any of the Cb or Cr channels are down
> sized before encoding, then these elements should be set accordingly.
>
>
> I mean that this field is defined as being optional, but there's no
> indication to say when it should or when it shouldn't be used. This
> probably applies to most of these fields (and much of the matroska spec).
>
Ahh, OK. Yeah I have always been under the impression that you shouldn't be
using these elements unless you know what you are doing. Again as you said
that pertains to a lot of the elements in the Matroska spec (as well as
other specs).

We could always expand upon these further in other documents/guides, but
for the spec I just want to accurately represent information that will be
used.

>
> I also suggest including an example; such as "Example: For video with
>> 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3.
>>
> I added "Example: For video with 4:2:0 chroma subsampling the
> ChromaSubsamplingHorz should be set to 1." As pretty much most video is
> 4:4:4 or 4:2:0 nowadays.
>
>
>> Element Name: ChromaSubsamplingVert
>> Level:        5
>> ID:           [55][B4]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         u
>> Description:  The amount of chrominance pixels to remove for every
>> chrominance
>>              pixel not removed vertically.
>>
>> Element Name: CbSubsamplingHorz
>> Level:        5
>> ID:           [55][B5]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         u
>> Description:  The amount of Cb chrominance pixels to remove for every Cb
>>              chrominance pixel not removed horizontally. This is additive
>> with
>>              ChromaSubsamplingHorz.
>>
>>
>> I'm confused about the relationship between CbSubsamplingHorz
>> and ChromaSubsamplingHorz.
>>
> These elements are only defined because I was trying to handle 4:2:1.
> Basically this is an old format where the Cr channel is half the size of
> the Y channel, and the Cb channel is half the size of the Cr channel. The
> Cb channel is a quarter the size of the Y channel.
>
> The CbSubsampling* elements were a late edition, right before I sent my
> previous email. At first I didn't have these elements and had text that
> 4:2:1 was not supported.
>
>
> Right. Sorry I wrote my comments before considering 4:2:1, since the
> fields are quite customized for situations like 4:2:1, perhaps it should be
> referenced by name as an example.
>
> How about I change the CbSubsamplingHorz element text too: "The amount of
> pixels to remove in the Cr and Cb channels for every pixel not removed
> horizontally." And the CbSubsamplingHorz too: "The amount of pixels to
> remove in the Cb channel for every pixel not removed horizontally. This is
> additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma
> subsampling the ChromaSubsamplingHorz should be set to 1 and
> CbSubsamplingHorz should be set to 1." Does this help the confusion?
>
>
> +1
>
> Element Name: CbSubsamplingVert
>> Level:        5
>> ID:           [55][B6]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         u
>> Description:  The amount of Cb chrominance pixels to remove for every Cb
>>              chrominance pixel not removed vertically. This is additive
>> with
>>              ChromaSubsamplingVert.
>>
>>
>> Element Name: ChromaSitingHorz
>> Level:        5
>> ID:           [55][B7]
>> Mandatory:    -
>> Multiple:     -
>> Default:      0
>> Type:         u
>> Description:  How Chroma is subsampled horizontally. (0: Unspecified, 1:
>> Left
>>              collocated , 2: Half)
>>
>> Element Name: ChromaSitingVert
>> Level:        5
>> ID:           [55][B8]
>> Mandatory:    -
>> Multiple:     -
>> Default:      0
>> Type:         u
>> Description:  How Chroma is subsampled vertically. (0: Unspecified, 1: Top
>>              collocated , 2: Half)
>>
>>
>> Element Name: Range
>> Level:        5
>> ID:           [55][B9]
>> Mandatory:    -
>> Multiple:     -
>> Default:      0
>> Type:         u
>> Description:  Clipping of the color ranges. (0: Unspecified, 1:
>> Broadcast range,
>>              2: Full range (no clipping), 3: Defined by
>>              Matrix/TransferFunction)
>>
>>
>> Element Name: TransferFunction
>>
>>
>> To align with ISO/IEC 23001-8, could we use TransferCharacteristics?
>>
> Done.
>
>>
>> Level:        5
>> ID:           [55][BA]
>> Mandatory:    -
>> Multiple:     -
>> Default:      2
>> Type:         u
>> Description:  Transfer Function. See ISO/IEC 23001-8 for more information
>> on
>>              enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,
>>              3: Reserved, 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))
>>
>>
>> Comment:
>> The table in ISO/IEC 23001-8 for transfer characteristics does not
>> include values or meaning for 16, 17 and 18 as above. Are these values from
>> ffmpeg's list?
>>
> 16 and 17 is an artifact form the FFmpeg list, but also form looking at
> FFmpeg CL's I think they are defined in an h265 spec. 18 is a proposed
> value for HLG.
>
>
>> Suggested description edit:
>> The transfer characteristics of the video. For clarity, the value and
>> meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC
>> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3:
>> Reserved, 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)
>>
> Done.
>
>
>>
>> Element Name: Primaries
>> Level:        5
>> Mandatory:    -
>> Multiple:     -
>> ID:           [55][BB]
>> Default:      2
>> Type:         u
>> Description:  Values that can be represented in the CIE 1931 colour
>> space. See
>>              ISO/IEC 23001-8 for more information on enumerations.
>>              (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved,
>>              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)
>>
>>
>> Suggested description edit:
>> The colour primaries of the video. For clarity, the value and meanings
>> for TransferCharacteristics are adopted from Table 2 of ISO/IEC
>> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3:
>> Reserved, 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)
>>
> Done.
>
>>
>> Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22
>> phosphors. Any reason to exclude this?
>>
> Added.
>
>
>>
>> Element Name: MaxCLL
>> Level:        5
>> ID:           [55][BC]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         u
>> Description:  Maximum brightness of a single pixel in candelas per square
>>              meter (cd/m²).
>>
>>
>> Suggested:
>> Maximum brightness of a single pixel (Maximum Content Light Level) in
>> candelas per square meter (cd/m²).
>>
> Done
>
>
>>
>> Element Name: MaxFALL
>> Level:        5
>> ID:           [55][BD]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         u
>> Description:  Maximum brightness of a single full frame in candelas per
>> square
>>              meter (cd/m²).
>>
>>
>> Suggested:
>> Maximum brightness of a single full frame (Maximum Frame-Average Light
>> Level) in candelas per square meter (cd/m²).
>>
> Done
>
>
>>
>> Element Name: MasteringMetadata
>> Level:        5
>> ID:           [55][D0]
>> Mandatory:    -
>> Multiple:     -
>> Default:      -
>> Type:         m
>> Description:  SMPTE 2086 mastering data.
>>
>>
>> Element Name: PrimaryRChromaticityX
>> Level:        6
>> ID:           [55][D1]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>>
>>
>> I think "0.0-1.0" is preferred for float range expressions.
>>
>
> Sorry there's an open discussion elsewhere on Cellar about expressing
> float ranges as hexadecimal floating-point literals, so this may be changed
> later, but the meaning should still be the same.
>
No problem. I just had it that way for brevity, much like a lot of my other
descriptions. I don't want to add to much text to a cell of the Matroska
spec table. :)


> Done
>
>
>>
>> Default:      -
>> Type:         f
>> Description:  Red X chromaticity coordinate as defined by CIE 1931.
>>
>>
>> Element Name: PrimaryRChromaticityY
>> Level:        6
>> ID:           [55][D2]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> Type:         f
>> Description:  Red Y chromaticity coordinate as defined by CIE 1931.
>>
>>
>> Element Name: PrimaryGChromaticityX
>> Level:        6
>> ID:           [55][D3]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> f
>> Description:  Green X chromaticity coordinate as defined by CIE 1931.
>>
>>
>> Element Name: PrimaryGChromaticityY
>> Level:        6
>> ID:           [55][D4]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> Type:         f
>> Description:  Green Y chromaticity coordinate as defined by CIE 1931.
>>
>>
>> Element Name: PrimaryBChromaticityX
>> Level:        6
>> ID:           [55][D5]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> f
>> Description:  Blue X chromaticity coordinate as defined by CIE 1931.
>>
>>
>> Element Name: PrimaryBChromaticityY
>> Level:        6
>> ID:           [55][D6]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> Type:         f
>> Description:  Blue Y chromaticity coordinate as defined by CIE 1931.
>>
>>
>> Element Name: WhitePointChromaticityX
>> Level:        6
>> ID:           [55][D7]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> Type:         f
>> Description:  White point X chromaticity coordinate as defined by CIE
>> 1931.
>>
>>
>> Element Name: WhitePointChromaticityY
>> Level:        6
>> ID:           [55][D8]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 1
>> Default:      -
>> Type:         f
>> Description:  White point Y chromaticity coordinate as defined by CIE
>> 1931.
>>
>>
>> Element Name: LuminanceMax
>> Level:        6
>> ID:           [55][D9]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 9999.99
>> Default:      -
>> Type:         f
>> Description:  Maximum luminance. Shall be represented in candelas per
>> square
>>              meter (cd/m²).
>>
>>
>> Element Name: LuminanceMin
>> Level:        6
>> ID:           [55][DA]
>> Mandatory:    -
>> Multiple:     -
>> Range:        0 <= f <= 999.9999
>> Default:      -
>> Type:         f
>> Description:  Minimum luminance. Shall be represented in candelas per
>> square
>>              meter (cd/m²).
>>
>>
>>
>>
>> I removed ChromaSubsampling and added ChromaSubsamplingHorz,
>> ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert.
>>
>> This is how I think the elements should be written for the different
>> subsampling types:
>> 1: 4:4:4
>>     - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as
>> there should be no chroma subsampling.
>>
>> 2: 4:4:0
>>   - ChromaSubsamplingHorz :not set
>>   - ChromaSubsamplingVert :1
>>
>> 3: 4:2:2
>>   - ChromaSubsamplingHorz :1
>>   - ChromaSubsamplingVert :not set
>>
>> 4: 4:2:1
>>   - ChromaSubsamplingHorz :1
>>   - ChromaSubsamplingVert :not set
>>   - CbSubsamplingHorz :1
>>   - CbSubsamplingVert :not set
>>   - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't
>> care about handling formats where the Cr and Cb channels are different
>> sizes.
>>
>>
>> I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz
>> though perhaps we need a narrative section to expand on this with the
>> examples you have here.
>>
>> 5: 4:2:0
>>   - ChromaSubsamplingHorz :1
>>   - ChromaSubsamplingVert :1
>>
>> 6: 4:1:1
>>   - ChromaSubsamplingHorz :3
>>   - ChromaSubsamplingVert :not set
>>
>> 7: 4:1:0
>>   - ChromaSubsamplingHorz :3
>>   - ChromaSubsamplingVert :1
>>
>> 8: 3:1:1
>>   - ChromaSubsamplingHorz :2
>>   - ChromaSubsamplingVert :not set
>>   - I'm assuming the luma subsampling can be handled by PixelWidth, and
>> DisaplyWidth.
>>
>> Jerome's vertical subsampling of 4
>>   - ChromaSubsamplingHorz :not set
>>   - ChromaSubsamplingVert :3
>>
>>
>>
>> The other issue I want to bring up is the value of "18: ARIB STD-B67
>> (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use
>> this value sooner than Matroska v4 will be finalized. Should I make this
>> value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17:
>> SMPTE ST 428-1" will be standardized across most documents, like 1-15
>> are. Just not sure if 18 will be HLG.
>>
>>
>> I see a few references to ARIB STD-B67 as 18, such as
>> http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf.
>> Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC
>> 23001-8. Then for values 16, 17, and 18 we could add better descriptions
>> and citations to define it better internally.
>>
> I'm fine with this. I'm just worried about the case where we diverge from
> one of the lists. Would be nice to have one canonical list.
>
>
>> If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as
>> expected) then we could update are description to say all values are
>> defined by ISO/IEC 23001-8.
>>
> Sounds good to me.
>
>
> It's a bit risky. Perhaps for now we should clarify that values 1-15 are
> defined by ISO/IEC 23001-8 and then give customized definitions for 16, 17,
> 18.
>

Following Jerome's comment,  how about this for TransferCharacteristic:
"The transfer characteristics of the video. For clarity, the value and
meanings for TransferCharacteristics 1-15 are adopted from Table 3 of
ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristics 16-17 are adopted from
<265 doc> and 18 is the proposed value of ARIB STD-B67. (0: Reserved, 1:
ITU-R BT.709, 2: Unspecified, 3: Reserved, 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))"

Dave Rice
>
>

_______________________________________________
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