There's more than one way to do things PerlMonks

### Re^2: Image Analysis

by fluffyvoidwarrior (Monk)
 on Oct 26, 2010 at 07:55 UTC ( #867415=note: print w/ replies, xml ) Need Help??

in reply to Re: Image Analysis

1. By how many pixels do things in successive images move?
The objects I want to detect - about 5%. The background slop - about 60%

2. Is the frame-rate consistent with the conveyor rate?
No

3. Is the movement linear in an ordinal direction? (Left to right or top to bottom.)
Mostly. The sludge is random and linear in the direction of flow. The objects have some limited random motion and travel fairly reliably in the direction of flow.

4. How good is the registration of successive images? (ie. is the camera rigidly fixed or wobbly?)
In theory good. In practice likely to wobble.

5. How long between frames and how much processing power is available to process the images?
Frames can be delivered as discrete jpegs at 5 per sec or as a digital cctv video stream. Processing power of an ordinary desktop PC.

Comment on Re^2: Image Analysis
Replies are listed 'Best First'.
Re^3: Image Analysis
by BrowserUk (Pope) on Oct 26, 2010 at 08:42 UTC

5% of what? (Ie. what size are the images? Also how many bits per pixel.

5% +/- how much?

2. Is the frame-rate consistent with the conveyor rate? No.

I think this may be the show stopper for what I was thinking about.

Processing power of an ordinary desktop PC

With or without a GPU and libraries?

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
5% of pixel area. Images are 6400x1200 RGB, 8bpp. The 5% is a total guess because it varies so much - could even be 20% on occasions but probably 5% minimum. GPU - probably not but maybe able to persuade for a good solution. Are you thinking strobe?
Are you thinking strobe?

No. It's well known that if you take two images taken from the same viewpoint but with minor scene changes (egthese two), and subtract them one from the other, if they are well registered, the you isolate the differences. Like this.

If you then convert that to greyscale and then stretch the contrast either side of some median value, and then eliminate noise, you get a clear B&W picture of the differences: so

A long time ago I discovered a twist on this. If there is (or you introduce) a slight offset in registration between two such images, then it acts as a very effective edge detector.

So, starting with these two images, which have such a slight regstration error, and you do the substraction, grayscaling contrasting and denoising.

That final image was the basis of the idea. If your snapshots could be so processed against a 'blank' base image of the same scene--this came before you mentioned the sludge--then you end up with an image suitable for edge detection and then a line discrimination algorithm like the Hough Transform.

Even with the rippling sludge, if your frame-rate and conveyor rates were synchronised, the it might be possible to re-register subsequent images sufficiently to allow the subtraction to eliminate the vast majority of the background (sludge) through averaging, thereby making any sharp-edged objects stand out. But with the variability of the procession rates, achieving close enough registration for the subtraction to be effective would be very difficult.

I realise that you said you've already managed to process the images with edge detection, and are only looking to be able to determine whether the image actually contains any hard lines. To that extent, the Hough Transform is the baby. But Hough is very processor intensive, as are most edge detection algorithms. The nice thing about the above algorithm is, although there are 4 passes, those passes are very fast and at least 3, if not all 4 can be combined into a single pass. That would have left more time for the Hough.

If you decide to look at the Hough, see if you can find the original 1962 version. It only looks for straight lines, where the later version look for ellipses as well, and hence are slower. In any case, if you're going to attempt this at 5 fps on 6400x1200 images, then you will certainly need to invest in some serious hardware. Very powerful GPUs are available for very reasonable prices now. The biggest problem will be finding libraries that uses them well, and either has the algorithms you need, or some well thought through primitives that allow you to construct your own. <P<Good luck.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
wow. Yes, thats good thought process. Even though probably not applicable I may be able to adapt bits. Will investigate.

Create A New User
Node Status?
node history
Node Type: note [id://867415]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (19)
As of 2015-11-24 22:18 GMT
Sections?
Information?
Find Nodes?
Leftovers?
Voting Booth?