Fast MD with burst/preview mode

mx3

Re: Fast MD with burst/preview mode

« Reply #180 on: 11 / July / 2009, 00:45:51 »

Advertisements

Quote from: Anaglyphic on 10 / July / 2009, 14:24:59

Any ideas?

1) lower threshold - because at clear day there is a litle noise on sensor
2) use alot of squares - because detection routine uses average value of square so make square as small as possible
3) use bigger comparison interval value - because ... those are objects with "small speed"

Logged

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

fudgey

1705
a570is

Re: Fast MD with burst/preview mode

« Reply #181 on: 11 / July / 2009, 04:59:08 »

Yep, you need a square size closer to your target object size. I use threshold 10 or 15 during the day. Much lower than that and it'll start to autotrigger from noise...you'll know when that happens. And compare interval is indeed crucial, MDFB defaults to speed test/lightning speed, it will never catch a tortoise with the defaults no matter what it's color is.

One thing I'd like to remind is that bugs are always possible. For example my camera fails to trigger from the lower side of the screen when in maximum resolution video mode. I wouldn't be surprised if you'd find a newly ported camera with display buffer configuration different from what we've gotten used to have its own quirks. This is probably not your case now since you already tested this setup indoors....just reminding everyone that it's a good idea to test any new setup by e.g. waving your hand in front of the camera first.

Logged

Anaglyphic

129
Anaglyphic lives!

Re: Fast MD with burst/preview mode

« Reply #182 on: 11 / July / 2009, 15:01:52 »

Thanks for taking the time, guys...

Quote from: mx3 on 11 / July / 2009, 00:45:51

2) use alot of squares - because detection routine uses average value of square so make square as small as possible

Quote from: fudgey on 11 / July / 2009, 04:59:08

Yep, you need a square size closer to your target object size.

This is what throws me off.

I take responsibility for grossly underestimating what a "large" value for interval is, but a great test was a NYC crosswalk - cars passing the detection area triggered regularly, but humans; on bikes, pushing buggies with sprogs, running to cheat the light, much less walking leisurely... NONE of these were captured, even with threshold ~2 points above self-triggering and an interval of 125ms! Moving it up to 250ms make it trigger more regularly on humans. Wow. I thought 25ms was high. But that was with lightning.

Anyway, but this detection grid size...

OK, so hypothetically, if I'm looking to capture a tiny, fast-moving trigger such as distant (eg tiny LCD) movement, it would be better to use a 128x96 grid with 50ms intervals than a single masked target box 1/25th of the screen with 1 cycle interval and pixel step 0... because what you're saying re: averaging, is that it really isn't pixel step 0, just in what gets averaged together to become the comparison value takes into account all pixels? And with such a fast compare interval, it doesn't detect that anything moved because the pixels of the captured region, when averaged, seem exactly the same. Mathematically I understand, but it makes it damn frustrating when experimenting.

re: threshold, I always try to set it close to self-triggering.... I'd rather have a couple empty shots than all misses. For lightning it's a lot easier than say people walking past trees/flowers in shade...

re: the settings I thought would work, waving my hand triggers just fine, as does tossing quarters in front of it, because I guess the spinning and reflections and the geometric edges make for easier detection... not that it was fast enough to catch said quarters flying in the air, but it did fire. Which is why I was so frustrated by why it would never trigger on a single aircraft.

I just tested it again, and it's not predictable in low contrast. Pointing it at the side of a brick highrise building in pre-dawn, it'll catch some white seagulls flying into the detection grid, but it won't catch any grey pigeons, even in groups of 5! If I increase the interval by 30ms to make the averaged difference higher, it's kind of pointless as the birds have already flown out-of-frame so it's irrelevant if it fires, and if I lower threshold by a couple points, the noise self-triggers. 'Course over the course of two hours the sun came up fully, and the same wall and same settings in bright sunlight triggers readily, including catching people walking past or opening windows. Morning neighbour.

Hmm, I have a feature request fudgey, if we can spare the bytes: Instead of just using a # for parameter set to use, can we get a text field in the stored settings, for descriptions? lightning day, lightning night, low contrast small, etc.

Logged

Since we cannot know all that there is to be known about anything,
we ought to know a little about everything. -- Blaise Pascal

Anaglyphic

129
Anaglyphic lives!

Re: Fast MD with burst/preview mode

« Reply #183 on: 11 / July / 2009, 19:49:48 »

Well, this has been a CHDK Saturday for sure, and after many hours I've come to the conclusion that I'm probably asking it to do something it cannot. Low-contrast small on-screen opjects are just difficult to capture. Considering that I'm trying to trigger off objects that, on the LCD, are smaller than of the LCD noise pattern... it's just not going to happen, regardless of how small the detection boxes or how low the pixel step is.

Eh.

Logged

Since we cannot know all that there is to be known about anything,
we ought to know a little about everything. -- Blaise Pascal

fudgey

1705
a570is

Re: Fast MD with burst/preview mode

« Reply #184 on: 12 / July / 2009, 16:33:20 »

Quote from: Anaglyphic on 11 / July / 2009, 15:01:52

OK, so hypothetically, if I'm looking to capture a tiny, fast-moving trigger such as distant (eg tiny LCD) movement, it would be better to use a 128x96 grid with 50ms intervals than a single masked target box 1/25th of the screen with 1 cycle interval and pixel step 0... because what you're saying re: averaging, is that it really isn't pixel step 0, just in what gets averaged together to become the comparison value takes into account all pixels? And with such a fast compare interval, it doesn't detect that anything moved because the pixels of the captured region, when averaged, seem exactly the same. Mathematically I understand, but it makes it damn frustrating when experimenting.

It's been a while since I tried to make sense of the MD code so I may be mistaken, but hopefully not too much:

Pixel step/skip is not related to cell size. If you specify a small cell size and a large pixel step ("large" may be surprisingly low here since live view resolution is rather low), many boxes will have zero active pixels, and the rest will have only one! In that case there is no averaging and thus noise will be a bigger problem.

Obviously your your object actually must hit active pixels. A tiny aircraft drawing a straight line to your LCD could be systematically avoiding all active pixels because they're in straight rows (if I remember correctly, starting from first pixel in top left corner). So, using a small pixel step makes sense.

The other point was already covered, i.e. you need a tiny cell size for a tiny object. MD takes an average from each active pixel in a cell and compares it to the previous average of the same cell. If your object does not cover a significant portion of a single cell, the average will not change much -- especially if its color (in respect to selected channel) doesn't differ that much from the background!

And if the object is small compared to cell size, it could even travel along a cell boundaries always filling two to four cells partially, making detection even less sensitive.

So basically... small cells with many active pixels (likely zero pixel step), and you'll have to mask cells or MD will slow down to a crawl. Then there will hopefully be a sweet spot between enough averaged pixels and small enough cell size so that noise won't autotrigger. But sounds like you've tried everything already and it didn't work... you may very well be beyond the reliable operating limits of the live view in terms of resolution, noise and CPU speed.

Logged

mx3

Re: Fast MD with burst/preview mode

« Reply #185 on: 13 / July / 2009, 03:03:52 »

Anaglyphic. one more idea:
what about using some optical zoom for detection of small objects in centre then zoom out and make shoot?
it seems it is equivalent to using custom centred grid but with better detection reliability...
I think such technique would be useful in cases when you can predict location of object.

Logged

skype: max_dtc. ICQ: 125985663, email: win.drivers(at)gmail, eVB decompiler

Anaglyphic

129
Anaglyphic lives!

Re: Fast MD with burst/preview mode

« Reply #186 on: 13 / July / 2009, 15:05:09 »

Quote from: fudgey on 12 / July / 2009, 16:33:20

So basically... small cells with many active pixels (likely zero pixel step), and you'll have to mask cells or MD will slow down to a crawl. Then there will hopefully be a sweet spot between enough averaged pixels and small enough cell size so that noise won't autotrigger. But sounds like you've tried everything already and it didn't work... you may very well be beyond the reliable operating limits of the live view in terms of resolution, noise and CPU speed.

I dunno how far beyond, but I agree I'm probably discovering limitations. It's still breathtaking what we can pull off. Man, I can really draw current. I worry about resource starvation and random lockups. I mean at one point the grip was extremely hot, as in I instinctively pulled my hand away! A freshly-charged pair of 2700mAh NiMH AAs lasted only ~300 shots / 30 mins with the LCD off. I think they were glowing when I kicked them out.

The LCD noise, I really didn't consider how much is there, especially in low light conditions where (I assume) the camera must use a variable gain opamp and ends up injecting excessive noise into the signal.

Quote from: mx3 on 13 / July / 2009, 03:03:52

Anaglyphic. one more idea:
what about using some optical zoom for detection of small objects in centre then zoom out and make shoot?
it seems it is equivalent to using custom centred grid but with better detection reliability...
I think such technique would be useful in cases when you can predict location of object.

It's a good idea, but in this specific case it wouldn't work because I'm already at maximum optical zoom, not to mention these so-called superzoom cameras take a couple seconds to go from full telephoto to wide and said object would be gone. That doesn't invalidate a good idea, it just won't help right now. :-)

Logged

Since we cannot know all that there is to be known about anything,
we ought to know a little about everything. -- Blaise Pascal

j-5-0

Re: Fast MD with burst/preview mode

« Reply #187 on: 18 / July / 2009, 08:18:48 »

Not sure if this has been posted yet; just loaded into my A1000is (1.00b) and it's working.... at least it loads, monitors and takes a photo, resets. That's as far as I've gotten.

Logged

ragnor

Re: Fast MD with burst/preview mode

« Reply #188 on: 24 / July / 2009, 13:33:29 »

I'm not sure if this is running in my SX1 IS.
I runned script "MDFB-080716-DigicIII-MovieButtonModels.bas". But when I tried it, it begins to take photos. Even when I put lens cap to the lens.
Anyone could explain me why is this happening?

Thank you all!

Logged

fe50

3139
IXUS50 & 860, SX10 Star WARs-Star RAWs

Re: Fast MD with burst/preview mode

« Reply #189 on: 24 / July / 2009, 16:00:45 »

Hello & wellcome, ragnor !

Quote from: ragnor on 24 / July / 2009, 13:33:29

I'm not sure if this is running in my SX1 IS.
I runned script "MDFB-080716-DigicIII-MovieButtonModels.bas". But when I tried it, it begins to take photos. Even when I put lens cap to the lens.
Anyone could explain me why is this happening?

On the SX1 use the following mask setting:

Quote from: elorup on 28 / April / 2009, 02:37:24

Tried again fudgey's motion detection script last evening and used default values plus the mask right=2 and bottom=2. So the camera only used the 8 cells in the upper left part. It worked and didn't constantly fire. I threw things in the cameras field of view and it took pics. I set the SX1 to MF, then to AF. Worked the same, though I didn't test for differences in speed.

Logged

-->FIRMWARE DUMPS<-- * Manual * Lua * me