Cannot modify chkd "core": (motion_detector.c & script.c) - page 2 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 [2]   Go Down

Cannot modify chkd "core": (motion_detector.c & script.c)

  • 16 Replies
  • 10001 Views
*

Offline Syl20.mm

  • *
  • 20
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #10 on: 05 / June / 2011, 06:07:47 »
Advertisements
OK I finally got the test I wanted to do at the beginning of time:
I noticed that in the Motiondetect function there was a "switch" within loops
Code: [Select]
switch(motion_detector->pixel_measure_mode){
default:
case MD_MEASURE_MODE_Y:
val = img[(y+x)*3 + 1]; //Y
break;
case MD_MEASURE_MODE_U:
val = img[(y+(x&0xFFFFFFFE))*3]; //U
break;
...
witch is time consuming. So I tested a motion detection scripts with a "Pix-Step(speed/accuracy)" to 1 to test most time consuming scenario. The script is attached to this post.
I printed the time before and after the loops (get_tick_count). And loops took 120ms.
Then I remove the switch  and let only one case :
Code: [Select]
for(y=row*y_step*vp_w; y<y_end; y+=motion_detector->pixels_step*vp_w){
for(x=col*x_step; x<x_end; x+=motion_detector->pixels_step){

// ARRAY of UYVYYY values
// 6 bytes - 4 pixels
val = img[(y+x)*3 + 1]; //Y

motion_detector->curr[ idx ] += val;
motion_detector->points[ idx ]++;
}
}And loops took only 90ms. So I am sure we will have the same benefit by putting the switch outside all loops.
I will Put the modified source file. There is a Flag in it to set the Benchmarking features: #define OPT_MD_BENCHMARK 1.
It is a small enhancement (25% time less) for just a part of the Motion detection process, but still worth something.
I noticed some crash after some time when benchmarking, I assume it is du to conflic in writing the log file and the photo.
« Last Edit: 05 / June / 2011, 07:15:03 by Syl20.mm »
Logged
S95 100h
*

Offline reyalp

  • ******
  • 14138
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #11 on: 05 / June / 2011, 17:44:00 »
Good test.

tick count only has 10ms precision, so you should do several measurements to verify that your results.

Is pix step 1 actually useful ? Optimizing for this case is not worthwhile unless you actually need it. I'm having trouble imagining a scenario where you'd need it, but I'm open to suggestions.

Keep in mind that if your port does not have vid_get_viewport_live_fb implemented correctly (many don't), this is all pointless, since you will be looking at an old buffer most of the time. Even with vid_get_viewport_live_fb, detection speed is ultimately limited by the refresh rate of the live view (not sure what that is but I'd guess ~30fps at most)

Copy/pasting all the loops is not something I'd put in the trunk without a very compelling reason, it's not worth the bloat and maintenance hassle otherwise. There should be better ways to do this. The loops could be optimized quite a bit, Examining the disassembly (see core/main.dump) of this function may provide useful clues. Moving this to ARM code (instead of thumb) might provide a decent speed gain since there are more registers available and those loops are pretty complex.
Logged
Don't forget what the H stands for.
*

Offline Syl20.mm

  • *
  • 20
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #12 on: 06 / June / 2011, 02:44:40 »
Quote from: reyalp on 05 / June / 2011, 17:44:00
Good test.

tick count only has 10ms precision, so you should do several measurements to verify that your results.
Id did ~10times the test, and yes the time differences between tests were ~10ms.

Quote from: reyalp on 05 / June / 2011, 17:44:00
Is pix step 1 actually useful ? Optimizing for this case is not worthwhile unless you actually need it. I'm having trouble imagining a scenario where you'd need it, but I'm open to suggestions.
Good point, I don't know the size of the view port (screen resolution ?) , but if it is small, it could be useful to set the pix step to 1.

Quote from: reyalp on 05 / June / 2011, 17:44:00
Keep in mind that if your port does not have vid_get_viewport_live_fb implemented correctly (many don't), this is all pointless, since you will be looking at an old buffer most of the time. Even with vid_get_viewport_live_fb, detection speed is ultimately limited by the refresh rate of the live view (not sure what that is but I'd guess ~30fps at most)
Well, saving time is always a good thing, it saves ressources for everything else.

Quote from: reyalp on 05 / June / 2011, 17:44:00
Copy/pasting all the loops is not something I'd put in the trunk without a very compelling reason, it's not worth the bloat and maintenance hassle otherwise. There should be better ways to do this. The loops could be optimized quite a bit, Examining the disassembly (see core/main.dump) of this function may provide useful clues. Moving this to ARM code (instead of thumb) might provide a decent speed gain since there are more registers available and those loops are pretty complex.
Yes I agree, there should be a nicer way to deal with this. but I'm not familiar with ARM code and disassembly, so I will stick to the C code.
Logged
S95 100h
*

Offline Syl20.mm

  • *
  • 20
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #13 on: 06 / June / 2011, 14:56:06 »
I tested it , on the POWERShot S95 the Viewport Size is  240x720
So I think A pix-step of 1 or 2 may be requiered to detect motion from fare away without zoom(10m)

Quote from: reyalp on 05 / June / 2011, 17:44:00
Keep in mind that if your port does not have vid_get_viewport_live_fb implemented correctly (many don't), this is all pointless, since you will be looking at an old buffer most of the time. Even with vid_get_viewport_live_fb, detection speed is ultimately limited by the refresh rate of the live view (not sure what that is but I'd guess ~30fps at most)

Ok I had a look and you are right "vid_get_viewport_live_fb" is not implemented at all so it uses "vid_get_viewport_fb".

If I Understood correctly:
  *  "vid_get_viewport_live_fb" should get the adress of the picture update in "real time" (not sure what would be the frequence
  *  "vid_get_viewport_fb" get the adress of the picture update in less "real time"

Basicaly, the finction "vid_get_viewport_live_fb" is "just" returning the adress of a buffer. Is there somewhere a kind of method or procedure to identify the address?
« Last Edit: 06 / June / 2011, 15:06:54 by Syl20.mm »
Logged
S95 100h
*

Offline reyalp

  • ******
  • 14138
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #14 on: 06 / June / 2011, 16:01:12 »
Quote from: Syl20.mm on 06 / June / 2011, 02:44:40
Well, saving time is always a good thing, it saves ressources for everything else.
No, it's only a benefit if you actually have a use for those resources. If the camera would be idle in that time, then it does matter. Also, your solution isn't without cost.
Quote
So I think A pix-step of 1 or 2 may be requiered to detect motion from fare away without zoom(10m)
Maybe, but I doubt you will have good results detecting changes this small anyway. Without an actual test case this is just speculation.
Quote
Basicaly, the finction "vid_get_viewport_live_fb" is "just" returning the adress of a buffer. Is there somewhere a kind of method or procedure to identify the address?
It uses a canon variable to return the most recent buffer. The other function just returns one fixed address, which may be several frames old.

Look at existing ports that return a non-zero value for this. Some examples: d10, sx30,
Logged
Don't forget what the H stands for.
*

Offline Syl20.mm

  • *
  • 20
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #15 on: 07 / June / 2011, 12:12:31 »
Quote from: reyalp on 06 / June / 2011, 16:01:12
No, it's only a benefit if you actually have a use for those resources. If the camera would be idle in that time, then it does matter. Also, your solution isn't without cost.

Ok I did not meant that my solution MUST be implemented in the trunk, just that there are optimisations available.

Quote from: reyalp on 06 / June / 2011, 16:01:12
It uses a canon variable to return the most recent buffer. The other function just returns one fixed address, which may be several frames old.
Look at existing ports that return a non-zero value for this. Some examples: d10, sx30,

This means that there are several buffers available and this variable is continuously changing to adress the most recent one (current one?)

Is there a methode besides analysing memory dumps, to identify this variable?





« Last Edit: 07 / June / 2011, 12:30:18 by Syl20.mm »
Logged
S95 100h
*

Offline reyalp

  • ******
  • 14138
Re: Cannot modify chkd "core": (motion_detector.c & script.c)
« Reply #16 on: 07 / June / 2011, 17:19:25 »
Quote from: Syl20.mm on 07 / June / 2011, 12:12:31
This means that there are several buffers available and this variable is continuously changing to adress the most recent one (current one?)
Yes, the live view is usually (always ?) triple buffered.
Quote
Is there a methode besides analysing memory dumps, to identify this variable?
The usual way is to find it in disassembly.
1) Find where the variable is used in a known camera,
2) Find some kind of landmark (a string, constant, reference to some other identifiable value, called or calling functions)
3) Find the equivalent in the disassembly of your camera and identify the corresponding variable.

On some ports, #1 and sometimes #2 is recorded in a comment on vid_get_viewport_live_fb

Once you done that and found a likely candidate, you can watch it in misc debug values, and it alternate between the original vid_get_viewport_fb value and two similar values. That will show you that you probably have the right variable. You should then verify you are using the right index to get the most recent buffer, which can be done by testing MD response speed.
Logged
Don't forget what the H stands for.
Pages: 1 [2]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal