digic 6 motion detection (was Re: SX60HS Porting) - page 4 - General Discussion and Assistance - CHDK Forum

digic 6 motion detection (was Re: SX60HS Porting)

  • 87 Replies
  • 28286 Views
*

Online reyalp

  • ******
  • 12153
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #30 on: 07 / August / 2016, 18:29:48 »
Advertisements
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.
Nice.

Did you check md response time with this change?
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #31 on: 07 / August / 2016, 19:50:05 »
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?

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #32 on: 07 / August / 2016, 20:17:38 »
How does this compare to pre Digic 6?
Much better than most and comparable to the best reported.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Online reyalp

  • ******
  • 12153
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #33 on: 07 / August / 2016, 20:28:35 »
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?
About the same (edit: as the ones with fast MD correctly implemented). The time is dominated by live view frame rate (~30fps = ~33ms) and scheduling of kbd_task which runs every 10 ms or more, not in sync with live view frames.

Note md tune just measures the detection latency (between the AF led turning on and the MD code seeing the change), if you are actually shooting there is additional latency between detection and the shot starting. This is poorly characterized and may vary significantly between camera models.
Don't forget what the H stands for.


*

Online reyalp

  • ******
  • 12153
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #34 on: 13 / August / 2016, 16:49:12 »
FWIW, a few times on G7X I've seen md continuously trigger on the right side of the screen when there isn't any real motion. Raising the threshold high enough to avoid triggering also prevents md_tune from working. This doesn't happen every time, and I haven't yet figured out how to reproduce it.
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #35 on: 13 / August / 2016, 18:28:54 »
Interesting.  If the buffer was misaligned at the edge, all that would happen is you would sample a few pixels from the left of next horizontal row.  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?

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #36 on: 13 / August / 2016, 19:21:55 »
Also if you select display 3, grid plus numeric value, it may shed some light on things.  I'm assuming your g7x viewport buffer byte width is 1472? Are the extra undisplayed pixels all on the right? maybe just write a little code to sum up this or these unused margins?

*

Offline srsa_4c

  • ******
  • 4031
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #37 on: 14 / August / 2016, 10:20:48 »
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).


Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #38 on: 14 / August / 2016, 11:55:24 »
Quote
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).

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?

*

Online reyalp

  • ******
  • 12153
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #39 on: 14 / August / 2016, 15:15:11 »
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?
As long as vid_get_viewport_image_offset is implemented correctly, they are effectively at the end.
Quote
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  ;).
I haven't verified it, but srsa_4c's explanation seems like it is probably correct. I the dumps and live view tests I did it looked like they were mostly black, but it's possible there's some case they get set to different values.

I'll look into fixing this, afaik srsa does not have this cam.

Quote
The only case so far is when we have a width of 736 with active width of 720, I believe.
There are quite a few pre-digic 6 cameras with buffer sizes different from image size. The non THUMB_FW code uses vp_w rather than vp_bw for start and end.

The MD code should definitely NOT include buffer area that isn't part of the image.

Quote
  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?
Note that the camera_screen values are actually for the UI buffer, though the SX280 port happens to re-use them for viewport because they happen to be usable for that particular camera (commented "// may not be always ok" in lib.c)
The buffer width currently means pixels here. Older camera bitmap buffers were 8 bpp paletted so bytes/pixels were interchangeable.
Don't forget what the H stands for.