Re: [Cellar] Colour Format proposal

On Sat, Feb 13, 2016 at 8:22 AM, Jerome Martinez <[email protected]>
wrote:

> On 13/02/2016 02:53, Dave Rice wrote:
>
>
> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel <
> [email protected]> wrote:
>
> [...]
>
> 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.
>
>
> I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because
> there is no explaination about Cb and Cr in SubsamplingHorz and
> SubsamplingVert.
> So maybe we need to add explanation.
> SubsamplingHorz and SubsamplingVert are for both Cb and Cr except
> indicated otherwise.
> CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and
> SubsamplingVert if not present.
>
Jerome, check out the text I added to Dave's email and let me know if you
think that is better.


>
> [...]
>
> 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.
>
>
> I don't follow: either we say that the list is the ISO/MPEG one and we
> need to find another way to provide HLG value, or we say that we don't care
> of MPEG list.
> Looks like we are in the middle (+ trying to use the FFmpeg list).
>
I think the FFmpeg list is just using the 265 list, which is basically a
superset of 23001-8 (or 264 list).

For example an answer about the reason we keep 0 and 3 as reserved is that
> it is in other specs, but we also say that we don't care of other specs. I
> am lost.
>
If we forego the other lists, then I agree we should only have one value as
unspecified.


>
> About HLG, my concern is not about Matroska v4 finalization, a bit out of
> topic actually (a list would be update without a new version of Matroska)
> but about the MPEG list. From document pointed by Dave, looks like ARIB has
> a deal with MPEG and ISO, or tries to force value 18 for HLG, so I would
> also use value 18, hoping that MPEG and ISO and ITU will accept value 18
> for HLG.
>

> Then for values 16, 17, and 18 we could add better descriptions and
> citations to define it better internally. 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.
>
>
> Values 16 and 17 are already in ITU H.265 documentation. I would reference
> this document (bonus: it is publicly available)
> I would just add a comment about value 18 = HLG.
>
If everyone else wants to do this, then I wouldn't object. The only reason
I wouldn't want to do this, is that H.265 is a specific codec. I don't want
to confuse people that these values are 265 specific.


> But as a general view of how we manage the list: how do we plan to manage
> it? If we say we try to follow MPEG list, maybe we need to have "temporary"
> value e.g. >0x1000000 and we wait for an official announcement from
> ITU/MPEG/ISO about value 18; if we don't care on any other list, we don't
> care of the value for HLG (18 or whatever).
>
This is what I was trying to get at from the start. Do we want to try and
follow another list? It seems like all of the lists try and follow each
other, which I guess is good. But what happens when two diverge?


>
> I think that before freezing the list, we need to clear about what is this
> list, if we try to follow another list we need to wait for its maintainer,
> else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list,
> why do we have 0=reserved and 3=reserved and why 2=unspecified when all
> other tags have 0=unspecified and why 4 values (1, 6, 14, 15) for the same
> transfer characteristic? I would ask for a reason to have such value in the
> list or remove it from the list, i.e 0=unspecified, 1=ITU-R BT.709, 2=ITU-R
> BT.470M...
> And define a method for updating it (and say who is the list maintainer)
> if we are the "owner" of the list.
>
I agree if Matroska decides to maintain their own list, we should get rid
of any redundant values.

But I would rather follow another list (or bunch of lists that follow each
other) then try and maintain our own.

>
> Jérôme
>

_______________________________________________
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