Skip to content
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

Merged
merged 1 commit into from
Aug 24, 2021

Conversation

davidplowman
Copy link
Collaborator

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]

@davidplowman
Copy link
Collaborator Author

@naushir

@davidplowman davidplowman force-pushed the motion-detect branch 2 times, most recently from de35bcd to 68ca57e Compare August 19, 2021 16:27
Copy link
Collaborator

@naushir naushir left a 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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/again/against/

Copy link
Collaborator Author

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.

Copy link
Collaborator

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?

Copy link
Collaborator Author

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!

Copy link
Collaborator

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...

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]>
@naushir naushir merged commit a6a9591 into raspberrypi:post-processing Aug 24, 2021
@davidplowman davidplowman deleted the motion-detect branch September 5, 2021 12:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants