I implemented the same thing for SX60HS. Thank you reyalp for finding this information. Interestingly, the buffer addresses are the same as on g7x. The address list begins at 0xfc5cf054 on 100f, and at 0xfc5cf040 on 100b . The location of the pointer was found at 0x8810, using rmem. I'm assuming this will be the same on 100b.
How does this compare to pre Digic 6?
I did check it. Between 40-100 msec. Average 50. So much improved. Might be able to get a little better with careful choice of parameters. Don't know how much is cpu busy cycles and how much is latency. How does this compare to pre Digic 6?
However in g7x I think you have 16 additional pixels which are not displayed, and these are included in the trigger sampling /summation for now. Maybe these bytes have some extra things going on?
Those extra (junk) pixels are usually different in each buffer. If they are not ignored by the MD routine, they can easily cause MD trigger if vid_get_viewport_live_fb() is correctly implemented (as on the g7x).
camera_screen.width = 720; camera_screen.physical_width = camera_screen.buffer_width = 736; camera_screen.height = camera_screen.buffer_height = 480; camera_screen.size = 720*480; camera_screen.buffer_size = 736*480;
It should be simple to modify motion_detector.c to skip these pixels. We just need some way to identify where they are. Are they at the end of each row?, the beginning? split?
Knowing this, I could modify the code to treat things properly, or it might be better if you did, since you have a camera that can test it .
The only case so far is when we have a width of 736 with active width of 720, I believe.
This also gets into the discussion about buffer sizes too..which I worry we are treating inconsistently...excerpt from lib.c: Code: [Select] camera_screen.width = 720; camera_screen.physical_width = camera_screen.buffer_width = 736; camera_screen.height = camera_screen.buffer_height = 480; camera_screen.size = 720*480; camera_screen.buffer_size = 736*480;is the buffer width really 736 or should it be 1472 (bytes) =736*2?is the buffer size really 736*480? Does "buffer" mean bytes or pixels for digic 6?