Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal

From: Frank Galligan <[email-masked]>
Date: Wed, 16 Mar 2016 21:46:53 -0700

OK really no comments for a long time.

On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer <[email-masked]
> wrote:

> Hi
>
> On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan wrote:
> > 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.
> >
>
> what would this be set to for old 16bit rgb, that is 5 bit red
> 6 bit green, 5 bit blue rawvideo.
> This maybe does not matter and iam not strongly suggesting to add it,
> rather i want to point it out so its not unintentionally forgotten
>

I didn't get into RGB here. As you said 565, 551, there are a good amount
of combinations. I think DirectShow (or maybe it was DirectDraw) that had
R,G,B, and A masks to show which bits belonged to which channel. I also
worked with formats like RGBBGR repeating.

>
>
> [...]
>
> > 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.
>
> What if Cr is subsampled more than Cb ?
> That too is rather obscure, but theres code in FFmpeg to handle such
> jpegs, so i suspect this case while very rare is not entirely non
> existent ...
>

I guess we can add that as well if more people really want it. Actually I
didn't even have CbSubsampling* elements at first. I only added that to
support the 4:2:1 format that was defined in the first enum.

>
>
> >
> >
> > 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)
> >
>
> iam not sure this is enough to specify all variants
> for 4:2:0 alone there are a few different variants
> theres mpeg1 style
> mpeg2 progressive and interlaced
> the mpeg2/mpeg4 style also differs from itself if the image is fliped
> right-left
> cropping 1 or 2 lines of the top of mpeg2 yuv420 also results in
> different variants
>

I also didn't get into interlaced.

I don't think we should add enough elements to support every format that
was ever produced. Opinions?

I think we should probably strive to support 99% of what is currently
produced today. Opinions?

Next what are we missing and what do you think we need to add to support
the formats?

Would adding interlaced and horizontal flip elements be enough to support
the 4:2:0 that people are using today?

>
> [...]
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
>

---

From: Steve Lhomme <[email-masked]>
Date: Mon, 28 Mar 2016 14:05:39 +0200

2016-03-17 5:46 GMT+01:00 Frank Galligan <[email-masked]>:
> On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer
> <[email-masked]> wrote:
>>
>> Hi
>>
> I didn't get into RGB here. As you said 565, 551, there are a good amount of
> combinations. I think DirectShow (or maybe it was DirectDraw) that had
> I don't think we should add enough elements to support every format that was
> ever produced. Opinions?

For archival (one of the main goal here) I think we should.

> produced today. Opinions?

The problem is that when you leave 1% out, you need to be sure it's
possible to integrate it later. Usually the best approach is to know
beforehand how you're going to do it. So in the end it's just like
covering it. That's just a general remark though.

> Next what are we missing and what do you think we need to add to support the
> formats?
>
>
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar
>

-- 
Steve Lhomme
Matroska association Chairman

---

From: Frank Galligan <[email-masked]>
Date: Tue, 29 Mar 2016 09:11:52 -0700

> covering it. That's just a general remark though.
I don't want to exclude anything in the future, but I also don't want to
make something overly complex/over specified to support a format that will
barely see any use.

I want to move forward with this, so how about we make a list and then vote
on what we think should be added to the sepc?
1. Raw RGB
2. Raw YUV
3. Interlaced
4. mpeg1 style
5. mpeg2 pogessive
6. mpeg2 interlaced
7. image flipped right-left
8. jpeg Cr subsampled more than Cb
9. non-linear color values (DPX scans)

Anything else we should add?

> the

---

From: Reto Kromer <[email-masked]>
Date: Tue, 29 Mar 2016 18:46:49 +0200

Frank Galligan wrote:

>I want to move forward with this, so how about we make a
>list and then vote on what we think should be added to the
>sepc?

>9. non-linear color values (DPX scans)

The non-linear world would be very useful - at least for me.

10. Bayer filters.

And I am personally a unconditional supporter of YCoCg - for
strictly mathematical reasons! - yet I feel often alone.

Best regards, Reto

AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: http://reto.ch | Twitter: @retoch

AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: http://reto.ch | Twitter: @retoch