Frames dropped due to contour out of bounds?

[carterw]

I'm finding that the motion detection algorithm has trouble detecting some white-colored vehicles. A few motion events are sometimes seen but not enough to reach the MO_TRACK_EVENT_COUNT number, and then the track is terminated as having timed out. I've added a little instrumentation here and there to try to investigate.

One thing I am seeing is that some camera images are being rejected in the get_biggest_contour() method. There is code which checks to see "if object contour is completely within crop area".
if x > x_buf and x + w < MO_CROP_X_RIGHT - MO_CROP_X_LEFT - x_buf:

Surprisingly, some contours are not and the image is therefore dropped. I realize the 'x_buf' number adds a fudge factor and it can be adjusted, but I don't understand how a contour "x" dimension can extend beyond the boundaries of the actual image. Can anyone explain?

More generally, why is this check necessary? What would be the effect if it were not performed? I am concerned that some legitimate motions may not be detected because the images are rejected.

[SamDecrock]

This function checks if the bounding box is within your self defined cropping area (configured with the MO_CROP_ variables). So increase your cropping area.

An explanation could be that the rectangle detected encompasses a piece of the background (because both the vehicle is white an so is your background?), thus reaching outside the cropping area and thus being dropped/ignored.

You can try lowering the MO_TRACK_EVENT_COUNT variable too.

[carterw]

The cropping area defines the image that gets evaluated to generate the bounding box. So how can the box be outside of that area?

I think part of the problem is that the motion detection algorithm always uses the X coordinate. Yes this will be the leading edge for vehicles going R2L, but in the L2R direction it is not the leading edge.