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

digic 6 motion detection (was Re: SX60HS Porting)

  • 87 Replies
  • 28310 Views
*

Offline srsa_4c

  • ******
  • 4031
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #20 on: 26 / July / 2016, 20:38:36 »
Advertisements
I've attached my first attempt at adapting motion_detector.c for digic 6 below.
I have tried it briefly, so I'll share a few thoughts.

- It appears to trigger (I used the md_tune.bas script in Y mode).
- Testing is very difficult due to these:
 - vid_get_viewport_live_fb() is not available, that means 10fps effective input instead of 30fps
 - screen drawing is horrible - it blinks and it is very slow

What method would you recommend for testing?

Some other notes:
Quote
vid_get_viewport_byte_width() (probably just 1280 bytes)
That's true for sx280/sx60 in LCD mode, but wrong for the other 2 ports. This should probably be computed from one of the vid_get_viewport functions, maybe vid_get_viewport_buffer_width_proper().

I have to admit that I know very little about the motion detector code...

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #21 on: 27 / July / 2016, 14:11:56 »
Thanks for the feedback srsa_4c.
Quote
vid_get_viewport_live_fb() is not available, that means 10fps effective input instead of 30fps
I tested and found response times varied from about 200-300 ms for pixel step of 1, to 80-100ms for larger pixels steps. Presumably a pixel step of 1 is using a lot of processor cycles, but a larger pixel step like 4 or 8 rapidly reduces the processor cycles by factors of 16 and 64 respectively. This seems consistent with 10 fps. I used different scan intervals 10,15,20 ms, which are probably unecessarily short given that a new updated frame won't be available for 100ms at 10fps.

FYI, motion detect scans each grid rectangular area of viewport, skipping by pixel step both in X and Y. So a pixel step, of say 2, results in every second horizontal line being scanned with every second pixel in X  having its Y(or other component) evaluated contributing to a sum value for that grid cell. If the sum value differs (up or down) from the previous sum value for the same grid cell by more than the threshold specified, the cell is "triggered"... Thus a pixel step of two, only evaluates 1/4 of the pixels in a grid cell. Too many grid cells, or too large a pixel step and you may have too few pixels to make a reliable sum to trigger on.

Quote
- screen drawing is horrible - it blinks and it is very slow
I didn't touch the screen drawing part, it seems to work fine on the sx60hs, but as I don't have a pre digic 6 camera to compare to, I may be easily satisfied. I am looking for something cheap and supported pre-digic6. Or perhaps you are referring to the console text which is output from md_tune.bas?

Quote
Quote
vid_get_viewport_byte_width() (probably just 1280 bytes)
That's true for sx280/sx60 in LCD mode, but wrong for the other 2 ports. This should probably be computed from one of the vid_get_viewport functions, maybe vid_get_viewport_buffer_width_proper().
I'll check into this, originally I had a problem because I hadn't defined vid_get_viewport_byte_width() and it picked up the weak definition from generic/wrappers.c, which returned 1080 bytes (6bytes/4pixels*640 pixels).  I assumed that all digic 6 were just hard coding 640. On the sx60hs the electronic view finder is also 640 wide (1280 bytes). I have played with hdmi and it works, of course with a different width, and I suppose motion detection should play nicely no matter how you're viewing the image. Bottom line  vid_get_viewport_byte_width needs to work correctly for the platform and viewport in use.

Thinking to build and post a test SX60HS version so I can get more feed back.







*

Offline srsa_4c

  • ******
  • 4031
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #22 on: 28 / July / 2016, 20:53:57 »
motion detect scans each grid rectangular area of viewport, skipping by pixel step both in X and Y. So a pixel step, of say 2, results in every second horizontal line being scanned with every second pixel in X  having its Y(or other component) evaluated contributing to a sum value for that grid cell. If the sum value differs (up or down) from the previous sum value for the same grid cell by more than the threshold specified, the cell is "triggered"... Thus a pixel step of two, only evaluates 1/4 of the pixels in a grid cell. Too many grid cells, or too large a pixel step and you may have too few pixels to make a reliable sum to trigger on.
Thanks for the explanation.
Quote
I didn't touch the screen drawing part, it seems to work fine on the sx60hs, but as I don't have a pre digic 6 camera to compare to, I may be easily satisfied. I am looking for something cheap and supported pre-digic6. Or perhaps you are referring to the console text which is output from md_tune.bas?
I'm referring to the grid drawn by the module (one of the script parameters controls this). Now that I retried, it doesn't seem that bad. It's hard to catch the cells that trigger though, and the interaction between the grid and the script's text output is irritating (screen gets cleared when the console updates, flashing that "busy" text). I'm using the script with shooting disabled.

Quote
I assumed that all digic 6 were just hard coding 640. On the sx60hs the electronic view finder is also 640 wide (1280 bytes).
GwhateverX and M models have LCDs/EVFs with different aspect ratio and higher resolution.
Quote
I have played with hdmi and it works, of course with a different width
You have HDMI output in rec mode? Also, I don't see CAM_SUPPORT_BITMAP_RES_CHANGE implemented for the sx60 port, so you'd have wrong CHDK overlay on the HDMI output.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #23 on: 28 / July / 2016, 22:39:37 »
Quote
You have HDMI output in rec mode? Also, I don't see CAM_SUPPORT_BITMAP_RES_CHANGE implemented for the sx60 port, so you'd have wrong CHDK overlay on the HDMI output.

Sorry, sloppy thinking, HDMI in play mode only. Not sure if it would work in REC mode even with CANON software booted (I haven't checked). There is "No Signal" in REC mode, not even the green grid shows from motion detect. I do have CAM_SUPPORT_BITMAP_RES_CHANGE implemented (partially) in my local build..and HDMI in play mode works. Haven't checked audio though.

Quote
I'm referring to the grid drawn by the module (one of the script parameters controls this). Now that I retried, it doesn't seem that bad. It's hard to catch the cells that trigger though, and the interaction between the grid and the script's text output is irritating (screen gets cleared when the console updates, flashing that "busy" text). I'm using the script with shooting disabled.
I agree, this is pretty much what I see too.



*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #24 on: 31 / July / 2016, 22:59:00 »
Thanks for doing this, I finally got around to testing on G7X
Running MD tune for ~100 cycles, I got min=40 max=120 avg=~87
This is about what I'd expect for ports without vid_get_viewport_live_fb()

Using MDFB2013.LUA in test mode, I could see that the correct parts of the grid triggered when moving my hand in front of the lens.

I agree there are drawing issues, on older cams it's much easier to see which cells are triggered. This general d6 drawing stuff, not related to 62ndidiot's changes. I found it easier to see the triggered cells in mdfb test mode, because the numbers hand around longer.

I'll try to take a closer look a the code and post more specific comments on that later.

edit:
GwhateverX and M models have LCDs/EVFs with different aspect ratio and higher resolution.
Indeed, g7x is a 720 pixel image on a 736 wide buffer :-[
« Last Edit: 31 / July / 2016, 23:06:01 by reyalp »
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #25 on: 06 / August / 2016, 13:34:28 »
Interesting case when 736*2 is the byte width.  This is not divisible by 3 or by 5 for example.  So you (@reyalp or others with 736) will be testing my arithmetic when you select three or five columns horizontally, that corrects for uneven (2 byte) starts to the uyvy pattern in each rectangle. The sx60hs has a width of 1280 which is divisible by 5 but not 7 or 9. This was/is absent in the pre digic 6 code, however, the buffer width (1080=640*6/4 uyvyyy) is divisible by 2,3,4,5,6,8,9,10 so the problem of misalignment (in this case 3 bytes) resulting in mixing of u,v,y would only happen for 7 columns (or 11) which probably doesn't matter in most applications.

*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #26 on: 06 / August / 2016, 21:53:05 »
I think I've found the current viewport buffer for g7x.
0x87f0 rotates through the list I identified previously (at fc612b84, also with RAM dumping) at ~30fps
Code: [Select]
!r=con:execwait[[t0=get_tick_count() r={} for i=1,14 do table.insert(r,{get_tick_count()-t0,peek(0x87f0)}) sleep(10) end return r]] for i,v in ipairs(r) do printf("%04d 0x%08x\n",v[1],v[2]) end
0000 0x43491300
0010 0x43491300
0020 0x43491300
0030 0x4353fb00
0040 0x4353fb00
0050 0x4353fb00
0060 0x4353fb00
0070 0x43334300
0080 0x43334300
0090 0x43334300
0100 0x433e2b00
0110 0x433e2b00
0120 0x433e2b00
0130 0x43491300

This is unlike previous cams where we have an index into of buffers. I looked at nearby addresses (+/- ~100 words but didn't see anything else that updated around the same rate.

Using this with md tune gives consistent times around 80ms, indicating that it isn't the most recent buffer. On other cams, we typically use the firmware index variable - 1 for fast MD.

Using the next entry in the list seems to give ~50ms response, which is fairly good. Others give worse performance.
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #27 on: 06 / August / 2016, 22:52:58 »
This great news! I recognize 0x4333400. Not exactly sure how to implement it but I'm sure with time and thought I'll understand :)


*

Offline reyalp

  • ******
  • 12159
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #28 on: 07 / August / 2016, 01:03:47 »
This great news! I recognize 0x4333400. Not exactly sure how to implement it but I'm sure with time and thought I'll understand :)
The g7x platform part of the code is checked in with a few comments, but unfortunately I don't have a step by step method to find it from disassembly. It involved some RAM searching and lucky guesses.

Some tips:
Initially, I found the addresses of the viewport buffers (other than the first one) from RAM dumps with binview.
I searched ROM for a list of these addresses together, which I found at 0xfc612b84. To do this, I searched for the known first address 0x43334300 and dumped nearby values for those that were found.
I searched ROM code for references to 0xfc612b84, but didn't find any. However, I did find references to a nearby address (0xfc612b74) in ROM code near references to LiveImage.c.
From older ports, I knew that the active buffer information was contained in a structure referenced by the LiveImage.c code, so I searched for nearby variable references, and dumped those.

Unfortunately, the thumb2 compiler often generates addresses for data in a roundabout way, e.g.
Code: [Select]
ldr r6, =0x0000880c
...
subs r6, #0x58
ldr r0, [r6, #0x18]
which makes it hard to find references to a specific structure. In the pre-digic6 firmware, a function that references a particular structure will typically just do ldr Rn,0x... for the specific address.

If SX60 is similar, I think the current buffer variable (equivalent to g7x 0x87f0) should be not far (~188 bytes) after 0x8754 (from fc13e46a, just before LiveImageTool.GetDzoomPosition_FW)
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #29 on: 07 / August / 2016, 16:21:58 »
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. I will build 100f and 100b versions for the SX60HS usings 4668. :)
« Last Edit: 07 / August / 2016, 17:22:54 by 62ndidiot »