FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups 
 ProfileProfile   PreferencesPreferences   Log in to check your private messagesLog in to check your private messages   Log inLog in 
Forum index » Electronix » design
Video Motion Detection
Post new topic   Reply to topic Page 2 of 2 [22 Posts] View previous topic :: View next topic
Goto page:  Previous  1, 2
Author Message
Luhan
electronics forum Guru


Joined: 10 Dec 2005
Posts: 365

PostPosted: Sun Jul 16, 2006 1:17 am    Post subject: Re: Video Motion Detection Reply with quote

Ken Smith wrote:
Quote:
In article <1152988446.349332.132950@m79g2000cwm.googlegroups.com>,
Luhan <luhanis@yahoo.com> wrote:

Ken Smith wrote:
[....]
If you reduce the number of values and the number of bits in each sample,
you reduce the odds of a change of one bit. If backlash is built into the
digitizer, a further reduction in the odds can be had.

The digitizer would have to remember the previous data at exactly that
location.

No, it would not.

I think you will agree that, if the digitizer was lets say 1 bit and the
backlash was greater than the video signal, the output would always be either
high or low depending on which way it started.

I think you would also agree that if the entire video frame was reduced to
a single pixel, a low resolution multibit digitizer would produce the same
result assuming the overall lighting did not change.

With some filtering before it, the one bit digitizer could be replaced
with a window comparitor. When you go to multiple pixels, the required
backlash circuit would become a majority logic circuit in the simple case.



If we are looking
for a change in the picture that is large enough, the CRC will work.

No, all of the CRC's I have seen react to single bit changes.

... and if the change in picture does not cause a change on the input to
the CRC, the CRC's output does not change. So all that is required is a
circuit that doesn't change the digital input if the picture doesn't have
some huge change in it.


The way I would attack doing it with a CRC (assuming I had to) would be to
do the following.

(1) Run the video signal into a "log(x)" circuit so that (roughly), the
same change in value always means that the brightness changed by the same
percentage. The bottom end of the curve will not be a true log function
so that we don't amplify the noise too much in very dark areas.

I prefer my one resistor and one capacitor.

To each his own, I guess but it sounds quite primative to me. With my
version, changes in overall brightness don't produce a changed output.


(2) Digitize with a, lets say, 12 bit ADC that is well synced to the
video. and feed that into a FPGA that does the following steps.

The PIC has 10 bits, using 12 contradicts your comment above about
reducing the number of bits. I use 8 bits for 'easy handling'.

This was about "using a CRC" so the details of the hardware doesn't matter
it is just getting it to involve a CRC that was the goal.


(3) Only clock samples through while we are in the scan area of the video
image.

Check the website, thats always done.

It still needs to be stated for the description to be complete.

The PIC has only about 100 memory locations.

Then don't use a PIC!


(6) Perhaps snip off the LSBs and decimate the data a bit to reduce the
need for the next bit of memory.


Conflicts with your #2.

How does that conflict. I sure don't see any way that it does.

amplitude compression. This mostly removes the effects of over all
dimming and brightening of the scene. Cutting out the high frequencies
removes much of the noise and jitter and rejects small objects such as
flies in the scene.

The bandpas filter in the column direction removes the variations in
brightness from left to right and again rejects small objects.

After the filtering, the signal, more or less, contains only information
about the locations of the objects in the scene plus some remaining noise.

If the backlash in step (Cool is much more than this noise, the Y=Old case
will happen every time unless something in the scene changes.

A CRC can easily be arranged so that it has its repeat values widely
spaced on the scene.


Build it and show us the design.

Why? Do you think it won't work or that it doesn't use a CRC?

Let us all know how it works. You
are going in the opposite direction from my design - better
recoginition with much greater complexity.

My design is a compromise on recognition with greatly reduced
complexity.

You may have some very good ideas here on an implementation using maybe
a PC to do the processing. This may have its uses depending on design
constraints.

No, like I suggested, an FPGA is the way to go. All of the logic will fit
into a not very large one. The memory pushes you up in size a bit but not
all that much these days. The amount of electronics to make the FPGA go
would not be much.
--
--
kensmith@rahul.net forging knowledge


I leave it for others to decide if what you say makes sense.

Luhan
Back to top
Mochuelo
electronics forum Guru Wannabe


Joined: 10 May 2005
Posts: 128

PostPosted: Sun Jul 16, 2006 10:25 am    Post subject: Re: Video Motion Detection Reply with quote

On 15 Jul 2006 11:34:06 -0700, "Luhan" <luhanis@yahoo.com> wrote:
Quote:
Ken Smith wrote:

(1) Run the video signal into a "log(x)" circuit so that (roughly), the
same change in value always means that the brightness changed by the same
percentage. The bottom end of the curve will not be a true log function
so that we don't amplify the noise too much in very dark areas.

I prefer my one resistor and one capacitor.

Your one resistor and one capacitor have nothing to do with this point
(1). They have to do with (5). They do a spatial low-pass filtering,
in the horizontal direction.

How do you filter vertically the image? How do you anti-alias in that
direction? You said you are taking 8x8 samples, but an NTSC frame has
480 viewable lines. 480/8=60. What do you do with the other 59 lines
per group? The fact that your ADC does not take two samples from the
same line does not change this reasoning. Vertically speaking, you are
only looking at 1.7% of the image, and ignoring the rest. You have
98.3% odds of not detecting a change, even if it is huge. In the case
of PAL, the situation is worse.

Quote:
(2) Digitize with a, lets say, 12 bit ADC that is well synced to the
video. and feed that into a FPGA that does the following steps.

The PIC has 10 bits, using 12 contradicts your comment above about
reducing the number of bits.

No, it doesn't contradict anything. His bit reduction was in (9).

Quote:
I use 8 bits for 'easy handling'.

Is 16-bit algebra with 8-bit words difficult for you, taking into
account that you don't even have to multiply or divide?

Quote:
(4) Implement a IIR bandpass filter in the column direction with about 3
memories.

(5) Using, lets say, 256*3 memory locations sellected according to the
column number, implement an IIR filter in the row direction.

The PIC has only about 100 memory locations.

No way. The PIC16F819 that you are using has 256 RAM bytes. You have
space for _four_ 64-byte frame buffers, in case you wanted to use
them. You were using 8-bit algebra, right?

Vertical spatial filtering is memory consuming but provides clear
benefits to any scheme that uses it --be it yours or one using CRCs.
The choice of including it is totally independent on the choice of the
change detection mechanism. Since we are trying to compare your scheme
with one using CRCs, the choice of including or not including vertical
spatial filtering has to be the same for both. Your scheme does not
use it, so disregard the complexity of this section.

Quote:
(6) Perhaps snip off the LSBs and decimate the data a bit to reduce the
need for the next bit of memory.

Conflicts with your #2.

??

Quote:
Build it and show us the design.

That sounds like an order.

Quote:
Let us all know how it works.

Regarding your scheme, you just said "it works." I've heard those two
words from so many people, meaning so many different things Smile, that
I don't know why I should believe you, especially after having seen
how easily you write strong statements --positive and negative.


By the way, strictly speaking, this thread is not about _motion_
detection. None of the ideas proposed here can tell whether something
that has been detected is just a change in luminosity, a movement, or
both. So, all this is just about _change_ detection. Motion detection
is much more complex.
Back to top
Luhan
electronics forum Guru


Joined: 10 Dec 2005
Posts: 365

PostPosted: Sun Jul 16, 2006 12:45 pm    Post subject: Re: Video Motion Detection Reply with quote

Quote:
No way. The PIC16F819 that you are using has 256 RAM bytes. You have
space for _four_ 64-byte frame buffers, in case you wanted to use
them. You were using 8-bit algebra, right?

Yea, but they are in memory banks. Resolving down to a single 8 bit
value has implications for units with more cameras, or doing various
time-dimention detection schemes, to say nothing about being just plain
nifty.

Quote:

Vertical spatial filtering is memory consuming but provides clear
benefits to any scheme that uses it --be it yours or one using CRCs.
The choice of including it is totally independent on the choice of the
change detection mechanism. Since we are trying to compare your scheme
with one using CRCs, the choice of including or not including vertical
spatial filtering has to be the same for both. Your scheme does not
use it, so disregard the complexity of this section

Build it and show us the design.

That sounds like an order.

Let us all know how it works.

Hot air is not currently in short supply here in Arizon Smile Sorry, I've
had just toooo much work experience with 'engineers' who talk a good
line, but fail at producing real, working designs. Also, the fact that
a 'better' scheme can be achieved using a lots more parts, more time,
and even totally different hardware is not suprising, but of little
interest to me in this application.

Quote:

Regarding your scheme, you just said "it works." I've heard those two
words from so many people, meaning so many different things Smile, that
I don't know why I should believe you, especially after having seen
how easily you write strong statements --positive and negative.

Well, it means it works for the desired application. In this case,
mine. So if it works good enough for me, thats it.
Quote:


By the way, strictly speaking, this thread is not about _motion_
detection. None of the ideas proposed here can tell whether something
that has been detected is just a change in luminosity, a movement, or
both. So, all this is just about _change_ detection. Motion detection
is much more complex.

The fact that it responds to luminosity is not relevent in my
application. False positives just happen to switch cameras, not a
problem. The unit does, however, seem to not miss objects moving into
the video frame.

Q.E.D.

Luhan
Back to top
Ken Smith
electronics forum Guru


Joined: 06 May 2005
Posts: 1727

PostPosted: Sun Jul 16, 2006 4:33 pm    Post subject: Re: Video Motion Detection Reply with quote

In article <k53kb2hvffv0vk01fj9vj5lgha1914bq7l@4ax.com>,
Mochuelo <cucafera@RE_MO_VE_THIStelefonica.net> wrote:
[....]
Quote:
Vertical spatial filtering is memory consuming but provides clear
benefits to any scheme that uses it

I think even a very crude spatial filter that doesn't use a lot of memory
for the vertical part would be helpful. A notch filter at the vertical
sweep rate and perhaps a harmonic or two would remove overall trends in
the frame. This would leave a few more bits for the stuff we care about.

Quote:
By the way, strictly speaking, this thread is not about _motion_
detection. None of the ideas proposed here can tell whether something
that has been detected is just a change in luminosity,

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.

--
--
kensmith@rahul.net forging knowledge
Back to top
Mochuelo
electronics forum Guru Wannabe


Joined: 10 May 2005
Posts: 128

PostPosted: Tue Jul 18, 2006 10:18 am    Post subject: Re: Video Motion Detection Reply with quote

On 16 Jul 2006 05:45:01 -0700, "Luhan" <luhanis@yahoo.com> wrote:

Quote:

No way. The PIC16F819 that you are using has 256 RAM bytes. You have
space for _four_ 64-byte frame buffers, in case you wanted to use
them. You were using 8-bit algebra, right?

Yea, but they are in memory banks.

This is one of those moments that I would like to have here, reading
us, some of those PIC-minded persons that say that PICs are as good as
other MCUs and that they don't give any problems. At least you just
admitted you are having problems.

Step by step. Let's not get lost.

Your MCU:
Microchip PIC16F819
----------------------------
1.95 GBP (qty 1) @ Farnell
4.03 USD (qty 1) @ DigiKey
3584 bytes flash
256 bytes RAM + 1 register.
Memory is divided in banks
No analog comparator
35 instructions
No hardware multiplier
ADC: 5 x 10-bit

A cheaper and better option:
Atmel ATmega48
----------------------------
1.40 GBP (qty 1) @ Farnell
2.58 USD (qty 1) @ DigiKey
4098 bytes flash
256 bytes RAM + 32 registers.
Linear memory map
With analog comparator
131 instructions
2-cycle hardware multiplier
ADC: 8 x 10-bit

See any difference?

The analog comparator in the ATmega would save you one external
comparator. The 131 vs. 35 instructions would mean shorter code, and
the capability to do more things. Dividing 256 bytes into banks is
something from the cave times. We are in 2006!


Quote:
Hot air is not currently in short supply here in Arizon Smile Sorry, I've
had just toooo much work experience with 'engineers' who talk a good
line, but fail at producing real, working designs.

You may have a loooong experience, but you just gave me a good example
of a real...ly suboptimal design.
Even a _32-bit_ ARM7 LPC2101 is cheaper (3.15 USD (qty 1) @ DigiKey)
than your PIC!

Quote:
Also, the fact that
a 'better' scheme can be achieved using a lots more parts, more time,
and even totally different hardware is not suprising, but of little
interest to me in this application.

Ok, let's forget about checker boards and CRCs. We don't need them, to
beat your scheme.

Take your hardware. Exactly as it is. Take your wonderful PIC. Let's
assume exactly the same 8x8 sampling matrix. Change your software to
do this:

Reserve 64 bytes of RAM for a frame buffer (you still spare 192 bytes.
The code you published needs much less than 192 bytes of RAM).

At the beginning of each frame:
- Reset flag_change.

For each pixel in your matrix:
- Read the 10-bit sample from the ADC.
- Use it to compute the average value of the current frame.
- Subtract from the sample the average value of the previous frame,
for which you have the exact value from the very first pixel. This way
you don't need a second frame buffer.
- Keep the 8 most significant bits (it was your choice to work with
8-bit algebra).
- Subtract from it the corresponding value in the frame buffer,
compute the absolute value, and compare with a threshold. If smaller,
do nothing. If larger, set flag_change, and update the frame buffer
with the 8-bit value.

At the end of each frame:
- Compare the average value of the current frame with the average
value of the previous frame. If the difference is larger, in absolute
value, than a certain threshold, reset flag_change.
- Check flag_change. If true, decide that there has been some change
in your image, and switch cameras. Otherwise, do not switch cameras
(unless a timer says it is time to do it).


No checker boards. No CRCs. This scheme detects many more cases of
change than yours, yet easily avoids noise. It does not miss neither
the diagonal movements that your scheme misses, nor many other
changes. It fits in your PIC, and the conceptual complexity is lower.

Now, change the PIC for the ATmega, and you'll save money and parts
(one comparator).

Paraphrasing your text, it turns out that "a better scheme can be
achieved using less parts, less conceptual complexity, and less
money."


H.L.C.
Back to top
Mochuelo
electronics forum Guru Wannabe


Joined: 10 May 2005
Posts: 128

PostPosted: Tue Jul 18, 2006 10:18 am    Post subject: Re: Video Motion Detection Reply with quote

On Sun, 16 Jul 2006 16:33:19 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) wrote:

Quote:
By the way, strictly speaking, this thread is not about _motion_
detection. None of the ideas proposed here can tell whether something
that has been detected is just a change in luminosity,

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.
Back to top
Ken Smith
electronics forum Guru


Joined: 06 May 2005
Posts: 1727

PostPosted: Fri Jul 21, 2006 1:39 am    Post subject: Re: Video Motion Detection Reply with quote

In article <mbdpb2de31dk4jpgfeejbcga5l88ttaqu4@4ax.com>,
Mochuelo <cucafera@RE_MO_VE_THIStelefonica.net> wrote:
Quote:
On Sun, 16 Jul 2006 16:33:19 +0000 (UTC), kensmith@green.rahul.net
(Ken Smith) wrote:

By the way, strictly speaking, this thread is not about _motion_
detection. None of the ideas proposed here can tell whether something
that has been detected is just a change in luminosity,

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.

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

--
--
kensmith@rahul.net forging knowledge
Back to top
Google

Back to top
Display posts from previous:   
Post new topic   Reply to topic Page 2 of 2 [22 Posts] Goto page:  Previous  1, 2
View previous topic :: View next topic
The time now is Tue Oct 23, 2018 2:48 am | All times are GMT
Forum index » Electronix » design
Jump to:  

Similar Topics
Topic Author Forum Replies Last Post
No new posts A/D for end of charge detection for NIMHs & NICADs Mike Basics 4 Wed Jul 19, 2006 8:51 pm
No new posts FA: Sony PVM-1220 Pro Video Color Monitor $1 tw@emailaccount.com Equipment 1 Wed Jul 19, 2006 6:03 pm
No new posts FA: Sony PVM-1220 Pro Video Color Monitor $1 tw@emailaccount.com Basics 1 Wed Jul 19, 2006 6:02 pm
No new posts Are you looking for high quality photo editing and video ... gwanglu@gmail.com design 2 Wed Jul 19, 2006 12:23 pm
No new posts GE TV model 31GT740, CTC203CA12 video problem captainvideo462002@yahoo. Repair 0 Tue Jul 11, 2006 2:49 am

Copyright © 2004-2005 DeniX Solutions SRL
Other DeniX Solutions sites: Unix/Linux blog |  Unix/Linux documentation |  Unix/Linux forums |  Medicine forum |  Science forum  |  Send and track newsletters


Powered by phpBB © 2001, 2005 phpBB Group