Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Consider google.comStill looking for some suggestions.
Still looking for some suggestions.
Consider google.com
http://www.itee.uq.edu.au/~damien/GuRoo/theses/Wong.pdf
-- Mike Treseler
Are you trying to what the CMU CAM does? Have you read the CMU papers? BlobWhat I did for Google was this:
FPGA OR ASIC "blob analysis"
which gave about 165 hits, but none of them seem to
point me in the direction of any source code or even to
any theoretical discussions. If you think I should
try another search then please do suggest something.
Brad,I have been doing some investigation into blob analysis algorithms
and would like to know if there are any designs that have been
rendered into FPGAs.
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message
news:10ad0596rrmu4da@corp.supernews.com...
What I did for Google was this:
FPGA OR ASIC "blob analysis"
which gave about 165 hits, but none of them seem to
point me in the direction of any source code or even to
any theoretical discussions. If you think I should
try another search then please do suggest something.
Are you trying to what the CMU CAM does? Have you read the CMU papers?
Blob
analysis doesn't mean anything to me so I'm guessing here, but perhaps you
meant center-of-mass type things?
The image processing stuff is generally DSP based as the algoritms are to
delineate an area using a standard convolver algorithm and then to track
its
"center of mass" using standard graphics techniques for finding the center
of a polygon. (See Eberly's FAQ for that code).
Off the top of my head I'm guessing you could do some clever stuff whereby
you keep an array of pixels in a the block ram of an FPGA, and use some
form
of iso-bar type system to connect regions with similar pixels. I'm not
sure
what the logic would look like, something like
for (pixel = 2048 downto 0)
begin
if ( NEIGHBOR(0,pixel) or
NEIGHBOR(1, pixel) or
NEIGHBOR(2, pixel) or
NEIGHBOR(3, pixel) or
...
NEIGHBOR(7, pixel) ) then
group[pixel] <= group_id;
group_id++;
end if;
end for;
Like I said, I'm no expert. Basically you want logic that creates a
comparator whose inputs are the logically adjacent pixels for each
individual pixel, and a second array which is the group membership
function
(in or out). If you set a specific criteria for membership (like the pixel
is a particular color) then this will probably work for you.
Then on each vertical retrace you need to compute the center of mass of
pixels in the "group."
--Chuck
"Brad Smallridge" <bradsmallridge@dslextreme.com> wrote...
I have been doing some investigation into blob analysis algorithms
and would like to know if there are any designs that have been
rendered into FPGAs.
Brad,
We are doing some work in this area for a robotics application. When
we first started our investigation of the literature, we found that
the existing implementations did not meet with our requirements for
implementation in an FPGA.
In our system we require that the pixels be presented to any image
processing engine only once, or we will get killed on memory
bandwidth. Most of the existing literature details algorithms that
are stack based that iterate through the image in a pattern that can
not be known a priori. Additionally, these algorithms tend to
require a variable amount of time, depending on the number of blobs
that are identified, and the shapes of these blobs.
A run length encoding approach, which I have seen detailed in the
literature, is a good starting point for the requirements that we had,
especially since we could ignore non-convex blobs in our application.
Though, it should be noted, a linescan blob finder can find non-
convex blobs, as long as it is capable of merging two or more blobs
that are found to overlap later in the image.
For any discussion to go forward, it would be helpful to understand
what your requirements are. If this is a commercial application,
please feel free to contact me offline, as we may be able to adapt
an existing core from our library.
If this is to be a public exercise, please offer the group an idea
as to the following:
performance requirement
application
maximum number of objects that you wish to find in a given image
whether you need to just find objects, or track across images
do you need to find non-convex blobs?
Blobfinding can be done in guaranteed time in a linescan fpga
implementation, the details of the implementation are highly
dependent upon the answers to the above questions.
Regards,
Erik Widding.
---
Birger Engineering, Inc. -------------------------------- 617.695.9233
100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com
That is basically true, but I expect it was a limitation of the computeI have read some CMU documentation but nothing
about blob analysis. I had believed that the CMU
can only track one blob whereas I need to collect
data about lots of blobs.
Comes from the weather service, imagine that you have a "cloud" of pixelsCenter of gravity is good.
Long axis, area, etc. If you suggest I will look
deeper into the CMU docs and web sites. Thanks.
What is iso-bar?
This is one of those times where leaving it for a year or so and coming backOn one of your other post you are comparing
a std_logic_vector to another. I suggest you
repost and state what libraries you are using.
I remember a difficulty in the original VHDL
spec that didn't allow for this that may have
been patched up by a library. VHDL has
been a work in progress for many years with
most improvements added via libraries.
hi Brad,Still looking for some suggestions.
We identified the option that you described, and a second approachI have done some armchair thinking about how to keep and
combine blobs if they should merge in susbsequent lines.
This may be done by keeping start and stop points of the
various blobs in a RAM LUT. But maybe this isn't the
best approach?
Exactly. In some vision applications, very few features need to beI saw mention of run length encoding in a web page by
Wintress. I do not know what advantage that encoding has
over a fifo that would give you the pixel threshold on every
pixel clock. I do know that some camera manufacturers like
Basler make cameras that threshold and run length encode
their outputs presumably to cut down on cable bandwidth.
The term evolved from the notion that blobs are inherently convex.I am not sure what you mean by the term non-convex. To
a newbie that is concave but you don't use the word concave
so perhaps this has a different meaning.
Which mode of connection you choose is entirely applicationI have also come across 4 neighbor or 8 neighbor terminology
which I assume represent the rules for making a connection,
based on a tic-tac-toe arrangement of pixels. I would suppose
that the 8 neighbor approach would be a tad more robust but
may lead to narrowly connected blobs with only a point in
common. Whis is better?
I do not suspect you will find any source code, but please don't useOn my web searching I have tried to refine my search to
just source code by using unique VHDL keywords like
downto and inout. However I didn't find anything with
this search: downto inout blob. Any suggestions to
better search techniques or Verilog keywords will
be appreciated.
Actually, our involvement with robotics has been limited to theAnother roboticist. Thanks so much.
Do you want to share with the group what Birger does?