Re: Real-time Image Process on FPGA

OK, so webcam type stuff. These have a low pixel rate and image size

compared to other

video. Bit serial arithmetic works great for this. I think the gradient

vector flow

might be a little easier to do. > > YunghaoCheng wrote: > > > > You didn't mention your image size or pixel rate. Those are a factor in > > > determining the best approach. > > > > > > YunghaoCheng wrote: > > > > > > > Hi folks!! > > > > Now ,I am designing a real-time visual tracking system based on FPGAs. > > > > > > > > The images are captured by the CCD camera, and we do edge detection > > > > by using (Sobel-mask) 2D convolver. > > > > We also use two consecutive image > > > > frames I(k) and I(k-1) to subtracted pixel by pixel ,in order to > > > > find out the moving object. > > > > > > > > A "Moving Edge" is include by doing a logic AND operation between the > > > > subtracted image and the edge image(obtained by Sobel-mask)of the > > > > current frame. > > > > > > > > After finding out the "Moving Edge" we must to extract the object's > > > > shape > > > > by using Active Contour Model(or snake). > > > > > > > > Now I have implemented the "Moving Edge" detection function on > > > > a Xilinx FPGA.The next step is to design the "Snake-Based Outline > > > > Extraction" > > > > function block. I've found a lot of reference papers on the Google > > > > about the > > > > "active contour model" and finally I want to choose two methods--> One > > > > is Greedy algorithm based snake-model and the other one is Gradient > > > > Vector Flow (GVF)based algorithm. > > > > I wonder which one is more suitable for FPGA based architecture > > > > design? > > > > Could anyone can give me some recommendations or you have any other > > > > good ideas > > > > to design the object outline extraction function on FPGA..?? > > > > > > > > Thanks a lot!! > > > > > > -- > > > --Ray Andraka, P.E. > > > President, the Andraka Consulting Group, Inc. > > > 401/884-7930 Fax 401/884-7950 > > > email snipped-for-privacy@andraka.com > > >
formatting link
> > > > > > "They that give up essential liberty to obtain a little > > > temporary safety deserve neither liberty nor safety." > > > -Benjamin Franklin, 1759 > > > > Yes .. > > > > The image size is 320x240 and in order to meet a nearly real-time constraint, > > each image frame (320x240) processing time must be less than 34 ms. > > -- > --Ray Andraka, P.E. > President, the Andraka Consulting Group, Inc. > 401/884-7930 Fax 401/884-7950 > email snipped-for-privacy@andraka.com >
formatting link
> > "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759

Yes ..

Bit-serial methods can be used to deal with the heavy arithmetic operations in the computing of Gradient Vector and Energy Function. I also found a lot of tutorial materials on your Web site

formatting link
and they gave us some useful information. But now we still face a problem that the GVF method is like one kind of "Optimization Method" and it consumes several iterations before reaching its optimal solution. And the iteration numbers may differ from case by case.

My question is that -- "how to design a flexible structure on FPGA?" Flexible means the numbers of iteration can be changed.

Reply to
YunghaoCheng
Loading thread data ...

compared to other

vector flow

constraint,

--

--Ray Andraka, P.E. President, the Andraka Consulting Group, Inc.

401/884-7930 Fax 401/884-7950 email snipped-for-privacy@andraka.com
formatting link

"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759

Reply to
Ray Andraka

exit strategy

remaining ones.

I think that the low frame rates and resolutions involved argue for a processor based control algorithm with hardware acceleration for the per-pixel image processing.

Snake-based segmentation departs from the typical per-pixel image processing operators - indeed these are just a preprocessing step in the overall algorithm. The hard work takes place at a higher level of abstraction, that might be difficult and unnecessary to implement fully in hardware.

Were it my project, I would investigate putting a microblaze or similar core in the FPGA to handle the iterative, control-type processes, with the parallelisable grunt-work farmed out to specialised hardware units.

This might also permit a gradual migration of a C-based implementation into hardware. Get your prototype code running on a PC, port it across to the embedded processor, and go from there. Really depends on where your skills lie, and what your requirements are.

Regards,

John

Reply to
John Williams

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.