I've added detection for viewport_buffers and active_viewport_buffer to the DryOS sig finder.
void *vid_get_viewport_live_fb() { // lifted from a2200 1.00b return (void*)(void*)(*(int*)(0x20F8)); // Possible addresses (20F8, 214C, 28C0)}
Quote from: philmoz on 02 / February / 2013, 23:44:37I've added detection for viewport_buffers and active_viewport_buffer to the DryOS sig finder.I have one camera that will work with this (A1200) so I decided to try it out. Added some debugs to display to the LCD using the code at the bottom of main.c.The first thing I found out is that the current version of vid_get_viewport_live_fb() for the A1200 always returns 0 . Bad porting job - the MD code just defaults to vid_get_viewport_fb().So I added some code to the spytask to scan RAM from 0x1000 to 0x3000 looking for the address returned by vid_get_viewport_fb() and found the three locations. That's pretty much what the A2200 code comments told me to expect. Added another debug and found that only one of those three seemed to change in with shooting mode active.Success - I have a new vid_get_viewport_live_fb() for the A1200 1.00c :Code: [Select]void *vid_get_viewport_live_fb() { // lifted from a2200 1.00b return (void*)(void*)(*(int*)(0x20F8)); // Possible addresses (20F8, 214C, 28C0)}Not so good for the 1.00b version though as I don't have the camera so don't have an easy way to find the right value for that camera. I'll ping some of the beta testers and see if they will run some custom code for me I guess.My next test was to compare my new vid_get_viewport_live_fb() to the value the new sigfinder and G12 based code finds. Both routines turn out to rotate through the same four buffer addresses in shooting mode. So far so good.However, the address returned by each routine at the same point in time is different. I added a debug to simply subtract the two values and display the result in real time. I get the seven difference values you would expect ( all multiples of 0x3f480 - I assume that's the buffer size). This indicates random sync differences between the two routines I think ( unless the buffer addresses change while I'm calculating the difference between them - seems unlikely).So I have now have two ways to find vid_get_viewport_live_fb() but they return different results (same buffer list - different buffer at any point in time). Not sure where to go next with this - just go for empirical testing and see which one comes out faster?Update : just realized I should be able to modify the MD code to use both routines and then see which one is quicker to pick up on a change. Having reyalp's "flash the autofocus LED to trigger the test" might be something to look at now ....
Look forward to seeing the results - using the AF led is an interesting idea, might allow you to calculate the MD detect time without actually needing to record an image (using test mode).
A tip if you need to save values in the module code (e.g. store a get_tick_count() value in the MD code) that you want to use in the core code (display in spytask). I find the easiest way to do this is add entries to the end of the camera_info structure. Both the module and core code can access these without needing to add stuff to the module exporlist.
Quote from: philmoz on 03 / February / 2013, 17:00:43Look forward to seeing the results - using the AF led is an interesting idea, might allow you to calculate the MD detect time without actually needing to record an image (using test mode). Experimenting now. Converted the motion_detector struct to a four element array so that I work with all four buffers. Its possible that the fastest detection might actually involve being one buffer behind the vid_get_viewport_live_fb() pointer. Of coarse I suppose I need to validate the order in which the buffers are used too. So much to learn ...
The code I used in my camera versions is to use active_viewport_buffer - 1 - assuming that's the most recently filled buffer not the one currently being filled.
Although looking at the code now I see I'm also anding the result with 3, assuming there's only four buffers. Not sure how valid that assumption is.
Let me apologize beforehand if this is not posted in the correct place....
I was looking at the parameters for Motion Detection...does the "c" mean that I can program a color brightness so it would (for instance) ignore red and photo motion of a blue object? The reasson I ask is that I want to be able to "frame" my aerial photographs and thought if the settings were color specific i could put colored lamps or pieces of colored cloth on the ground to get the compositon I was seeking.
Can the rows and columns be masked so that only 'right to left' movement will be photographed and 'left to right' will be ignored? Thbis is just a random question and I do not have a specific use for it ... but it might be useful for recording the flow of traffic at different times of rush hour to spot anomalies.
There is a performance hit when displaying the cell difference value in MD.Timings on my G1X:10x10 grid - grid display takes <10ms, cell diff takes 30ms.20x20 grid - grid display takes 10-20ms, cell diff takes 130ms.
I've created a patch (attached) that adds a test mode for the MD code using the AF assist LED.This patch is for the trunk (1.2) version. It's experimental so no guarantees it will work on other cameras.
Started by Barney Fife « 1 2 » Completed and Working Scripts
Started by knorke Creative Uses of CHDK
Started by mrShrimp LUA Scripting
Started by mellow-yellow Script Writing
Started by Kestrel1978 General Help and Assistance on using CHDK stable releases