Re: [video] Alpha blending 4:2:2 sources

[Alexander.Holland@Zarlink.Com]

Hi,

> OK, what is the problem you are trying to solve ?

I have several problems.

1) Should I use a 4:2:2 linestore for gfx before blending or a 4:4:4 one
and then decimate?
2) Should I blend my 4:2:2 gfx directly with the 4:2:2 video, what about
transparent pixels?
3) Should I use a 4:4:4 linestore and up-interpolate the video to 4:4:4 and
then blend and then decimate to 4:2:2?
4) What does everyone else do?

Background
----------

MPEG Video graphics are coming out of the video scaler in 4:2:2 (8-bit per
component) YCrCb.

Graphics are being constructed in a line buffer before being blended to the
video.

If I use a 4:2:2 line buffer for my graphics,

1) You are restricted to aligning all graphics on pixel pair boundrys to
avoid Chroma phase differences, and perhaps limiting objects to sizes which
are a power of 2.

2) Overlapping graphics (using a painters algorithm on the line buffer)
suffer from fringing effects at the edges (and at Transparent pixel
locations).

Imagine the Line buffers contents are:

<Cb0><Y0><Cr1><Y1><Cb2><Y2><Cr3><Y3><Cb4><Y4>

And I want to overlay a new object (Also 4:2:2). It has to be 2 pixels wide
and it has to start at pixel 0, pixel 2 or pixel 4 to avoid chroma phase
mismatches.

<Cb2'><Y2'><Cr3'><Y3'>

I end up with the following line

<Cb0><Y0><Cr1><Y1><Cb2'><Y2'><Cr3'><Y3'><Cb4><Y4>

As you can see, <Cb2'>, has no Chroma information in it with respect to
<Y1> and so for Pixel 1 the wrong colour is calculated, the same happens
for pixel 3.

If I use a 4:4:4 Line buffer these problems dont occur, but you have to
decimate the lines stores to 4:2:2 before blending with the Video. This
seems like a waste of RAMS.

You could identify these edge, and transparent conditions, and do a
read/modify/write on the values, averaging the chroma values between the
two pixels, but I dont really have the bandwidth.

Anyhow assume I've used a 4:4:4 linestore, decimated down to 4:2:2 and I am
now ready to blend with the video.

> Depending on the output requirements, you could look at converting both
> blender inputs to 4:2:2 with the same Cb, Cr phase.

That is what I have, the Linestore is 720 pixels wide, the video is 720
pixels wide, and both start with the same Cb,Cr phase.

So I assume that I'll be able to use

dest_chroma = a * Gfx_chroma + (1 - a)Video_chroma;
dest_luma = a * gfx_luma + (1 - a)video_luma;

The only thing which I am concerned with is again Transparency. Where there
are Transparent gfx pixels, with video pixels visible through.

When the gfx was in 4:4:4, the transparent pixels had a AYCrCb of 0, not
sure what happens after decimation, and if I need an alpha other than 0, to
avoid Colour fringing effects.

> Otherwise, you'll probably want to upsample to
> 4:4:4, as well as converting (if necessary) to
> a shared colour space such as YCbCr.

I suggested this to my workmates (who, like myself, dont have any gfx
experience) and they dismissed it, saying that when you decimate back to
4:2:2 on pixels that dont have any gfx overlaid, you may not get the same
values you put in.

> I guess you're not bothered that
> Pn = a * Gn + (1 - a)Vn doesn't really give
> the right results if [Gn] or [Vn] contains an
> alpha component.

Not sure what you mean?

> What happens after the blender ?

Syncs + 601 goto the internal DENC, ITU656 goes to pins.

> Do you want to keep the 4:4:4 for a SCART DENC or some other gadget ?

Not that I know of. We have an onchip SCART DENC, but it's input is 601.

> For consumer SD applications, not a lot of people are going to complain,
> or even notice, if you just wack 4:4:4 blender output back down to
> 4:2:2.

Yes?

> If either of the blender inputs has energy in the Cb, Cr, or alpha
> channels above a quarter of the Y sample rate, you'll want a low-pass
> somewhere.

I dont really know very much about it, I was handed this algorithm and told
to implement

Y'n = 1/2*Yn + 1/4*Y(n + 1) + 1/4*Y(n - 1)

Where n =  Line number.

I guess I need even MORE linestores :(

This filter is a "do if we have time". Not sure if it is very important or
not.

Thanks for replying.

Cheers

Alexander Holland
Graduate ASIC Engineer
Zarlink Semiconductor


--
To unsubscribe from video mailing list please visit http://www.opencores.org/mailinglists.shtml