Motion Detection too slow? - page 11 - Script Writing - CHDK Forum
« previous next »
Pages: 1 ... 6 7 8 9 10 [11] 12 13 14 15 16 ... 26   Go Down

Motion Detection too slow?

  • 253 Replies
  • 200253 Views
*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #100 on: 06 / February / 2008, 06:20:50 »
Advertisements
Quote from: anonymous on 06 / February / 2008, 06:09:11
Tested the framebuffer mod on an IXUS70/SD1000 1.01a, using 1.01b from trunk-r285.
It gives consistent results, but they are not faster, more to the slower end of the spectrum.
...
there is an error in motion_detector.c,

great work.
I did not even thought about checking zoom :-)

as for (half press) another buffer: I'm not sure. lightning9 works fine
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #101 on: 06 / February / 2008, 06:32:23 »
Quote from: mx3 on 06 / February / 2008, 05:46:32
why do you mention initial delay?
we are speaking about decreasing interval between detection and shoot.
do we?
My customesed version supposed to decrease this time but not initial delay
Because your changes made no detectable differences for me. I was saying the biggest changes come from the different scripts. Why does putting an extra "shoot_full" command or changing it's position allow me to use a smaller shoot delay?

After editing the source it seems to be very finicky about how much delay is needed between shooting. After removing the flash waiting/histo procedures etc it sometimes works and sometimes locks up. Once again this does not make sense to me since I can run a simple script that just loops through a "shoot_full" command and it will run as fast as possible until the card is full. Tomorrow I will try to track down this "shoot_full" command and see what it actually does.

Another thing, people keep saying the camera goes into a continuous shooting if the delay isn't long enough to allow the evf to settle down. Well can't something be added to the beginning of the MD code to wait for it?
Logged
*

Offline anonymous

  • *
  • 11
Re: Motion Detection too slow?
« Reply #102 on: 06 / February / 2008, 08:23:32 »
Two issues.

The buffer size is incorrectly computed in my previous post.
The viewport buffer is 720x240(230), with 6 bytes (UYVYYY) for 4 pixels.
So the table should read

zf   mem_size  widthxheight
1.0  ox3CA50   720x230
3.0     3CA50   720x230
3.6     336A8   600x234
4.5     28DE8   465x240
5.8     1FE78    363x240
7.2     1A1A8    297x240
9.0     144D8    240x231 or 231x240
12.       F8E8    180x236 or 177x240

computed in such a way that the height is between 230 and 240, the numbers
are integer, and all add up, data not checked further.

In the motion_detector.c code only the 1st 3 bytes of the 6 bytes are used,
essentially it uses only 1 of the 4 available Y data bytes, so that's why it is
stepping from 1 to 360

Second, to avoid (some of) the trigger delay in the MD script use the following

x=30000
press "shoot_half"
while 1
 t=0
 md_detect_motion a, b, i, x, d, c, 1, t, h, 1, 1, a, f, 0, g, e
 if t then click "shoot_full"
 do
   get_prop 206 p
 until p<>1
 if t then press "shoot_half"
wend
end

with 206 replaced by 205 for digiII like camera's
(is there a test for the type op propcase used in a camera?).

Then set trigger delay to e=1 (i.e., .1 s), in low light you need more.
Addiing extra lines directly after the shoot_full is no problem,
picture taking will take at least .4 sec, so you can execute 40 lines
of ubasic code before returning to the md_detect_motion command.
You can also time your loop by sprinkling
print get_tick_count
lines in your code, to convince yourself.
Logged
*

Offline Barney Fife

  • *****
  • 1157
    • Gay Outdoorsmen
Re: Motion Detection too slow?
« Reply #103 on: 06 / February / 2008, 12:35:55 »
Deleted
« Last Edit: 22 / April / 2008, 10:26:53 by Barney Fife »
Logged
[acseven/admin commented out: please refrain from more direct offensive language to any user. FW complaints to me] I felt it imperative to withdraw my TOTAL participation. Nobody has my permission, nor the right, to reinstate MY posts. Make-do with my quoted text in others' replies only. Bye
*

Offline anonymous

  • *
  • 11
Re: Motion Detection too slow?
« Reply #104 on: 06 / February / 2008, 13:02:05 »
Quote from: Barney Fife on 06 / February / 2008, 12:35:55
Interesting, but it didn't work on my S3. :(

Like all other scripts, if the trigger delay is very small, then I get 90ms motion to shutter delay, but a non-stop cycling after the first time it is triggered. But using your script ideas didn't stop me from having to use trigger delays of 1.5 seconds or more to stop cycling (as with all other scripts, although one of them lets me get by with 1.2 seconds trigger delay). The other problem with it is in when (what I call the musical-chairs analogy) the motion is detected depending on what part of the script loop is occuring at the time of the motion.

while 1 = +10ms
 t=0 = +10ms
 md_detect_motion a, b, i, x, d, c, 1, t, h, 1, 1, a, f, 0, g, e = +10ms
 if t then click "shoot_full" = +10ms
 do = +10ms MOTION TRIGGER HAPPENS HERE (worse-case scenario)
   get_prop 206 p = +10ms
 until p<>1 = +10ms
 if t then press "shoot_half" = +10ms
wend = +10ms

So, if the motion happens at the green-text line, then we have 10+10+10+10+10+10+10+10 = 80ms lines of code that have to pass by before the md_detect_motion line can make use of any motion going on. (8 chairs away after the signal to sit on the shoot-command chair.) That detect to shoot loop has to be as tight as possible. Only jumping out of it after a shoot to reset things and wait for EVF settle-down. Then enter the tight "detect then shoot" loop that has to cycle fast.



For an S3 you have to use 205, not 206.

To avoid being outside the MD function, just use a much larger value for x,
then your worst case scenario cannot happen.

The only important timing is from the detection of motion to the shoot_full.
The trigger delay is not relevant for that, and the 80ms you mention are very short
compared to your 1.9s trigger delay. Remember that during the trigger delay
the MD function does not detect motion, so for this period it is blind!
Logged
*

Offline Barney Fife

  • *****
  • 1157
    • Gay Outdoorsmen
Re: Motion Detection too slow?
« Reply #105 on: 06 / February / 2008, 13:23:07 »
Deleted
« Last Edit: 22 / April / 2008, 10:27:22 by Barney Fife »
Logged
[acseven/admin commented out: please refrain from more direct offensive language to any user. FW complaints to me] I felt it imperative to withdraw my TOTAL participation. Nobody has my permission, nor the right, to reinstate MY posts. Make-do with my quoted text in others' replies only. Bye
*

Offline Barney Fife

  • *****
  • 1157
    • Gay Outdoorsmen
Re: Motion Detection too slow?
« Reply #106 on: 06 / February / 2008, 14:18:29 »
Deleted
« Last Edit: 22 / April / 2008, 10:27:39 by Barney Fife »
Logged
[acseven/admin commented out: please refrain from more direct offensive language to any user. FW complaints to me] I felt it imperative to withdraw my TOTAL participation. Nobody has my permission, nor the right, to reinstate MY posts. Make-do with my quoted text in others' replies only. Bye
*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #107 on: 06 / February / 2008, 14:22:16 »
Quote from: Barney Fife on 06 / February / 2008, 14:18:29
Apparently I don't fully understand how this md_detect_motion command is working.

Does the program sit on that line waiting to detect motion and THEN it goes on to the rest of the routines?


it works as sleep command.
sleep blocks execution of commands until timeout
the same with md_detect_motion
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline Barney Fife

  • *****
  • 1157
    • Gay Outdoorsmen
Re: Motion Detection too slow?
« Reply #108 on: 06 / February / 2008, 14:55:00 »
Deleted
« Last Edit: 22 / April / 2008, 10:28:02 by Barney Fife »
Logged
[acseven/admin commented out: please refrain from more direct offensive language to any user. FW complaints to me] I felt it imperative to withdraw my TOTAL participation. Nobody has my permission, nor the right, to reinstate MY posts. Make-do with my quoted text in others' replies only. Bye
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Motion Detection too slow?
« Reply #109 on: 06 / February / 2008, 16:06:53 »
Quote from: Barney Fife on 06 / February / 2008, 14:55:00
The whole line acts as a sleep command? It sits there sleeping for the duration of the timeout setting?

Or does it sleep on that line during the timeout setting, and then if it detects motion it stops sleeping no matter what the timeout setting is?

Your lightning scripts have x=30000 milliseconds and pass it as fourth argument ("timeout") of the md_detect_motion command. When the interpreter executes the the md_detect_motion command, it will stay there just as long as a 30 second sleep command would stay, unless motion is detected. Increase x and you'll be detecting motion a higher percentage of time.

This is a part from your MD Lightning6 script:
Code: [Select]
press "shoot_half"
t=0
do
md_detect_motion a, b, i, x, d, c, 1, t, h, 1, 1, a, f, 0, g, e
until t>0
click "shoot_full"

If motion is detected or the timeout is exceeded, the script proceeds with the next command. If motion was detected, t>0 and we will shoot. If it was a timeout, t will not be >0 and we go back into detecting motion very quickly.

I really don't know what trigger delay is, and whether it is in effect even when the md timeouted. I think it isn't (and thus the loop above is detecting motion at a very high percentage of about 99.999% or something), but haven't tried to experimenting with this nor looked at the source code for this.

It would make sense to me to have the MD code use infinite timeout if the timeout argument == 0. I don't know if this is the case, couldn't find it in the documentation and haven't looked at the source.
Logged
Pages: 1 ... 6 7 8 9 10 [11] 12 13 14 15 16 ... 26   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal