[M4IF Technotes] YCrCb to RGB conversion

[Wesley De Neve]

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