[M4IF Technotes] YCrCb to RGB conversion

Wed May 7 15:39:22 EDT 2003

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