Re: [Cellar] Colour Format proposal
Frank Galligan via Matroska-devel <[email protected]> Thu, 4 Feb 2016 12:51:51 -0800
| Newsgroups | gmane.comp.multimedia.matroska.devel |
|---|---|
| Message-ID | <CAJGH+UvijFA4V38cPa68x1szVXa4_h54QjSoMVDCJ6zLDAf3oQ@mail.gmail.com> |
On Wed, Feb 3, 2016 at 1:30 AM, Steve Lhomme <[email protected]> wrote: > 2016-02-03 7:25 GMT+01:00 Dave Rice <[email protected]>: > > > > On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel > > <[email protected]> wrote: > > > > On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme <[email protected]> > wrote: > >> > >> 2016-01-06 23:30 GMT+01:00 Frank Galligan <[email protected]>: > >> > > >> > > >> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[email protected] > > > >> > wrote: > >> >> > >> >> Thanks for your detailed proposal. > >> >> It is a lot of items, I am not expert in all domains but I have some > >> >> comments: > >> > > >> > Neither am I, but I figured we might as well start from a proposal and > >> > iterate from there. > >> > > >> >> > >> >> Name: MatrixCoefficients (or Matrix. You don't use "Colour" with > >> >> "Primaries" element, so I would not use it here too) > >> > > >> > Sounds good to me. > >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> 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) > >> > > >> > When authoring the video, I'm not sure why the software would not know > >> > the > >> > bits per channel. Can you describe a use case where the this is > unknown? > >> > >> When remuxing an older file. Either from Matroska source or AVI or > other. > >> > >> Now if elements are mandatory with a default value to "unknown" it's > fine. > >> > >> > I really think we should make this mandatory and have authoring > software > >> > populate the element (or default) vs software thinking this was > >> > non-mandatory and not populating this element because the developer > >> > didn't > >> > think it was needed. > >> >> > >> >> > >> >> > >> >> > >> >> 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). > >> > > >> > I'm fine with coming up with a more extensible solution (Micheal asked > >> > for > >> > that as well). > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> 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 > >> > > >> > I thought someone mentioned to me before that the range could change > >> > based > >> > on the matrix and transfer function. I'm fine with your proposal. > >> > > >> >> > >> >> > >> >> > >> >> 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. > >> > > >> > Someone who knows more about this should propose something to this > list > >> > to > >> > be included. > >> > > >> >> > >> >> there are also other colour ideas with e.g. EBU Tech 3349. > >> > > >> > If this is important to people, then we could add this as well. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> 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. > >> > > >> > I don't know the H.26x list. I started with my own, but then switched > to > >> > FFmpeg as they already had an extensive list and assumed they have > seen > >> > a > >> > lot of the video already. > >> > > >> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg would be > >> > better as it handles a lot more video than H.26x. > >> > > >> >> > >> >> 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) > >> > > >> > Yeah HLG is relatively new, but has been requested by a few people. > >> > > >> > > >> > > >> > _______________________________________________ > >> > Cellar mailing list > >> > [email protected] > >> > https://www.ietf.org/mailman/listinfo/cellar > >> > > >> > >> > >> > >> -- > >> Steve Lhomme > >> Matroska association Chairman > > > > > > So I updated my original proposal based on comments from this list. > > > > Changes: > > - Added more common ChromaSubsampling values > > - ColourMatrix renamed to Matrix > > - Added a default value of 0 to BitsPerChannel to signify "unspecified". > > - Added "decoded" to BitsPerChannel note. > > - Added ChromaSittingHorz and ChromaSittingVert elements. > > > > > > In this case, I think the intended term is ‘siting’ rather than > ‘sitting’. > > > > - Added Broadcast range to Range element. > > - Removed mandatory flag for elements with unspecified defaults. > > - Updated element IDs. > > > > > > - I kept "Defined by Matrix/TransferFunction" in Range element because > there > > are ranges that fall outside of Broadcast and Full depending on the TF. > E.g. > > xvYCC (61966-2-4) > > - Does someone want to propose something better for ChromaSubsampling? > > - I know some people expressed that they don't think starting from FFmpeg > > for the TransferFunction is a good idea as they might have got something > > wrong or too subjective. But I just used it as a starting point for a > list. > > I can reorder the list however we want. I also don't think following > another > > list, so we will be compatible with future additions, will give us what > we > > want as that list most likely will be incomplete with something that is > > defined only in a different list. So should we just start with a list, > > re-order it (so we are not explicitly following it), then add what is > > currently missing? Then in the future if someone needs to add something > to > > the list it can be brought up here? > > > > > > I think Jerome’s main point was that FFmpeg’s list themselves were based > on > > something else, so we should follow the source for a vocabulary > authority. > > For instance, see ITU Recommendation H.264 at > > https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. Pages > 387 > > (pdf page 409) gives a table of color primaries, page 388 has transfer > > characteristics, and 392 has Matrix coefficients. The information in the > ITU > > docs provides a lot more context than FFmpeg source code. > > > > This is what I currently have: > > > > The parent element would be Video [E0]. > > > > > > Element Name: Colour > > Level: 4 > > ID: [55][A0] > > Mandatory: - > > Multiple: - > > Default: - > > Type: m > > Description: Settings describing the colour format. > > > > > > Element Name: Matrix > > Level: 5 > > ID: [55][A1] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Colour Matrix 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) > > > > > > I suggest referencing a specific ITU document for these values and their > > meaning. > > > > Element Name: BitsPerChannel > > Level: 5 > > ID: [55][A2] > > 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. > > > > > > Element Name: ChromaSubsampling > > Level: 5 > > ID: [55][A3] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: > > 4:2:0, > > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) > > > > Element Name: ChromaSittingHorz > > > > > > Siting > > > > Level: 5 > > ID: [55][A4] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: > > Left > > collocated , 2: Half) > > > > Element Name: ChromaSittingVert > > > > > > Siting > > > > Level: 5 > > ID: [55][A5] > > 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][A6] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: (0: Unspecified, 1: Broadcast range, 2: Full range, 3: > Defined > > by > > Matrix/TransferFunction) > > > > > > I think a description (beyond the list) is needed. > > > > Element Name: TransferFunction > > Level: 5 > > ID: [55][A7] > > Mandatory: - > > 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)) > > > > > > Consider referencing ITU document as an external authority for the > > vocabulary. > > > > Element Name: Primaries > > Level: 5 > > Mandatory: - > > Multiple: - > > ID: [55][A8] > > 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) > > > > > > Consider reference to ITU document. Needs a description besides list. > > > > Element Name: MaxCLL > > Level: 5 > > ID: [55][A9] > > 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][AA] > > > > > > [55][AA] is already in use as FlagForced. > > > > 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][D0] > > Mandatory: - > > Multiple: - > > Default: - > > Type: m > > Description: SMPTE 2086 mastering data. > > > > > > I’m not well experienced in MasteringMetadata but wouldn’t this data > need to > > change from scene to scene rather than be stored within the Tracks > element > > where the same values would apply to all scenes? > > > > Element Name: PrimaryRChromaticityX > > Level: 6 > > ID: [55][D1] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > The description is actually a range. When we initially drafted > information > > on expressing ranges in EBML definitions, I ignored float, see > > > https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown#expression-of-range > . > > I can update this definition to include floats and greater-than-or-equal > > values. But the description for this and the following elements should be > > moved to range (suggested formatting as "0-1”). Then these elements need > > actual descriptions. > > Rather "0.0-1.0" then. > > > Element Name: PrimaryRChromaticityY > > Level: 6 > > ID: [55][D2] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: PrimaryGChromaticityX > > Level: 6 > > ID: [55][D3] > > Mandatory: - > > Multiple: - > > Default: - > > f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: PrimaryGChromaticityY > > Level: 6 > > ID: [55][D4] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: PrimaryBChromaticityX > > Level: 6 > > ID: [55][D5] > > Mandatory: - > > Multiple: - > > Default: - > > f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: PrimaryBChromaticityY > > Level: 6 > > ID: [55][D6] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: WhitePointChromaticityX > > Level: 6 > > ID: [55][D7] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: WhitePointChromaticityY > > Level: 6 > > ID: [55][D8] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <= f <= 1. > > > > > > Element Name: LuminanceMax > > Level: 6 > > ID: [55][D9] > > 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 > > > > > > Add a Range value and split the Description and Range. > > > > Element Name: LuminanceMin > > Level: 6 > > ID: [55][DA] > > 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 > > > > > > Add a Range value and split the Description and Range. > > > > Best Regards, > > Dave Rice > > > > > > _______________________________________________ > > Cellar mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > _______________________________________________ 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