motiontrack-devel Mailing List for Motiontrack
Status: Beta
Brought to you by:
corvuscorax
Menu
▾
▴
motiontrack-devel — Main developer mlist
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Nick W. <ni...@li...> - 2005-09-30 16:33:15
|
On Friday 30 September 2005 17:10, Nick Warne wrote: > FYI, I have attached my whole 'security' script that I have now cobbled > together (my Cam is a 3Com homeconnect). I have got the false/postive down > to about 1 image in 12 hours solid running (usually caused by drastic > outside light shift - sun coming out directly through window etc.). > > Again many thanks for a great project. Oh, forgot to mention - I hacked motiontrack.c a little, so all it outputs is the sector change as a digit, therefore I can just assign a $var to it as per in the script. I also hacked the vigrab code so the green neon light on my cam stays off! Nick -- http://sourceforge.net/projects/quake2plus "When you're chewing on life's gristle, Don't grumble, Give a whistle..." |
|
From: Nick W. <ni...@li...> - 2005-09-30 16:11:08
|
On Thursday 29 September 2005 23:22, Corvus Corax wrote: > To work around that you could either set the enhance quality to 100% (what > makes motiontrack slower) or set your sectorsize smaller. I suggest 5 or 8 > pixel for a 320x240 (160x120 after enhance) source, which correspond to > 10x10 or 16x16 pixel blocks in your source image. OK, I understand now. I was doing this, but sectors_image still showed the sectors changing where the date was - so I presumed (never presume!) the ignoresectors wasn't working. But of course, looking at output of sectors list, they are indeed ignored. So I go this working perfect now. Thanks. FYI, I have attached my whole 'security' script that I have now cobbled together (my Cam is a 3Com homeconnect). I have got the false/postive down to about 1 image in 12 hours solid running (usually caused by drastic outside light shift - sun coming out directly through window etc.). Again many thanks for a great project. Nick -- http://sourceforge.net/projects/quake2plus "When you're chewing on life's gristle, Don't grumble, Give a whistle..." |
|
From: Corvus C. <cor...@cy...> - 2005-09-29 22:22:54
|
Am Thu, 29 Sep 2005 18:59:36 +0100 schrieb Nick Warne <ni...@li...>: > > > > Those "sectors" are really squares, in a 2d coordinate system that spans > > over the image - for example with sectorsize 10 on a 320x240 image sectors > > range from 0,0 (top left sector) to 31,23 (right bottom sector) (sectorsize > > is in pixel) > > OK, this is exactly how I guessed it should work, but I couldn't get it to > work, hence why I ended up running a debug script to give me the sectors > where the date was in the image. > > But I just tested again with two 320x240 images > > ./motiontrack --sectorsize 10 image_a.jpeg image_b.jpeg image_out.jpeg > > Now, image_out.jpeg is 160x120 in size! And therefore e.g. sector 31,23 > doesn't exist (it becomes 15,11)? > > Now, I have edited code to supress info and the sector lists (I just use > sectorcount | $var), but I haven't changed no code at all. Any ideas what I > am doing wrong? > Ah ok - got it - what you are experiencing is an effect added by the edge enhancement filter, wich in default configuration decreases the image dimensions of its output by 50% to gain speed. At the same time the new behaviour of "enhance" was added, the default sectorsize changed from 10 to 5 pixels to not break existing scripts. If you explicitly set 10 pixel sectorsize you indeed have 16x12 sectors in your image so they would range from 0,0 to 15,11. Maybe I should add some more documentation to that. motiontrack basically is a frontend to the single filter steps run on your images, while each flter runs on the result of the previous, like if you would run them manually. Since the "enhance" step decreases the image size from 320x240 to 160x120, the "sector" filter for which --sectorsize applies runs on a 160x120 sized image. To work around that you could either set the enhance quality to 100% (what makes motiontrack slower) or set your sectorsize smaller. I suggest 5 or 8 pixel for a 320x240 (160x120 after enhance) source, which correspond to 10x10 or 16x16 pixel blocks in your source image. regards Corvus |
|
From: Nick W. <ni...@li...> - 2005-09-29 17:59:50
|
Hi Corvus, On Thursday 29 September 2005 13:59, Corvus Corax wrote: > Hey thanks :) Thanks for info. I will have a few little things you can do :-) > > One question - I am a bit lost on the way the --sectorsize coords work > > for ignoring sections of the image. e.g. after running several debug > > scripts, my 320x240 image with --sectorsize 15 has the bottom > > middle/right row sectors as '6,7 7,7 8,7 9,7'. I am not sure how this > > works out like this? > > Those "sectors" are really squares, in a 2d coordinate system that spans > over the image - for example with sectorsize 10 on a 320x240 image sectors > range from 0,0 (top left sector) to 31,23 (right bottom sector) (sectorsize > is in pixel) OK, this is exactly how I guessed it should work, but I couldn't get it to work, hence why I ended up running a debug script to give me the sectors where the date was in the image. But I just tested again with two 320x240 images ./motiontrack --sectorsize 10 image_a.jpeg image_b.jpeg image_out.jpeg Now, image_out.jpeg is 160x120 in size! And therefore e.g. sector 31,23 doesn't exist (it becomes 15,11)? Now, I have edited code to supress info and the sector lists (I just use sectorcount | $var), but I haven't changed no code at all. Any ideas what I am doing wrong? > > http://sourceforge.net/projects/quake2plus > > heh - cool project - long live ID software for GPLing their Quake code :-) Yes, heh. I started this ages ago and finally decided to go public with it properly. Thanks, Nick -- http://sourceforge.net/projects/quake2plus "When you're chewing on life's gristle, Don't grumble, Give a whistle..." |
|
From: Corvus C. <cor...@cy...> - 2005-09-29 13:00:03
|
Am Wed, 28 Sep 2005 16:34:05 +0100
schrieb Nick Warne <ni...@li...>:
> Hi,
>
> I have been playing with this for two days, and got it working perfectly!
>
> What a great bit of code! I am really surprised the sourceforge page is so
> quiet???
>
> Anyway, I use to compare two images from my webcam to detect motion (of sorts)
> - it is superb!
>
Hey thanks :)
The sourceforge site is currently quiet for several reasons reasons
- 1: Im still the one and only motiontrack developer
- 2: most downloads are taken from my own mirror and probably not from
sourceforges doe to my link setup so the statistics dont reflect them
- 3: I hadnt had the time to work on the open source part during the past half
year -- some improvements are to come but not yet included into the code base
- like a streaming capable high speed motion routine to link into someones own
programs - I developed that as a paid project for someone who stumbled over
motiontrack but needed it faster for a multi camera commercial surveillance
solution, I will release that under GPL of course, but it has to be cleaned
up first.
Also improved color selection code which allows to mask image regions
with an alpha channel instead of just a list of to be ignored sectors are
planned.
However I have currently no idea how to improve on the object detection
code - all approaches I thought about are not practical yet - maybe I lack the
skill ^.^ - well at least I have a nice ascii art generator ;)
> One question - I am a bit lost on the way the --sectorsize coords work for
> ignoring sections of the image. e.g. after running several debug scripts, my
> 320x240 image with --sectorsize 15 has the bottom middle/right row sectors as
> '6,7 7,7 8,7 9,7'. I am not sure how this works out like this?
Those "sectors" are really squares, in a 2d coordinate system that spans over
the image - for example with sectorsize 10 on a 320x240 image sectors range from
0,0 (top left sector) to 31,23 (right bottom sector) (sectorsize is in pixel)
if you make motiontrack create an output image you see the motion amount
detected in each sector and the ones with motion over threshold are marked.
> http://sourceforge.net/projects/quake2plus
>
heh - cool project - long live ID software for GPLing their Quake code :-)
regards
Corvus
|
|
From: Nick W. <ni...@li...> - 2005-09-28 15:34:15
|
Hi, I have been playing with this for two days, and got it working perfectly! What a great bit of code! I am really surprised the sourceforge page is so quiet??? Anyway, I use to compare two images from my webcam to detect motion (of sorts) - it is superb! One question - I am a bit lost on the way the --sectorsize coords work for ignoring sections of the image. e.g. after running several debug scripts, my 320x240 image with --sectorsize 15 has the bottom middle/right row sectors as '6,7 7,7 8,7 9,7'. I am not sure how this works out like this? (I compared images during a run to see the image clock change, hence how I got those coords). Thanks, Nick -- http://sourceforge.net/projects/quake2plus "When you're chewing on life's gristle, Don't grumble, Give a whistle..." |
|
From: Eric N. <eri...@gm...> - 2003-01-28 17:14:38
|
Seceral features had been added lately and need testing. Whoever reads this, test ang give me feedback :-)) Corvus Corax PS: I am open for any additional feature requests, since the old short-time list of "features to add" is almost depleted, and i dont have an idea how to realize the longterm-planned "object detection" yet. |
|
From: Eric N. <eri...@gm...> - 2003-01-16 21:48:47
|
A support action for a frustrated Motiontrack user (who is now beta tester) leads to the knowledge of: gd.h being another version as the libgd actually installed leads to successful compilation of a motiontrack which does run, but not process images right. in fact it does absolute nonsense and probably never (or always) detects motion so if anyone sees this problem, just check for the libgd headers, they are probably wrong Corvus |
|
From: Eric N. <eri...@gm...> - 2002-12-05 18:16:54
|
Unfortunately my DSL provider gives me dynamic IPs, and some of their available IP ranges are in a DUL list of dialup adress ranges. sourceforge's mailserver rejects mail coming from them, so when getting your mails returned, just forget your local mail system that took you hours to configure properly to work with all connected computers and configure your providers ntpd relay (if you are lucky enough to have a provider that lets you access one) as a mail relay computer. GRRRRRRR this is unnecessary! blame sourceforge. why do they use dialup DULs ? Corvus V Corax -- angry and annoyed when he cant post to his own mailinglist! |
|
From: Eric N. <eri...@gm...> - 2002-12-05 18:00:17
|
libPNG seems no need zlib and math in some version on some systems. motiontrack's configure checks for that now since 0.0.2-rc5 Corvus V Corax |
|
From: Eric N. <eri...@gm...> - 2002-12-02 15:01:50
|
Bug reports have proven that the gd lib seems to have problems on some distributions with some versions of libpng This leads to unresolved function references in libpng when checking for libpng - or when compiling. This is definitely a libpng issue, however if anyone might know a workaround how to link to this libs, please tell. For now. libgd seems to work well with libpng 1.0.12, but not with libpng 1.2.4 and 1.2.5 on all of my gentoo systems. and on at least 1 reported SuSE systems libpng 1.2.5 does not work doe to this issue. maybe libpng needs additional libs to work since 1.2.x, if anybody knows, please tell me! Corvus V Corax |
|
From: Eric N. <eri...@gm...> - 2002-12-02 02:49:52
|
This is the main Mailinglist for Motiontrack Feel free to ask or report everything about the project here if the list gets too crowded, i might create other lists for specific issues. i'd really look up for this, having created a project wich gets so much publicity :) Make yourself at home. Corvus V Corax |
