Video Motion Detection

[Mochuelo]

The compression in my method removes an overall change in luminosity. By
taking the log() and then high passing, you remove the effect of
multiplying the input by a constant.

I meant a local change in luminosity.


The output is just one bit. These methods detect changes, movements
and combinations of both. One bit does not give enough information to
be able to distinguish.

 

[Ken Smith]

I meant a local change in luminosity.

Yes. if some spot brightens, that will be considered a change. However,
given uniform lighting, that doesn't sound like a big problem.

 

[joseph2k]

Yikes! A CRC will not work at all. There is no way to set a
'threshhold' level for detecting significant changes vs random
variations.

[...]

CRC's cannot be used. They respond wildly to even a singe bit change.
Since there is always some variation in the video data, the CRC would
change with every video frame regardless of whether motion was present.

What do you mean by "will not work at all," "there is no way" and
"cannot be used"? You mean:

a) Nobody can come up with a way to use CRCs in this application, and
end up with better performance than with your proposed scheme.
b) You can't.

a or b?

I would say b. CRC typically outputs multibit differences for 1 bit
disturbances in the input field.

 

[Ken Smith]

I would say b. CRC typically outputs multibit differences for 1 bit
disturbances in the input field.

The trick is to make sure the CRC gets the same string of bits each time
unless something moved. The trouble is coming up with a way to ensure
that.

 

[Mochuelo]

Yikes! A CRC will not work at all. There is no way to set a
'threshhold' level for detecting significant changes vs random
variations.

[...]

CRC's cannot be used. They respond wildly to even a singe bit change.
Since there is always some variation in the video data, the CRC would
change with every video frame regardless of whether motion was present.

What do you mean by "will not work at all," "there is no way" and
"cannot be used"? You mean:

a) Nobody can come up with a way to use CRCs in this application, and
end up with better performance than with your proposed scheme.
b) You can't.

a or b?

I would say b. CRC typically outputs multibit differences for 1 bit
disturbances in the input field.

The same threshold Luhan proposed to use after his sums can be used
before the CRC. So, yes, "b."

Best part is we need neither sums nor CRCs. See my other post.