tsiwt

Hello, Since my last post was so confusing. I am posting a video to see if I can get feedback (watch the video fullscreen and follow the mouse to see where my problem is) I am aware that the solution might be easy. but it is baffling me.

http://screencastle.com/watch/8ae6f575b41b94000cfaf1abc3ff2687

there are three stages in the video all are basically the same problem but in different scenarios

scenario 1) If centroid detection vanished the result number goes default to 127 instead of staying in last captured number (in this case #71)

scenario 2) If centroid detection leaves the screen it goes back to default 127 instead of staying in the last number before it left the screen (in this case 81)

scenario 3) i toogle the line object and th gswitch in order for the last captured number to remain 5 seconds the problem with this approach is that after 5 seconds it reverts to 127

I want to always send the tracking number but if there is no tracking or the tracking goes out the screen to make it stay in the last tracked digits instead of defaulting in this case to 127.

writing about it , it makes sense that this is a centroids command and not max, seejayjames ( a very valuable poster in the forum) suggested I use [i] or "set $1" but I am not sure if that is going to do it for me.

there are three stages in the video  all are basically the same problem but in different scenarios

scenario 1) If centroid detection  vanished the result number goes  default to 127 instead of staying in last      captured number (in this case #71)

scenario 2) If centroid detection leaves the screen it goes back to default 127 instead of staying  in the last number before it left the screen (in this case 81) 

scenario 3)  i toogle the line object and th gswitch in order for the last captured number to remain 5 seconds the problem with this approach is that after 5 seconds it reverts to 127 

I want to always send the tracking number but if there is no tracking or the tracking goes out the screen to make it stay in the last tracked digits instead of defaulting in this case to 127. 

writing about it , it makes sense that this is a centroids command and not max,   seejayjames ( a very valuable poster in the forum) suggested I use  [i] or  "set $1" but I am not sure if that is going to do it for me. 

made-a-video-that-clarifies-my-problem

I am beginning to think that this problem is mainly a limitation to cv.jit.centroids rather than a limitation to my max knowledge.

once the camera is not detecting any centroids it defaults to 0 or in my case 127 . And I can't even send a #msg to the int number box, it just stays in 127. until next centroids are detected on which the jit. iter unpacks the position again and the number moves from 127 to the X position of the centroid.

once the camera is not detecting any centroids it defaults to 0 or in my case 127 .  And I can't even send a #msg to the int  number box, it just stays in 127.  until next centroids are detected on which the jit. iter unpacks the position again and the number moves from 127 to the X position of the centroid.


ah I think I know the problem, have run into it before. cv.jit keeps sending the values even with no centroids detected. you need to do a [zl len] on the output first and if it's 1 (I think it sends a single value with no blobs detected) you can [gate] the output, which will prevent overriding what you're sending to the int number box. But if [zl len] is greater than 1, you're detecting at least one blob (it sends out a list of 3: X Y area), 6 if it detects two blobs, etc.

If you put a [print] after the number box and send it a message, you'll probably see your number appear in the Max window, but it gets overriden so quickly you can't see it in the patch itself.

thanks seejayjames, I don't understand zl len very well but from the help patch it seems like It might do the trick, I didn't think anyone was going to reply, thanks for the help. I didn't see zl in the max tutorials.

anyways thank. Ill repost if I run into difficulties

thanks seejayjames, I don't understand zl len very well but from the help patch it seems like It might do the trick, I didn't think anyone was going to reply, thanks for the help.   I didn't see zl in the max tutorials. 

anyways thank. Ill repost if I run into difficulties


ok I have recreated the problem without using Centroids.

I encapsulated the part where I am trying to experiment and find a solution (with the advice seejayjames gave me of using zl len) I still haven't figured it out.

It is all programming no cv jit object involve... Now do you think you can help?

It is basically this -> How to pause and unpause number comming out of a line object without taking the line off.

The challenge is how to do this only in one number output 

hi vanille bechamel,
ok I have recreated the problem without using Centroids. 

I  encapsulated the part where I am trying to experiment and find a solution (with the advice seejayjames gave me of using zl len) I still haven't figured it out. 

It is all programming no cv jit object involve...  Now do you think you can help?

It is basically this -> How to pause and unpause number comming out of a  line object without taking the line off. 

The challenge is how to do this only in one number output 


I'm still not quite understanding what you're trying to do, but maybe this is close?

cool Chris thanks, yes that is very close! the problem is that after you turn it off and on again it doesn't turn on where it left off, but rather in a number of the line sequence.

so for it work, if I turn it off in 56 when I turn it on again it would be 56 again and then move up to 127.

This works. But the rest of the [line] output will be slower than the original, as it takes the overall time and divides that to determine how fast the steps are. So if you stop at 100 and then go to 127, it'll be much slower to get there (5000 msec stays constant, but only 27 steps rather than 127). Used the "stop" message to [line] and stored the current step into another [i] to be used when the [line] is resumed.

To adjust for that you could scale the 5000 msec by the percent of 127 that the new [line] part needs to go through, would be straightforward. Though if you add the [qmetro] into the picture (which keeps banging regardless) you'll need to figure out how to manage the overall timing as you see fit. The right outlet of [line] that signals the end of the ramp, plus the ability to reset and restart the [qmetro] at a new interval should give you everything you need for whatever functionality you want. 

smooth!! thanks for the help, this forum is very good even though it has gotten popular over the past year.

Ill submit what I did with your help after its finished and field tested.

smooth!! thanks for the help, this forum is very good even though it has gotten popular over the past year.
Ill submit what I did with your help  after its finished and field tested. 

Made a video that clarifies my problem