285 replies to this topic

[FastFrench]

Hello,

I didn't receive any new posts with email in this topic, but I had subscribed it... Strange.

Anyway, now I could test some code for 2.0 if you want.

Thank you, I'll probably ask when there will be something to test

But still looking for someone ready to handle the update of the AutoIt wrapper.

Excuse me, can I use the original search mode function PixelSearch as a function of FFNearestPixel?
I need the coordinates of the first pixel.Thanks.

With FFNearestPixel, you've a finer control on the order of the search. But you can't do exactly the same as with PixelSearch. Now, if you set the reference point as the top left corner of your search area, the result will usually be the same as PixelSearch with default scan order.

[frank10]

Thank you, I'll probably ask when there will be something to test

But still looking for someone ready to handle the update of the AutoIt wrapper.

It's what I meant with the test
If you want to send me the code I could try to make the wrap.

[FastFrench]

It's what I meant with the test
If you want to send me the code I could try to make the wrap.

Good news. Can you gimme your email please, so I can send you the new dll and some instructions ?

[frank10]

I sent a PM with mail on 13 april. I haven't received your answer.

[FastFrench]

I've just sent you all the materials.

Sorry for the delay.

[Rutger83]

I was hoping someone could help me with how to use the 'snapshots', as you can see below I want to use FFColorCount in a loop. But the only way I can do this is by taking a new snapshot everytime it is runned. I tried serveral things but I cant figure out how to use the same snapshot for all the ffcolorcounts in the loop

FFSetDefaultSnapShot(0)
$snap=FFSnapShot($iLeft, $iTop, $iRight, $iBottom)

For $iRow = $iTop to $iBottom
       $iRowCount=FFColorCount($icolor,0,True, $iLeft,$iRow,$iRight,$iRow)

Edited by Rutger83, 24 April 2012 - 12:27 PM.

[FastFrench]

Just check the parameters of FFColorCount...

FFSetDefaultSnapShot(0)
$snap=FFSnapShot($iLeft, $iTop, $iRight, $iBottom)

For $iRow = $iTop to $iBottom
       $iRowCount=FFColorCount($icolor,0,False)

BUT you can only count on the full snapshot, so it doesn't help. That's the reason you need here to make a new SnapShot with a different line each time (as you did), if you need to count separately each row.

Edited by FastFrench, 24 April 2012 - 03:37 PM.

[FastFrench]

New version 2.0 is here !

Thanks to CeramicWeasel for the new Documentation in chm (Windows Help) format
And thanks to Frank10 for his help on the autoit wrapper.

[Jummi]

Anyone use this library in visual basic 2010?

Some example?

Thanks.

[frank10]

Hi, good job on FF2.0

I was trying the FFComputeMeanValues on 4 rectangle snapshots on a webcam pic to determine motion detection and specifically to understand which direction the person is going.
I use this rig so I put rectangles on door A, B, C and D (the white rectangle in bottomright)

I get the snapshots every 100ms and I collect every subsequent detection area in a string with all the areas interested, so, in theory, analyzing the first and the last detection I should know the starting and ending crossing and so the direction of the person.
It works quite well, but I get some problems:

1) At the right of D there is a window so when someone passes in that area, can cast some shadows on door A and this fires up the MeanValues of A without someone crosses there. (A false detection)

2) Apart that, sometimes if someone crosses from D to A or viceversa, I get sequences like this:
correct:
DDDBA
AAABBABBDDD

NOT correct:
from DtoA: DBDBDABAC
from AtoD: ABDDADA
that means in the final motion there is still a motion in an area different from the real final.
For C area it could be some pixels are still out of range after passing through A.
For the A area, it could be the door is still slowly moving when arriving to D


The point is that these false detection could really be true if someone changes idea and wants really to go to C or to return to A from where it was coming...

So, how could I get the real direction of a person avoiding false detection?

Edited by frank10, 29 April 2012 - 04:13 PM.

[FastFrench]

Anyone use this library in visual basic 2010?

Some example?

Thanks.

Some people use it with VB .NET, C# and also C++, but those wrappers are not published (yet).

[Steve0]

I'm having trouble with FFIsDifferent and FFLocalizeChanges... just a very basic example:

$InitialSnapshot = FFSnapShot(0, 0, 0, 0, 0, WinGetHandle("[ACTIVE]"))
Sleep(5000)
$NewSnapshot = FFSnapShot(0, 0, 0, 0, 0, WinGetHandle("[ACTIVE]"))
$ChangeResult = FFLocalizeChanges($InitialSnapshot, $NewSnapshot, 0) ; have tried using FFIsDifferent here also
If IsArray($ChangeResult) = False Then Msgbox(0,"Error","Result is false")

Result always comes back false, regardless of whether the window has changed. I added in FFSaveJPG so I could track, and the window is definitely changing in the 5000ms. I figured with FFLocalizeChanges, I'd be able to get back the number of different pixels between the two snapshots, yet the result is False (ie, not an array of information).

Any idea what I'm doing wrong?

Thanks in advance

Steve

[frank10]

You are putting your two snapshots in the same memory slot (0). Furthermore the return of Snapshot func is 1, so it's useless to use a var to get the return value.
You should do like this:

FFSnapShot(0, 0, 0, 0, 0, WinGetHandle("[ACTIVE]"))
Sleep(5000)
FFSnapShot(0, 0, 0, 0, 1, WinGetHandle("[ACTIVE]"))
$ChangeResult = FFLocalizeChanges(0, 1, 0)
If IsArray($ChangeResult) = False Then Msgbox(0,"Error","Result is false")

This way you put the 2 Snapshots in memory slot 0 and 1 and you compare them in LocalizeChanges. Adjust also the shadevariation to a value more than 0 to avoid false positive due to noise.

[frank10]

I saw this beautiful Siemens alarm detection video.
This is what I'm looking for.
Do you think it's possible to obtain similar result?

Determining the baricenter of a detection rectangle is easy and also tracking it to obtain the path.
The problem is to determine the rectangle to fit the size of a man and above all to split in 2 rectangles when 2 men go in different directions.
In FFlocalizechanges, it could be made monitoring the width of the detection: if more than a threshold, split it at the default maximum width rectangle of a man at left and another one at right.
The best should be different tracking of multiple objects in a scene, so it should necessary a threshold control in every group of changing pixels in the scene, to select different groups separately. You could set an array of groups of pixels with their coordinates.

Another problem could be the perspective of a barrier line: at the moment we use a 2d position system to check the detection, but it should be made taking care of perspective, but this could be made inside autoit script.

Edited by frank10, 15 May 2012 - 01:26 PM.

[Steve0]

You are putting your two snapshots in the same memory slot (0).

Ahh - many thanks frank10. I've adjusted and works well. The script is to be used to monitor a given window on a regular basis to see if it changes. If there has been no change after a set period, the snapshot is to be saved as a JPG and emailed to helpdesk. After the period of time (5000ms) if the snapshots differ, the initial snapshot (memory slot 0) needs to be overwritten by the current snapshot, in order to check again after the next period of time. Would the FFDuplicateSnapshot feature work here? For instance;

FFDuplicateSnapShot(1, 0)

Thanks again

Steve

[frank10]

Yes, FFDuplicate will work.

[FastFrench]

I saw this beautiful Siemens alarm detection video.
This is what I'm looking for.
Do you think it's possible to obtain similar result?

Determining the baricenter of a detection rectangle is easy and also tracking it to obtain the path.
The problem is to determine the rectangle to fit the size of a man and above all to split in 2 rectangles when 2 men go in different directions.
In FFlocalizechanges, it could be made monitoring the width of the detection: if more than a threshold, split it at the default maximum width rectangle of a man at left and another one at right.
The best should be different tracking of multiple objects in a scene, so it should necessary a threshold control in every group of changing pixels in the scene, to select different groups separately. You could set an array of groups of pixels with their coordinates.

Another problem could be the perspective of a barrier line: at the moment we use a 2d position system to check the detection, but it should be made taking care of perspective, but this could be made inside autoit script.

Interesting. But you're right, detecting and tracking several changing sub-areas at the same time starts be be somewhat out of the scope of FFFastFind, and I would say maybe even of a scripted solution. To have decent performance, you would probably need to implement specific algorithms with an optimized language (C++ or something similar).

Now, if you make some assumptions to simplify the problem, maybe you can find some way to do it with the materials you have here (FFFastFind + Autoit).

[FastFrench]

Hi, good job on FF2.0

I was trying the FFComputeMeanValues on 4 rectangle snapshots on a webcam pic to determine motion detection and specifically to understand which direction the person is going.
I use this rig so I put rectangles on door A, B, C and D (the white rectangle in bottomright)

I get the snapshots every 100ms and I collect every subsequent detection area in a string with all the areas interested, so, in theory, analyzing the first and the last detection I should know the starting and ending crossing and so the direction of the person.
It works quite well, but I get some problems:

1) At the right of D there is a window so when someone passes in that area, can cast some shadows on door A and this fires up the MeanValues of A without someone crosses there. (A false detection)

2) Apart that, sometimes if someone crosses from D to A or viceversa, I get sequences like this:
correct:
DDDBA
AAABBABBDDD

NOT correct:
from DtoA: DBDBDABAC
from AtoD: ABDDADA
that means in the final motion there is still a motion in an area different from the real final.
For C area it could be some pixels are still out of range after passing through A.
For the A area, it could be the door is still slowly moving when arriving to D


The point is that these false detection could really be true if someone changes idea and wants really to go to C or to return to A from where it was coming...

So, how could I get the real direction of a person avoiding false detection?

You could do some filtering, but I can't find a reliable way to consider
ABDDADA as a correct A to D path

Mean of 3 last steps is closer of A than D. Maybe you should/could adjust detection params to limit false detection in A.

[frank10]

I think the problem is also related with shadows casted by door, window or the man himself when walking.
When someone is in D sometimes he breaks the window's light from D and casts a shadow to A that fires the Mean values...

The same occurs when the door in A is moving: it reflects light that fires changes in C.



Anyway, I saw the beautiful open source openCV: that's the way to detect and track a movement, obviously it doesn't rely only to mean/luma values.
I would like to try it and maybe to use some DllCall from Autoit if I get it to work, but I don't know if it's possible with all that huge files .h .dll .lib maybe a very restricted set of func just that ones needed...
Do you know something of that? Are you interested to try a little of conversion in Autoit, maybe in another thread?

[FastFrench]

I think the problem is also related with shadows casted by door, window or the man himself when walking.
When someone is in D sometimes he breaks the window's light from D and casts a shadow to A that fires the Mean values...

The same occurs when the door in A is moving: it reflects light that fires changes in C.



Anyway, I saw the beautiful open source openCV: that's the way to detect and track a movement, obviously it doesn't rely only to mean/luma values.
I would like to try it and maybe to use some DllCall from Autoit if I get it to work, but I don't know if it's possible with all that huge files .h .dll .lib maybe a very restricted set of func just that ones needed...
Do you know something of that? Are you interested to try a little of conversion in Autoit, maybe in another thread?

Sorry, but I don't think I'd have the time for that.