Image Processing on sbRIO-9651 SOM

[RizwanSaleem]

Hello Everyone, 

I am using SOM sbrio-9651 development kit, i've interfaced an AMLCD with it. I've implemented an image rotation algorithm on RT, after processing I am sending this data to LCD via FPGA using DMA FIFO. Image rotation is being displayed on LCD but issue here is that I am not getting the desired frame rate per second (25FPS/40ms) as RT is taking much time for processing. Currently image processing time is around 250-270ms.

For Image rotation, I have developed my code in C and then using it in RT labview via Call Library Node.

If I develop some algorithm in Labview RT vi it takes approx... 600-700ms, (I also used image rotation example provided in LABVIEW Example) that’s why I am using my C code for image rotation.

I tried to transfer my original image data on FPGA for processing but problem here is image size (1MB) and I can’t transfer it to FPGA BRAM.

Is there any way I can increase my frame rate per second? Also can I use NI-IMAQ for SOM sbrio-9651, will it be a good practice?

Any suggestion or example code is more than welcome?

[richtian]

Do you always rotate a same angle? Or is the angle changed frame by frame? If the algorithm is the same as Rotate a Picture.vi example, I think you should have a chance to achieve your targeted frame rate.

Thanks,

Richie

[RizwanSaleem]

Hi Richie,

Angle of rotation is changing for every frame and my algorithm is a bit improved version of Rotate a Picture.vi example, as processing time for my algorithm is 220ms and if i import Rotate a Picture.vi example to my RT target its processing time is 450~500ms. 

Thanks,

Rizwan

[richtian]

How do you do the algorithm? I benchmark the example on 9607, which has the same Zynq as your target, and get the key algorithm run at 110ms.

[richtian]

Oh, I guess I forgot to check the image size. Your image size must be larger than that example. Sorry for the confusion.

Does your application allow latency for the image flow? If yes, how about consider using FPGA to do the index calculation, stream up the indexes, and get the actual images from RT and display the pictures?

Thanks,

Richie

[RizwanSaleem]

Hello Richie,

Thanks for your reply, please bear with me this is gonna be a long reply, yes my image size is larger(1MB) than the one used in example that's why my processing time is greater.

I tried to transfer my original image data on FPGA for processing but problem here is image size (1MB) and I can’t transfer it to FPGA BRAM. i tried to do it through Host memory buffer (HMB)

I am transferring all the image data to HMB and then accessing it on FPGA through CAPI interface. Example i'm using is at following link:

http://www.ni.com/example/53881/en/

HMB implementation on FPGA is as follows:

HMB implementation

Data being passed to LCD as follows:

Data from HMB buffer passed to LCD I/Os

CAPI code: CAPI code is also attached with file name 'ImageTransform.c' .

CAPI code

But the problem i am facing here is that image is not being displayed on LCD. There is some syncing issue i guess.

[RizwanSaleem]

and what do you mean by "stream up the indexes" ?

Thanks,

Rizwan

[richtian]

Hi, Rizwan

In my mind, HMB is an approach similar to DMA. For example, Host Write and FPGA Read. I feel that you don't use it correctly.

I think the time consuming part is the index calculation, because the algorithm is just indexing the original picture according to the calculated indexes. What I was thinking is to give FPGA the rotate angle, let FPGA calculate the indexes and send the calculated addresses back to host through DMA, let RT index the correct pixels and send the pixels to FPGA through DMA for display. If the HMB can work and fast enough, probably, the process can be a little easier. The new process could be that RT writes the raw picture into HMB (if it's large enough to hold the whole picture ), RT gives FPGA the angle for current frame, FPGA calculates the indexes according to the angle and indexes the pixels from the HMB according to the calculated address and sends the pixels to the LCD.

Hope this makes my point clear. I've never done such a thing. Just image. 🙂

Thanks,

Richie