FIR 2D behavioural

Hi,

> how does it work onto the Chroma(s) signal?

It does not work. The 2D FIR would apply the filter as if all chroma values belong to a single color plane.

You may be able to get around the issue by splitting the luma channel and the chroma channels, using two 2d FIR filters and then joining the streams back.

--- Quote Start ---

Hi,

> how does it work onto the Chroma(s) signal?

It does not work. The 2D FIR would apply the filter as if all chroma values belong to a single color plane.

You may be able to get around the issue by splitting the luma channel and the chroma channels, using two 2d FIR filters and then joining the streams back.

--- Quote End ---

Hi

Thanks for your reply.

So, if I understand correctly, if I get into the 2D FIR Chroma plane and Luma plane I get an elaboration ONLY on the luma plane?

> I get an elaboration ONLY on the luma plane?

I may have misunderstood your question but I think the answer is no. If you attempt to send YCbCr 4:2:2 into the 2DFIR you will have to parameterize the input as two channels in sequence Y, C. The 2DFIR filter does not understand subsampled data and it only sees a second fully sampled color plane C. Consequently, the filter would smear the Cb and Cr planes onto each other.

What I was suggesting was that:

4:2:2 (seq or par) -> VIP_ColorPlaneSequencer (splitter) -> 1 + 2

1) FIR on Y (1 seq) -> Fifo(*) -> 3

2) FIR on Cb,Cr (2 seq) -> Fifo(*) -> 4

3 + 4 -> VIP_ColorPlaneSequencer (join) -> 4:2:2 (sequence or parallel)

*Fifos may be necessary in case of throughput issues

all right, understood.

When I split the color planes how do I have to set the CPS in order to propagate correctly the non image data signals?

I think the following will work but perhaps you should confirm that the IP is doing the right thing:

For the splitter:

din0 is C Y, please make sure that this is the correct order in time (or correct endianess if in parallel)

dout0 should be C and you should halve the width of the control packets

dout1 should be Y

A slightly different way of doing the same thing is given in the VIP user guide with the 2 pixels per port option

For the joiner:

din0 should be Y

din1 should be C

dout0 should be C Y and the source of non-image packet should be din0

thanks for patience and hints

best regards

Phate.

--- Quote Start ---

splitter

din0 is C Y,

dout0 should be C and you should halve the width of the control packets

dout1 should be Y

--- Quote End ---

That is the correct endianess.

But why, for the joiner, you said

--- Quote Start ---

For the joiner:

din0 should be y

din1 should be c

dout0 should be C Y and the source of non-image packet should be din0

--- Quote End ---

shouldn't be

din0 C

din1 Y

dout0 [7:0] C

dout0 [15:8] Y

?

>shouldn't be

>din0 C

>din1 Y

>dout0 [7:0] C

>dout0 [15:8] Y

The control packet used by the joiner is the control packet from din0 by default. This is the reason why I suggested to plug the Y channel back to din0 rather than din1. Otherwise, the wrong control packet (with half the width) will be propagated.

Your choice for the output is fine if you wish to output 4:2:2 in parallel.

I know it may sound like a newbie affermation, but..

All the configurations I've tried in order to correctly split color planes, does not work.

But I don't know why.

Also halving (or not halving) control data pakets for the LSB paket, it does not work for me.

Did anyone managed to correctly speare two color planes, without using the " two pixels per port" option?

If I would use the "two pixels per port option" and color planes in parallel,my settings should be, with a color pattern in sequence YCbCr 4:2:2

din0 CrYcbY ,

dout0 Cr

Cb

dout1 Y

Y

Or I am wrong?