Re: [Cellar] [Matroska-devel] Colour Format proposal
Frank Galligan <frankgalligan@gmail.com> Thu, 18 February 2016 19:50 UTC
Return-Path: <frankgalligan@gmail.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8191B3466 for <cellar@ietfa.amsl.com>; Thu, 18 Feb 2016 11:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.867
X-Spam-Level: **
X-Spam-Status: No, score=2.867 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSD5XVOItrUm for <cellar@ietfa.amsl.com>; Thu, 18 Feb 2016 11:50:28 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E18F1B345E for <cellar@ietf.org>; Thu, 18 Feb 2016 11:50:28 -0800 (PST)
Received: by mail-ob0-x231.google.com with SMTP id kf7so2402809obb.1 for <cellar@ietf.org>; Thu, 18 Feb 2016 11:50:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=28CIpbtdvWm6zABdT/MDF8T0R9b0B5JpX0qgw8X0C0s=; b=Yral4XEedTjPrTdSxzYSq0uemlkFUfLfqWQnoVRN3roMOu4aCHIFkOVPriXZDJmlVc tzFIzuWx7IO7wpng8P8ZaJUUSthq6bBMqZg/eRYMGUDH6jasO5prSWyljmGOyS+GmuqB fVxrnH0hA12ZCerluAK3OuBpsCLFW5M8Zgm7daGctjEEjh7qCHWvnMypddhuA9/wqILn IQ3dMpuRPrEyVLDcz/hb9diFXru0LqvdLU+gKFwysq49q746lhGzQ7TJxQNOv6vBjaVm c1EpAVCMOFFbNmNyajRuBNELszw0gpi91cn21uhdAJ9ezfKTSqOQmHchN1j39VTmaTE6 X0nw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=28CIpbtdvWm6zABdT/MDF8T0R9b0B5JpX0qgw8X0C0s=; b=ScByYYB4aos/taqWPA33EFCp+IWtUVf32xNZxNaAQw+TYJ0CcuEZlyORfkYDfCZwof EEo3GxAkC/K7QCIgOt+GzuTfxL1DIkRIDdiD5PYTyT3XJgPMGl6/7qaJoa8s/SktggTC iRKEgn+PpQyzuMc7cV8DXwhho7SfQFxcxjcdCN8tbLUlAwHXJkfpiNp0p5Rj8SCL1kE9 l+8kP8CoT8eSWxqoWvbn/NE5Vzpuc0fPj8C8gnXBK3u1/LBbVEAF2Zz1YtY/O7eydq1m 9bb5OaJ/0N9MNyH43XN9GsVXoniLkmPZel0OkSwH/5inKLikPMA+sicf6ZX764ZJfdeo +yoA==
X-Gm-Message-State: AG10YOSBTfC66zn03S2Qiz4IRutVKlMR7cd9a9F6xczwe483nJR9utkeEyFQlKi39wHHp0LTdjVsulO1q3f90g==
MIME-Version: 1.0
X-Received: by 10.202.188.134 with SMTP id m128mr7914495oif.4.1455825027681; Thu, 18 Feb 2016 11:50:27 -0800 (PST)
Received: by 10.202.59.130 with HTTP; Thu, 18 Feb 2016 11:50:27 -0800 (PST)
In-Reply-To: <CAJGH+UtxGnwmYXokmHoBjhuEerLZvs_dTAdqrhVFqDGJa7E+fw@mail.gmail.com>
References: <CAJGH+UuSn8O04HR1=L+b1=ouwgPd=n+xYFQZmTXqs8buZ-Wdrg@mail.gmail.com> <568C3CA0.8040300@mediaarea.net> <CAJGH+UveWG5_ngd+YxSqPOiPkEE7_uM288yJd=F8fPrThU4cRw@mail.gmail.com> <CAOXsMF+VYv5WXek_-vuQO1cgvrhLN7WRDNkHegYaQT0YwkhRbw@mail.gmail.com> <CAJGH+Ush3_X3SPgbGKYr5LcYLQAnO3w1-3MoF9CPeykqsYXhOw@mail.gmail.com> <56B8CD1A.20307@mediaarea.net> <CAJGH+Uv3cEtHG1US2r_4hwcybHcQX+RF0B1SQ9jFJcF2A6=oew@mail.gmail.com> <CAJGH+Uu=LwbHb_JaWmRxHbBWpg2=JVvxbA_aWR+GYeeK3ejYzA@mail.gmail.com> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <CAJGH+UuK562q+qV=BCMS9KRFQh=4NCcyr1gRtJ40fqXfJk3LBg@mail.gmail.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> <CAJGH+UtxGnwmYXokmHoBjhuEerLZvs_dTAdqrhVFqDGJa7E+fw@mail.gmail.com>
Date: Thu, 18 Feb 2016 11:50:27 -0800
Message-ID: <CAJGH+Uv6A1UciiQ1xUkVEFXH_7Mv2WkbowedLoLKDtphhshUMg@mail.gmail.com>
From: Frank Galligan <frankgalligan@gmail.com>
To: Dave Rice <dave@dericed.com>
Content-Type: multipart/alternative; boundary="001a113dcc82a15718052c10ad98"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cellar/hIKLhMdgTMTEwUTeA4ct38h0tmE>
Cc: Jerome Martinez <jerome@mediaarea.net>, Discussion about the current and future development of Matroska <matroska-devel@lists.matroska.org>, cellar@ietf.org
Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 19:50:42 -0000
Here is the current proposal, minus the reference to the 265 doc.
The parent element would be Video [E0].
Element Name: Colour
Level: 4
ID: [55][B0]
Mandatory: -
Multiple: -
Default: -
Type: m
Description: Settings describing the colour format.
Element Name: MatrixCoefficients
Level: 5
ID: [55][B1]
Mandatory: -
Multiple: -
Default: 2
Type: u
Description: 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:GBR, 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)
Element Name: BitsPerChannel
Level: 5
ID: [55][B2]
Mandatory: -
Multiple: -
Default: 0
Type: u
Description: Number of decoded bits per channel. A value of 0 indicates
that
the BitsPerChannel is unspecified.
Element Name: ChromaSubsamplingHorz
Level: 5
ID: [55][B3]
Mandatory: -
Multiple: -
Default: -
Type: u
Description: The amount of pixels to remove in the Cr and Cb channels for
every
pixel not removed horizontally. Example: For video with 4:2:0
chroma subsampling, the ChromaSubsamplingHorz should be set to
1.
Element Name: ChromaSubsamplingVert
Level: 5
ID: [55][B4]
Mandatory: -
Multiple: -
Default: -
Type: u
Description: The amount of pixels to remove in the Cr and Cb channels for
every
pixel not removed vertically. Example: For video with 4:2:0
chroma
subsampling, the ChromaSubsamplingVert should be set to 1.
Element Name: CbSubsamplingHorz
Level: 5
ID: [55][B5]
Mandatory: -
Multiple: -
Default: -
Type: u
Description: 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.
Element Name: CbSubsamplingVert
Level: 5
ID: [55][B6]
Mandatory: -
Multiple: -
Default: -
Type: u
Description: The amount of pixels to remove in the Cb channel for every
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
MatrixCoefficients/TransferCharacteristics)
Element Name: TransferCharacteristics
Level: 5
ID: [55][BA]
Mandatory: -
Multiple: -
Default: 2
Type: u
Description: 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))
Element Name: Primaries
Level: 5
Mandatory: -
Multiple: -
ID: [55][BB]
Default: 2
Type: u
Description: The colour primaries of the video. For clarity, the value and
meanings for Primaries 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, 22: JEDEC P22 phosphors)
Element Name: MaxCLL
Level: 5
ID: [55][BC]
Mandatory: -
Multiple: -
Default: -
Type: u
Description: Maximum brightness of a single pixel (Maximum Content Light
Level)
in candelas per square meter (cd/m²).
Element Name: MaxFALL
Level: 5
ID: [55][BD]
Mandatory: -
Multiple: -
Default: -
Type: u
Description: Maximum brightness of a single full frame (Maximum
Frame-Average
Light Level) in candelas per square meter (cd/m²).
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.0 <= f <= 1.0
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.0 <= f <= 1.0
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.0 <= f <= 1.0
Default: -
f
Description: Green X chromaticity coordinate as defined by CIE 1931.
Element Name: PrimaryGChromaticityY
Level: 6
ID: [55][D4]
Mandatory: -
Multiple: -
Range: 0.0 <= f <= 1.0
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.0 <= f <= 1.0
Default: -
Type: f
Description: Blue X chromaticity coordinate as defined by CIE 1931.
Element Name: PrimaryBChromaticityY
Level: 6
ID: [55][D6]
Mandatory: -
Multiple: -
Range: 0.0 <= f <= 1.0
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.0 <= f <= 1.0
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.0 <= f <= 1.0
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.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.0 <= f <= 999.9999
Default: -
Type: f
Description: Minimum luminance. Shall be represented in candelas per square
meter (cd/m²).
[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
>.
<reference to h265 doc)
On Tue, Feb 16, 2016 at 11:56 AM, Frank Galligan <frankgalligan@gmail.com>
wrote:
>
>
> On Tue, Feb 16, 2016 at 11:14 AM, Dave Rice <dave@dericed.com> wrote:
>
>>
>> On Feb 16, 2016, at 2:01 PM, Frank Galligan <frankgalligan@gmail.com>
>> wrote:
>>
>>
>>
>> On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice <dave@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
>>> >.
>>>
>>> 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
>>
>>
>
- [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] Colour Format proposal Timothy B. Terriberry
- Re: [Cellar] [Matroska-devel] Colour Format propo… Michael Bradshaw
- Re: [Cellar] Colour Format proposal Dave Rice
- Re: [Cellar] Colour Format proposal Jerome Martinez
- Re: [Cellar] [Matroska-devel] Colour Format propo… Jerome Martinez
- Re: [Cellar] Colour Format proposal Michael Niedermayer
- Re: [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] Colour Format proposal Jerome Martinez
- Re: [Cellar] Colour Format proposal Peter B.
- Re: [Cellar] Colour Format proposal Jerome Martinez
- Re: [Cellar] Colour Format proposal Dave Rice
- Re: [Cellar] Colour Format proposal Steve Lhomme
- Re: [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Dave Rice
- Re: [Cellar] [Matroska-devel] Colour Format propo… Steve Lhomme
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] Colour Format proposal Jerome Martinez
- Re: [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] Colour Format proposal Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Dave Rice
- Re: [Cellar] [Matroska-devel] Colour Format propo… Jerome Martinez
- Re: [Cellar] [Matroska-devel] Colour Format propo… Steve Lhomme
- Re: [Cellar] Colour Format proposal Peter B.
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Dave Rice
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] Colour Format proposal Reto Kromer
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Dave Rice
- Re: [Cellar] [Matroska-devel] Colour Format propo… Michael Niedermayer
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Steve Lhomme
- Re: [Cellar] [Matroska-devel] Colour Format propo… Frank Galligan
- Re: [Cellar] [Matroska-devel] Colour Format propo… Reto Kromer
- Re: [Cellar] [Matroska-devel] Colour Format propo… Steve Lhomme
- Re: [Cellar] [Matroska-devel] Colour Format propo… Dave Rice
- Re: [Cellar] [Matroska-devel] Colour Format propo… Steve Lhomme
- Re: [Cellar] Colour Format proposal Kieran O Leary
- Re: [Cellar] Colour Format proposal Kieran O Leary
- Re: [Cellar] Colour Format proposal Dave Rice
- Re: [Cellar] Colour Format proposal Dave Rice