I've attached my first attempt at adapting motion_detector.c for digic 6 below.
vid_get_viewport_byte_width() (probably just 1280 bytes)
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
Quotevid_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().
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.
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 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
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.
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.
GwhateverX and M models have LCDs/EVFs with different aspect ratio and higher resolution.
!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]) end0000 0x434913000010 0x434913000020 0x434913000030 0x4353fb000040 0x4353fb000050 0x4353fb000060 0x4353fb000070 0x433343000080 0x433343000090 0x433343000100 0x433e2b000110 0x433e2b000120 0x433e2b000130 0x43491300
This great news! I recognize 0x4333400. Not exactly sure how to implement it but I'm sure with time and thought I'll understand
ldr r6, =0x0000880c...subs r6, #0x58ldr r0, [r6, #0x18]
