-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
post-processing: Add a motion_detect stage #68
post-processing: Add a motion_detect stage #68
Conversation
de35bcd
to
68ca57e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the small typo, it looks good!
*/ | ||
|
||
// A simple motion detector. It needs to be give a low resolution image and it | ||
// compares pixels in the current low res image again the value in the corresponding |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/again/against/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And s/give/given/ too!
// Because this gets run in parallel by the post-processing framework, it means | ||
// the "previous frame" is not totally guaranteed to be the actual previous one, | ||
// though in practice it is, and it doesn't actually matter even if it wasn't. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not something to do now, but I wonder if we should have a mode that ensures we use the "current" and "previous" frame only. Would that be useful?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it would be nice to guarantee that the "previous" frame really is the actual genuinely previous one. But we're at the mercy of the multiple threads, which thread tries to run first, who gets the mutex first... that kind of thing. So I'm not entirely sure what the best way is to do that. Perhaps run it before we split into several threads? Does that over-complicate the post-processing idea? Open to suggestions on this one!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need to think about how to do this a bit more. Given the postprocessing thread dispatch code ensures that we return results in order, I think we may be able to do some trickery with mutexes or other sync primitives...
68ca57e
to
617f4bf
Compare
The motion_detect stage looks for pixel differences in the low resolution image, which should normally be configured quite small, such as 128x96 pixels. Computation can be further reduced using the hskip and vskip parameters. If enough pixels have changed sufficiently, this counts as "motion". Signed-off-by: David Plowman <[email protected]>
617f4bf
to
0b81a92
Compare
The motion_detect stage looks for pixel differences in the low
resolution image, which should normally be configured quite small,
such as 128x96 pixels. If enough pixels have changed sufficiently,
this counts as "motion".
Signed-off-by: David Plowman [email protected]