highlight objects when detected about dvr-scan HOT 11 CLOSED

It seems cv2.findContours, which you mentioned, plus cv2.boundingRect and cv2.rectangle, could help, as per this tutorial

from dvr-scan.

I did a quick test with this and it seems feasible, the only issue is that the box can jump around quite a bit (especially if the motion suddenly stops and starts again), so will need to figure out some kind of smoothing.

Here's a sample to demonstrate the output:

This can definitely be improved in v2.0 when the output path is separate from the input path, but I think as is it is probably good enough for now. Some things I still need to also look at:

• Investigate if a sliding window helps make it more smoother without much loss of accuracy (make the window size based on the effective framerate)
• Add a minimum width/height for the box (see end of above clip), say 5% of the video frame

from dvr-scan.

This is now in DVR-Scan v1.4, check out the -bb/--bounding-box option. It takes an optional amount to smooth the box over time, with the default being 0.1 seconds. Feedback is most welcome! :)

from dvr-scan.

I also seem to have missed the line to actually set frame skip in the bounding box code, sorry about that. It was compensated for, just never updated - thus in v1.4 the smoothing amount is still relative to the original framerate. A fix will be included in v1.4.1.

Thank you!

from dvr-scan.

Hi @hlbahy;

That's a pretty good idea - I'll have to look to see if OpenCV might provide any kind of help for blob detection (with a user-definable threshold) and see if this is feasible or not.

Thank you for the request!

from dvr-scan.

@hlbahy sry if this point is now moot, but VideoLAN's VLC viewer has a feature that may give you a partial work around while viewing the file.

Look in VLC's menu Tools | Adjustments | Video | Advanced "Motion Detect"

This will draw boxes around motion in real-time using VLC's own algorithm.

VLC does not know anything abotu dvr-scan, so it cannot indicate which motion triggered dvr-scan's threshold, nor does it know dvr-scan's region of interest, but can help the human viewing the video clip later.

from dvr-scan.

It seems like the findContours function provided by OpenCV would be useful for this, for example in this gist (source):

https://gist.github.com/creotiv/cf6979d7cb4ae7f78200cc815b9ef38d#file-detect_vehicles-py

im, contours, hierarchy = cv2.findContours(
    fg_mask, cv2.RETR_EXTERNAL, cv2.CHAIN_APPROX_TC89_L1)
# Loop through all contours.

from dvr-scan.

So the bounding boxes in v1.4 do generally work: The CLI switches work, the option is basically compatible with the other options, and a bounding box is shown for most events.

But after all, it’s only working correctly sometimes:

• Sometimes the bounding box appears too late (by several seconds), which is either obvious from looking at the video, or from the --time-before-event value (which tells us when we should expect a first bounding box). In both cases, it can be seen that there is earlier motion that is not marked at all (zero bounding boxes), sometimes even quite obvious motion.
• Sometimes the bounding boxes are only partial, e.g. from a rough visual interpretation, only 50% of what you would classify as motion is marked by a box. For example, only some motion in the background (where shades/brightness probably change) is marked, while not marking a moving object in the foreground.
• Finally, the bounding boxes seem to be heavily affected by the --frame-skip parameter (e.g. values of 0 (default) vs 2). I think to a certain degree this is expected, because if you drop frames, the motion you would mark changes. But it’s much more significant than that: The whole nature of the boxes changes, i.e. the size, the position, how fast they disappear. Could this be due to the 0.1 seconds smoothing, which is perhaps not adjusted to --frame-skip values?

from dvr-scan.

Thank you for the feedback, I'll do some more investigation into this. Of course there won't be any bounding boxes during --time-before-event, but after a review, those frames covered by --min-event-length will be missing a bounding box. which is definitely a bug. Are you increasing that parameter by any chance?

Also regarding frame skip, the smoothing amount should take that into account already. It's also possible that the size/position isn't consistent since with more frame skipping, the actual motion masks between frames will differ (may be larger). I want to look into adding a new command line argument to allow exporting videos of strictly the resulting motion mask, which will make debugging issues like this easier. Essentially, then you could determine what DVR-Scan is seeing internally, which would also greatly help with tweaking various detection options (and allow people to visually see what the effect of changing kernel size, for example) affect the source material during processing.

from dvr-scan.

Of course there won't be any bounding boxes during --time-before-event

Sure, this is not something I expected or tried to see in tests.

those frames covered by --min-event-length will be missing a bounding box. which is definitely a bug. Are you increasing that parameter by any chance?

My understanding was that --min-event-length does not extend or modify events in any case, unlike --time-before-event and --time-post-event, but that it may just cause some events to be dropped (which don’t fulfill the requirements).

Based on that understanding, and given that I’m not interested in, say, 7-frame-long events at 30 FPS, I have been using a non-default value for --min-event-length in all tests, yes. Something around 1 or 1.5 seconds.

Regarding --frame-skip, that problem would, of course, be gone with #82 .

from dvr-scan.

Based on that understanding, and given that I’m not interested in, say, 7-frame-long events at 30 FPS, I have been using a non-default value for --min-event-length in all tests, yes. Something around 1 or 1.5 seconds.

That makes sense - unfortunately in v1.4 those frames as part of --min-event-length do not have a bounding box drawn on them. That should be fixed in v1.5.

Thank you for letting me know, will update the known issues to reflect this.

from dvr-scan.