Re: [Cellar] Colour Format proposal

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?

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.

_______________________________________________
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