[Matroska-devel] [Cellar] Colour Format proposal

Dave Rice via Matroska-devel matroska-devel at lists.matroska.org
Tue Feb 16 20:14:59 CET 2016


> On Feb 16, 2016, at 2:01 PM, Frank Galligan <frankgalligan at gmail.com> wrote:
> 
> 
> 
> On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice <dave at dericed.com <mailto:dave at dericed.com>> 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 <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.

> 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 <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).

> 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.

> 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 <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.
Dave Rice

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20160216/31bbd0f6/attachment-0001.html>


More information about the Matroska-devel mailing list