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

digic 6 motion detection (was Re: SX60HS Porting)

  • 87 Replies
  • 48308 Views
*

Offline reyalp

  • ******
  • 14128
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #70 on: 04 / October / 2016, 17:22:49 »
Advertisements
In my experience, MD_Tune has some some weird issue independent of PTP and D6. It was really a quick and dirty hack. However, the crash I see happens with regular MD too, so it's no related to that.

Are you running live view when the md_tune causes problems?
Quote
What memory location(s) would you suggest to monitor in sx60hs?
If you don't see the crash, then the memory location affected on G7X almost certainly isn't being affected. In SX60 100b, there's an assert for ISDriver.c line 1835 around fc2c1100, but the code doesn't look completely equivalent.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #71 on: 04 / October / 2016, 20:21:09 »
So far I've seen the value be 0x03 and 0x3c in the camera log. From using rmem before and after running MD, the neighboring values don't don't seem to be affected  :-[
It's possible that the corrupted area is located completely elsewhere (for example: your byte variable's source, the propcase area, ...). You could also try disabling all CHDK drawings (use an empty function for draw_pixel_std() ) and do the experiment blindly.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #72 on: 05 / October / 2016, 12:49:39 »
Quote
It's possible that the corrupted area is located completely elsewhere (for example: your byte variable's source, the propcase area, ...). You could also try disabling all CHDK drawings (use an empty function for draw_pixel_std() ) and do the experiment blindly.
Sounds like an excellent idea! You also could disable/disarm allthe pieces of MD and turn them back on one by one until the crash happens.

I checked SX60 100f, I think the IS memory location is 0xb91c (corresponding to g7x 0xb9a0).

during MDtune (IS is set to continuous):
Code: [Select]
con 1> rmem -i32 0xb910 64
0x0000b910 256
0x0000b910: 0x00000000 0x00000001 0x00000000 0x00000001
0x0000b920: 0x00000001 0x00000000 0x00000000 0x00000000
0x0000b930: 0x00000001 0x00000000 0x00000000 0x00000000
0x0000b940: 0x00000001 0x00000000 0x00000000 0x0002405f
0x0000b950: 0x0002aed4 0x0000fffc 0x0000ffc9 0x01d20132
0x0000b960: 0x01d40134 0x01d60136 0x01d80138 0x00000000
0x0000b970: 0x00000000 0x0002aed4 0x00000000 0x80008000
After interrupting MDtune and pressing play:
Code: [Select]
con> c
connected: Canon PowerShot SX60 HS, max packet size 512
con> rmem -i32 0xb910 64
0x0000b910 256
0x0000b910: 0x00000000 0x00000001 0x00000000 0x00000001
0x0000b920: 0x00000001 0x00000000 0x00000000 0x00000000
0x0000b930: 0x00000001 0x00000000 0x00000000 0x00000000
0x0000b940: 0x00000001 0x00000000 0x00000000 0x0009dce2
0x0000b950: 0x0009d487 0x0000fffc 0x0000ffc9 0x01d20132
0x0000b960: 0x01d40134 0x01d60136 0x01d80138 0x00000000
0x0000b970: 0x00000000 0x0009d487 0x00000000 0x80008000

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #73 on: 26 / February / 2017, 21:20:18 »
I've attached a corrected version of motion_detector.c that treats triggering on colors correctly.  The previous version may well have triggered on color changes, but the  R G B values were not calculated correctly.

*

Offline reyalp

  • ******
  • 14128
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #74 on: 19 / March / 2017, 03:57:42 »
I've attached a corrected version of motion_detector.c that treats triggering on colors correctly.  The previous version may well have triggered on color changes, but the  R G B values were not calculated correctly.
Thanks for doing this, and sorry for letting it sit so long. I'm finally getting caught up enough to work on CHDK again :-[

I realized we don't really have a good repeatable way to test MD (other than response timing), so I'm working on some code to support that. The idea is to display a controlled scene on a monitor, and use chdkptp to display the values in various modes. So you can verify that different versions of the code behave equivalently, or that flashing a green rectangle affects the green measure mode more than the red mode. I'll post more details once I have it a bit further along.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14128
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #75 on: 19 / March / 2017, 23:28:41 »
I haven't started debugging yet, but I don't think the U, V and RGB modes are correct in the new code for pre-digic6 cameras.

Here's the test procedure I used:

Display the attached html file
Set up the camera so it's focused at the screen, with the black rectangle near with middle of the frame, taking up roughly 60% of the frame width. Exact size doesn't matter, you just want to have several cells of the 5x5 md grid mostly covered by the rectangle, and several covered by the white background. Nothing other than the middle rectangle and white background should be in the frame.

AE lock or manual exposure should be set to the live view levels don't change when you switch colors.

in chdkptp (with the extras/md.lua from the latest SVN)

Code: [Select]
!m=require'extras/md' m.init()

To test how the colors are interpreted in a given measure mode, use a command like

Code: [Select]
!m.print_result(m.do_md({threshold=10,mode='y',timeout=300,wait=true,cell_vals=true}))For chdk builds before 4771, you need to add start_delay=20.

In this case, we aren't interested in actually detecting motion, just the values seen in the cells. The output will be something like

Code: [Select]
cells: 0 time: 0.320
values:
 179 200 208 200 175
 211 146  96  91 206
 220  93  14  10 218
 224  89  11  10 220
 217 233 238 230 211
The "cells 0" line shows that MD has not triggered, which it shouldn't in a static scene like this. If it does trigger, it could be due to a bug, changes in the scene or a low threshold. You can use cell_diffs=true to see the trigger values.

To switch colors, click on the color at the top, or press the key with the matching number. Run the chdkptp command again after each change.

expected results:
Y mode
Black will be low (~0), white will be high (~200).
Other colors will be in between.

U mode
Unsaturated colors (black, grey, white) will all be ~0
cyan will be positive
magenta will be positive
green will be negative

V mode
Unsaturated colors (black, grey, white) will all be ~0
cyan will be negative
magenta will be positive
green will be negative

R, G, B modes
black will be ~0
white will be high
the color matching the measure mode will be similar to white
the other pure colors will be similar to black

The current svn code on pre-digic 6 meets all of these.
« Last Edit: 26 / March / 2017, 00:32:03 by reyalp »
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #76 on: 21 / March / 2017, 00:24:10 »
Quote
I haven't started debugging yet, but I don't think the U, V and RGB modes are correct in the new code for pre-digic6 cameras
I tried not to touch the predigic6 code, but I think in the last iteration to correct digic 6 color calc I may have made what I thought were innocuous changes to the logic flow around u, v , r g b calcs. 
On the other hand I always thought the calc was suspect pre digic 6 for u v r g b because I didn't think the position/alignment in the row was constrained properly so uyvyyy was used correctly. Sometimes it would hit yyuyv.  It gave me a headache;)

I guess the simplest thing to do ( but maybe not most pleasing)  is to ensure all changes are enclosed within the #ifdef thumb properly. 

Creating a test tool is a good idea. I tried testing using a red laser pointer but it's hard to differentiate between Y and R. This would also be good for zebra and histogram testing. 
« Last Edit: 21 / March / 2017, 01:09:02 by 62ndidiot »

*

Offline reyalp

  • ******
  • 14128
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #77 on: 21 / March / 2017, 01:49:11 »
I tested the new code on G7X and all the modes seem to work correctly.

On the other hand I always thought the calc was suspect pre digic 6 for u v r g b because I didn't think the position/alignment in the row was constrained properly so uyvyyy was used correctly. Sometimes it would hit yyuyv.  It gave me a headache;)
It gives me a headache too, that's why I had to write code to show me what values it's actually seeing.
Quote
I guess the simplest thing to do ( but maybe not most pleasing)  is to ensure all changes are enclosed within the #ifdef thumb properly.
I would be tempted to have to totally separate implementations of md_detect_motion, or maybe the stuff inside the row/column loops. I'd rather have (relatively) easy to follow code duplicated than one massive tangle. Only the innermost loops should really be performance sensitive, so splitting the inner code into platform specific functions might be another option.

edit:
regarding the test code, if the test pattern was implemented in chdkptp GUI code, it could almost be automated....
« Last Edit: 21 / March / 2017, 01:50:58 by reyalp »
Don't forget what the H stands for.

Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #78 on: 22 / March / 2017, 23:55:42 »
Quote
regarding the test code, if the test pattern was implemented in chdkptp GUI code, it could almost be automated....
It took me awhile to understand what you were saying.  Kept misreading chdkptp as chdk.  YES!

Chdkptp is actually a sleeping giant of opportunity for many things. 

*

Offline Ant

  • *****
  • 509
Re: digic 6 motion detection (was Re: SX60HS Porting)
« Reply #79 on: 23 / March / 2017, 11:15:10 »
FYI: on M3 in movie mode veiwfinder refresh rate is equal to selected movie framerate. So, MD Tune shows minimum result 20 and average 29.

 

SimplePortal © 2008-2014, SimplePortal