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;...
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 ]++; } }
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.
Well, saving time is always a good thing, it saves ressources for everything else.
So I think A pix-step of 1 or 2 may be requiered to detect motion from fare away without zoom(10m)
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?
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.
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?
Started by ledelectronics Feature Requests
Started by Microfunguy General Discussion and Assistance
Started by v3as4k General Discussion and Assistance
Started by philmoz General Discussion and Assistance
Started by Herbie Script Writing
