[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