Motion Detection too slow? - page 2 - Script Writing - CHDK Forum  
« previous next »
Pages: 1 [2] 3 4 5 6 7 ... 26   Go Down

Motion Detection too slow?

  • 253 Replies
  • 187993 Views
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #10 on: 30 / January / 2008, 06:40:45 »
Advertisements
Trying your script there is just no way I could catch flying toys! I just set it with the values you listed, along with a high shutter speed and high iso, manual focus, review and noise reduction turned off and everything and I still can't even catch my hand moving slowly let alone an object being thrown across a room. It is just too slow.

I did read about the idea of using the other data buffers to speed up the code and it's one of the things I was interested in modifying myself. But if this doesn't even work then it's not worth trying. I'm probably still doing something wrong but I have no idea what it is.

Edit:
I meant to say I don't think it's the detection code causing the problem since it works fast if a test script which just prints the number of cell changes is used.
« Last Edit: 30 / January / 2008, 06:56:06 by jonnythe »
Logged
*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #11 on: 30 / January / 2008, 07:52:58 »
I have switched off zebra and histogram
try to use 16 pixel step
NOTE: actually number of cells does not affect speed
using only half of screen will speedup calculation (I think it will be usefull for lightning  photography )


oh. I almost forgot
md have built-in performance test module

Code: [Select]
@title md benchmarks

@param a Columns
@default a 8

@param b Rows
@default b 6

@param c Threshold (0-255)
@default c 10

@param d compare Interval (millisecs)
@default d 0

@param g pix step(speed/accuracy adj)
@default g 8

@param h  reg mode(0-no,1-incl,2-excl)
@default h 2

@param e Top Rows
@default e 1


@param i 0-U,1-Y,2-V,3-R,4-G,5-B
@default i 1

@param f bench time (seconds)
@default f 120


let f=f*1000

md_detect_motion a, b, i,     f,  d, 0, 1, t, h, 1, 1,  a,   e,  10, g, f

end


this code will produce file in the root directory: MD_INFO.TXT
here is my file:

--- 2008-01-30  15:09:34
CHDK Ver: allbest [ #16 ]
Build Date: Dec 29 2007 14:18:21
Camera:  a630 [ 100c ]
[8x6], threshold: 0, interval: 0, pixels step: 8
region: [1,1-8,1], region type: 0
wait interval: 120000, parameters: 10, calls: 11809, detected cells: 0
  • - 52360
    • [1] - 52370
    [2] - 52380
    [3] - 52390
    [4] - 52400
    [5] - 52410
    [6] - 52420
    [7] - 52430
    [8] - 52440
    [9] - 52450
    [10] - 52460
    [11] - 52470
    [12] - 52480
    [13] - 52490
    [14] - 52500
    [15] - 52510
    [16] - 52520
    [17] - 52530
    [18] - 52540
    [19] - 52550
    [20] - 52560

[skipped]

explanation:
detected cells: 0 - does not matter
threshold - does not matter in benchmarking (oops. some more bug. i used 10. don't worry. it is error of log function)

pixels step: 8 - actually used not every 8th pixel but 8*8=64 (this step applyed to X and Y coordinates)
region type: 0 - full grid was used for calculation
wait interval: 120000 - 120 seconds where used for benchmarking ( 10 seconds enough really :-) )
parameters: 10 - it seems it is incorrect value  (sorry. some bug :-) )
calls: 11809 - that is count of comparisons have been made during benchmarking

as we can see every 10 mseconds md code did it's work without processor overloading
also following values are time in milliseconds
  • - 52360
    • [1] - 52370
    [2] - 52380

    time difference between calls ( CHDK code calls md routine when it can . it is every 10 miliseconds - normal variant)

    second try - more load on processor. using every pixel calculations (use 0)
    bench time - 30 secs

    hm. it slows down LCD dispay. lets see what we have in file (by the way. debug information is added to end of file. just scroll down)



    --- 2008-01-30  15:28:19
    CHDK Ver: allbest [ #16 ]
    Build Date: Dec 29 2007 14:18:21
    Camera:  a630 [ 100c ]
    [8x6], threshold: 0, interval: 0, pixels step: 1
    region: [1,1-8,1], region type: 0
    wait interval: 30000, parameters: 10, calls: 341, detected cells: 0
  • - 212370
    • [1] - 212480
    [2] - 212570
    [3] - 212660
    [4] - 212750
    [5] - 212840
    [6] - 212930
    [7] - 213020
    [8] - 213110
    [9] - 213200

    surpise. md detection slow down all chdk
    lets see
    30 seconds
    341 calls
    so it takes 80-90 milliseconds to make comparisons using every pixel

    so.
    how to use it properly then?
    use every 100th pixel?

    anyway using so short times between comparisons takes processor time from CHDK
    also I have noticed that it is useless to use compare time less then 30 - LCD update speed
    also CHDK uses only one of three available buffers

    there is a 30% chance that we will be in time to avoid 60 msecs loose (so use 30 msecs is logical)
    of course chances will be 100% after aplying patch to use all three buffers


    lets test 30msec + every 4th pixel
    1) it will speed up calculation to 16 times ( 4 step for X and Y coordinates)
    2) will not waste processor time unnecesary

    what we got?
    LCD is more live ( but not fast enough for me :-( )
    lets see debug info file

    --- 2008-01-30  15:47:15
    CHDK Ver: allbest [ #16 ]
    Build Date: Dec 29 2007 14:18:21
    Camera:  a630 [ 100c ]
    [8x6], threshold: 0, interval: 30, pixels step: 4
    region: [1,1-8,1], region type: 0
    wait interval: 30000, parameters: 10, calls: 2910, detected cells: 0
  • - 176590
    • [1] - 176610
    [2] - 176620
    [3] - 176630
    [4] - 176640
    [5] - 176650
    [6] - 176660
    [7] - 176670
    [8] - 176680
    [9] - 176690
    [10] - 176700
    [11] - 176710

    30 secs/ 2910 calls = 10 msecs

    ok. it seems it is almost safe to use pixel step 4 for my camera. in this case md code dont take away processor time from CHDK and calculates data in realtime

    so if modification applyed to main trunk (to your camera) it is possible using 4pixels step to catch changes in 30 msecs interval.

    waiting your debuging file


Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #12 on: 30 / January / 2008, 16:45:14 »
Thanks for that mx3. I'll work through it later.

BTW, with Allbest's newest build (ver 16) something is making the "save RAW" option enable. I don't touch it but notice it's been switched on  occasionally. Strange.
Logged
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #13 on: 30 / January / 2008, 17:02:43 »
Here's my debug file, and it shows the motion detection code is working properly. The problem is the camera taking too long to initiate a shot. In other words, although I can detect motion fine, the camera is too slow to capture the change.

Doesn't the A630 have the same processor speed as the A610? Then I really can't understand why I can't get it to work. I played for several hours last night trying this and trying that and it just makes no difference.
Logged
*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #14 on: 30 / January / 2008, 22:22:45 »
maybe new features with overrides have broken something
try old version (see attached file)
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline PhyrePhoX

  • *****
  • 2254
  • make RAW not WAR
    • PhyreWorX
Re: Motion Detection too slow?
« Reply #15 on: 31 / January / 2008, 04:00:54 »
Quote from: jonnythe on 30 / January / 2008, 16:45:14
BTW, with Allbest's newest build (ver 16) something is making the "save RAW" option enable. I don't touch it but notice it's been switched on  occasionally. Strange.
there is a keyboard shortcut you can enable/disable raw with, maybe you pressed that by accident.
see http://chdk.wikia.com/wiki/CHDK_firmware_usage#RAW_parameters_menu
Logged
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #16 on: 31 / January / 2008, 06:00:53 »
Yes you're correct. I realized about the raw shortcut today.

As for the motion detection, I've written a windows program to test it. It emulates a lightning strike including the leader by flashing the computer screen, and allows me to change the time between the leader and main strike etc. So I will be able to see how fast my A610 will actually work. I will try it tomorrow and post back the results.

Thanks for the help everyone.
Logged
*

Offline mx3

  • ****
  • 372
Re: Motion Detection too slow?
« Reply #17 on: 31 / January / 2008, 13:15:13 »
my monitor type is of electron beam so I think your program have no use for me...

can you share such program ?
Logged
skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #18 on: 01 / February / 2008, 02:46:12 »
mx3, I also have a crt monitor but I don't think it matters in this case. My program isn't meant to get millisecond accuracy or anything. It's to show my A610 just doesn't have what it takes to capture lightning with the motion detection function - unless I'm doing something wrong.

The following image is what was captured from one test. In this example each bar is 20 ms of time. The program moves the white bar from left to right approximately every 20ms:

It's hard to see in this resized image, but there are about 25 bright bars which equates to the 25*20ms=500ms shutter time I used. But if you count the dark bars before then, there are about 34 of them. This equates to around 680ms. The timing is taken from the beginning of the "trigger" flash and the trigger lasted 20 milliseconds. In other words my camera began the capture approximately 680ms after the initial trigger. And ended after another 500ms which it should since that's the shutter speed I chose. I have tried other tests and it always takes similar amount of time to open the shutter. I don't know if it's something I'm doing wrong.

Is this program useful to anyone? That's horrible barrel distortion isn't it?  :blink:
Logged
*

Offline jonnythe

  • **
  • 93
Re: Motion Detection too slow?
« Reply #19 on: 01 / February / 2008, 03:06:32 »
Here is the program. It's a bit cheesy but it has helped me.

"Trigger interval" is the interval between consecutive triggering.
"Trigger flash time" is how many ms to flash the trigger on screen (maybe useful but not sure :) )
"Timing step" is the number of milliseconds for each bar drawn.

The program is hard coded to take 2 seconds from left to right but that should be enough for testing.
It may not work on everyones pc, but I did code it in a vmware machine and it works fine in that and on my host dual core system. And the lines and bars don't usually line up perfectly since the bar location is calculated just before drawing, whereas the grid is computed once and is just a guide.
Logged
Pages: 1 [2] 3 4 5 6 7 ... 26   Go Up
« previous next »
 

Related Topics