[M4IF Technotes] YCrCb to RGB conversion
Gary Sullivan
garysull windows.microsoft.com
Tue May 13 17:58:53 EDT 2003
I followed up further on this.
I confirmed that an approximation of the 50 Hz BT.709 coefficients are
the ones used in that Microsoft MPEG reference software tool.
That is, kr = 0.2126, kb = 0.0722 (not kr = 0.299, kb = 0.114).
For downsampling, I was told that the program uses filter tap values
[40 88 88 40] / 256
(both horizontally and vertically).
For upsampling:
I was told that the program horizontally uses filter tap values
[ 5, 11, -21, -37, 70, 228, 228, 70, -37, -21, 11, 5] / 256,
and vertically it uses filter tap values
[ 3, 7, -16, -32, 67, 227, 227, 67, -32, -16, 7, 3] / 256.
Regarding the phase of the filtering, I believe that because these
are both even-length symmetric filters, this kind
of resampling will produce correct phase
for the H.261, MPEG-1 and H.263 definitions of 4:2:0. But it will
be a little off horizontally for the MPEG-2 and MPEG-4 definitions
of 4:2:0.
-Gary Sullivan
+> -----Original Message-----
+> From: Gary Sullivan [mailto:garysull windows.microsoft.com]
+> Sent: Wednesday, May 07, 2024 2:39 PM
+> To: Rosiles Gerardo-ra9355; Wesley De Neve; technotes lists.m4if.org
+> Subject: RE: [M4IF Technotes] YCrCb to RGB conversion
+>
+>
+>
+> I am the first author on that MSDN article. Here is what I
+> know. I am
+> trying to find out more, but not promising anything.
+>
+> The half-sample shift issue is discussed in some detail in
+> the section
+> of the MSDN article on 4:2:0 to 4:4:4 conversion.
+> Vertically, yes - the resampling is technically off-phase by half a
+> sample. Horizontally, it depends on the definition of 4:2:0
+> -- if you
+> use the definition in MPEG-2 or MPEG-4 visual, they are OK
+> horizontally.
+> As Gerardo indicates, the phase shift allowed in the MSDN
+> article saves
+> some computations and probably does not significantly harm visual
+> quality.
+>
+> I believe the yuvtoavi and avitoyuv tools that Wesley mentioned as
+> coming from Microsoft are not part of any Microsoft product.
+> They were
+> provided by a Microsoft MPEG participant as part of the MPEG-4 visual
+> reference software package only, and only for purposes of aiding in
+> doing quick experiments. They are undocumented and were
+> never tested or
+> inspected to make sure they are completely correct in any
+> strict sense.
+> There may even be more than one version of them floating
+> around, and we
+> aren't confident of what they are doing. They were written several
+> years before that MSDN article and by a different person at
+> Microsoft.
+> He'll be out of the office for the next week.
+>
+> They are also not the same thing as the yuv2avi code
+> distributed by S.
+> Worral.
+>
+> In regard to the color conversion formulas, I think they use a
+> conversion matrix that is closer to the 60 Hz coefficients of ITU-R
+> BT.709 rather than the coefficients used in the MSDN article
+> (which are
+> based on ITU-R BT.601 and are thus equivalent to the 50 Hz
+> coefficients
+> for ITU-R BT.709 rather than the 60 Hz coefficients). I'm not sure
+> about this -- the subroutines within the code support a number of
+> different sets of conversion coefficients and I haven't
+> verified which
+> one is being used, but that is what I was told some time ago.
+>
+> I don't yet know how they do the upsampling and downsampling, but I
+> would not be surprised if I learned that their resampling
+> methods were
+> sloppier than those in the MSDN article.
+>
+> Best Regards,
+>
+> -Gary Sullivan
+>
+> +> -----Original Message-----
+> +> From: Rosiles Gerardo-ra9355
+> [mailto:Gerardo.Rosiles motorola.com]
+> +> Sent: Wednesday, May 07, 2024 1:33 PM
+> +> To: 'Wesley De Neve'; Rosiles Gerardo-ra9355;
+> +> technotes lists.m4if.org
+> +> Subject: RE: [M4IF Technotes] YCrCb to RGB conversion
+> +>
+> +>
+> +> Hello,
+> +>
+> +> One more thing that catched my eye on the MSDN explanation
+> +> is that the chroma upsamling they propose is not 100%
+> +> correct. They do not correct for the half sample shift that
+> +> is introduced during the 4:2:2 to 4:2:0 down conversion (in
+> +> MPEG-2 terms). This effectively saves you half of the
+> +> computations required on 4:2:0 to 4:2:2. Not correcting for
+> +> this phase misalignment could potentially introduce color
+> +> shifts. However, I suspect that after compression the chroma
+> +> information has been quantized so much that the 1/2 pel
+> +> shift does not matter.
+> +>
+> +> Your experiment without compression also points in this
+> +> direction, but I'll make sure you test with a few sequences
+> +> with and without the phase alignment to be sure it meets
+> +> your quality expectative.
+> +>
+> +> FYI, for interlaced video testing I have used the VQEG
+> +> sequences. I have read reports (see
+> +> http://www.hometheaterhifi.com/volume_8_2/dvd-benchmark-speci
+> +> al-report-chroma-bug-4-2001.html) of disturbing artifacts
+> +> introduced by processing interlaced data as progressive data
+> +> for chroma upsampling.
+> +>
+> +> Regards,
+> +>
+> +> Gerardo
+> +>
+> +> -----Original Message-----
+> +> From: Wesley De Neve [mailto:Wesley.DeNeve ugent.be]
+> +> Sent: Wednesday, May 07, 2024 2:35 PM
+> +> To: Rosiles Gerardo-ra9355; technotes lists.m4if.org
+> +> Subject: Re: [M4IF Technotes] YCrCb to RGB conversion
+> +>
+> +>
+> +> Hi Gerardo, Tobias, all,
+> +>
+> +> Rosiles Gerardo-ra9355 wrote:
+> +> > Hi Wesley,
+> +> >
+> +> > This method is correct in DSP terms. The difference in
+> +> implementation
+> +> > could be the filters that are actually used. One more
+> thing to be
+> +> > aware of is if you are working with interlaced or
+> +> progessive frames.
+> +> > The spatial relations between Chroma and Luma are
+> +> different between
+> +> > the two scans. For interlaced scan a different set of
+> filter taps
+> +> > would be required. It seems this site explains only the
+> case for
+> +> > progressive conversions.
+> +>
+> +> good to know that.
+> +>
+> +> > Do the yuvtoavi tools support interlaced standard conversion?
+> +>
+> +> I don't think they support deinterlacing, but I'm not sure
+> +> about that due to the lack of documentation. The input test
+> +> sequences were normally progressive.
+> +>
+> +> I'm interested in the applied formulas because there has to
+> +> be a large difference between the ones applied in the
+> +> avitoyuv/yuvtoavi tools and those implemented by the tool as
+> +> found on
+> +> http://www.ee.surrey.ac.uk/Personal/S.Worrall/dloads/yuv2avi.
+> zip.
+>
+> I did a test with the foreman test sequence in which I
+> placed the first
+> frame in an AVI file by making use of yuv2avi (also doing a
+> conversion
+> to the RGB888 colorspace). After that I immediately
+> extracted the frame
+> in question from the AVI file by the avitoyuv tool (doing a
+> conversion
+> back from RGB888 to YCrCb). Result: Y-PSNR +/- 20 dB (and
+> this without
+> compression...). Today I've seen in the history of this
+> mailinglist that
+> yuv2avi indeed has some strange behaviour
+> (http://lists.m4if.org/pipermail/technotes/2002-July/000982.html).
+>
+> As Tobias already mentioned, it's indeed better to implement
+> those tools
+> by yourself and I've done that for PSNR calculation, for RGB/YCrCb
+> conversion (based on the equations as described by MSDN), and for
+> putting YCrCb frames in the MOV file format (not yet for the AVI file
+> format). On the other hand, I do not want to invent the
+> wheel twice ;-).
+>
+> Thanks for the replies,
+> Wesley
+> _______________________________________________
+> Technotes mailing list
+> Technotes lists.m4if.org
+> http://lists.m4if.org/mailman/listinfo/technotes
+>
+> _______________________________________________
+> Technotes mailing list
+> Technotes lists.m4if.org
+> http://lists.m4if.org/mailman/listinfo/technotes
+>
More information about the Mp4-tech
mailing list