[M4IF Technotes] YCrCb to RGB conversion

[Rosiles Gerardo-ra9355]

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-special-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