Ruben Veiga
Ruben Veiga

Reputation: 343

Blob detection in C (not with OPENCV)

I am trying to do my own blob detection who will receive a real time video, and try to detect a white paper sheet. Even if is something written inside the paper. I need to detect the paper and is corner, because what i really want is to draw a opengl polygon over the paper in each corner of the paper will be a corner of the polygon. Then i need the coordinates of the paper to do other stuffs. So i need to: - detect a square white blob. - get the coordinates of the cornes - draw a polygon over the white sheet.

Any ideias how can i do that?

Upvotes: 1

Views: 1536

Answers (2)

moooeeeep
moooeeeep

Reputation: 32512

I am trying to do my own blob detection who will receive a real time video, and try to detect a white paper sheet.

Your first shot could be a simple flood-fill. That is, select a good threshold to binarize the image and apply the algorithm. The threshold can be fixed if you know the paper is always brighter than X and the background is always darker than this. Or this can be an adaptive threshold, for example Otsu's method. OpenCV offers this for free.

If you'd need to speed it up you could use a union-find data structure.

Finally you'd need to come up with some heuristic how to identify the corners (e.g. the four extreme values in x/y direction).

Then i need [...] the coordinates of the cornes [...]

Then you don't need blob detection, but corner detection or contour detection in the first place. OpenCV has some nice functionality for exactly this. If you can't use it, I would suggest to binarize the image as above and use a harris-detector to find the corners of the object.

OpenCV's TBB support could also come quite handy if you'd use it and you have problems to meet your real-time requirements.

Upvotes: 2

LSerni
LSerni

Reputation: 57388

Much depends on context. For example, suppose that you:

  1. know that the paper is always roughly centered (i.e. W/2, Y/2 is always inside the blob), and no more rotated than 45 degrees (30 would be better)

  2. have a suitable border around the sheet so that the corners never touch the edges of the FOV

  3. are able (through analysis of local variance, or if you're lucky, check of background color or luminance) to say whether a point is inside or outside the blob

  4. the inside/outside function never fails (except possibly in the close vicinity of a border)

then you could walk a line from a point on the border (surely outside) and the center (surely inside), even through bisection, and find a point - an areal - on the edge.

Two edge points give a rect (two areals give a beam), two rects give an intersection (two beams give a larger areal) - and there's your corner. You should carry along the detection uncertainty (areal radius) in order to validate corners (another less elegant approach is to roughly calculate where the corner is, and pinpoint it with a spiral search or drunkard's walk).

This algorithm is amenable to parallelization and, as long as the hypotheses hold, should be really fast.

All that said, it remains a hack -- I agree with unwind, why reinvent the wheel? If you have memory or CPU constraints (embedded systems, etc.), I believe there ought to be OpenCV and e-Vision "lite" ports also for ARM and embedded platforms.

(Sorry for my terminology - I'm monkey-translating from Italian. "Areal" is likely to correspond to your "blob", a beam is the family of lines joining all couples of points in two different blobs, line intensity being the product of distance from a point from its areal's center)

Upvotes: 2

Related Questions