johannes-eckart@gmx.at

I have problems with clear colour-tracking! In my patch I would like to track two colours, red and blue, and draw a line with these two informations (maybe this exlanation seems familiar to somebody, because I already posted some questions on it in earlier times, but still problems exist :$ ...).

The short video is an example of the colour-informations i get with my camera. ("video_320_240_15.mov" attached)

Unfortunately the line I get isn't very "homogeneous". It is very wiggly and sometimes the colour is totally lost so the line is somewhere else in the window.

* Is the resolution too small (already tried 640*480, but still problems and the CPU is not very happy ;) )?

* Are there better ways to track the colours instead of "jit.findbounds" (already looked a little bit on "cv.jit"-tracking, but most of they seem to work only in greyscale)?

* Is there a better way to clear out the colours maybe?

* Or is it just a calculation, that could help me to get a more proper line (don't know exactly how, just brain-storming...)

And a last question: everytime I switch on the camera, the CPU rashes up close to his limit! I already tried "displaylist" enabled on "jit.gl.sketch", or "depthbuffer" and "sync" on the "jit.window", but nothing really helped me...

Honestly I have to say, that only my laptop has hard problems with that, because he is already an older generation. But maybe something in my patch could be improved to "protect" a little bit my CPU...

I am sorry for posing so many problems at once, but any hints or tips are very useful for me as a "fresh" Jitter-User ;) !

Thank you very much indeed for your help!

Hi community,
I have problems with clear colour-tracking! In my patch I would like to track two colours, red and blue, and draw a line with these two informations (maybe this exlanation seems familiar to somebody, because I already posted some questions on it in earlier times, but still problems exist :$ ...).
The short video is an example of the colour-informations i get with my camera. ("video_320_240_15.mov" attached)
Unfortunately the line I get isn't very "homogeneous". It is very wiggly and sometimes the colour is totally lost so the line is somewhere else in the window.
* Is the resolution too small (already tried 640*480, but still problems and the CPU is not very happy ;) )?
* Are there better ways to track the colours instead of "jit.findbounds" (already looked a little bit on "cv.jit"-tracking, but most of they seem to work only in greyscale)?
* Is there a better way to clear out the colours maybe?
* Or is it just a calculation, that could help me to get a more proper line (don't know exactly how, just brain-storming...)

And a last question: everytime I switch on the camera, the CPU rashes up close to his limit! I already tried "displaylist" enabled on "jit.gl.sketch", or "depthbuffer" and "sync" on the "jit.window", but nothing really helped me...
Honestly I have to say, that only my laptop has hard problems with that, because he is already an older generation. But maybe something in my patch could be improved to "protect" a little bit my CPU...

I am sorry for posing so many problems at once, but any hints or tips are very useful for me as a "fresh" Jitter-User ;) !
Thank you very much indeed for your help!
Johannes

clear-out-colours

I don't quite understand what your final goal is. Do you want to see 

one line drawn between one red and one blue blob? What do you want to 

- Get ridd of as much pwindow objects as you can(I would kill them 

- You probably do not need very high resolution input video to 

analyze, I guess 80x60 would work. You could also add @unique 1 

attribute to jit.qt.grab to avoid sending same frame to analysis.

- Use qmetro instead of metro(this is a religious statement, ignore 

it if you're atheist and want to burn in hell)

- Are you totally sure you need two brcosa objects?

CV jit is very recommended, and if you're concerned about grayscale - 

don't worry, red and blue alone are grayscale anyway... open 

jit.unpack help file, load your video in it and see what's coming out.

I don't quite understand what your final goal is. Do you want to see  
one line drawn between one red and one blue blob? What do you want to  
happen when one of them is not visible?

Anyway, concerning cpu optimizations:
- Get ridd of as much pwindow objects as you can(I would kill them  
all, mwhaa ha ha ha).
- You probably do not need very high resolution input video to  
analyze, I guess 80x60 would work. You could also add @unique 1  
attribute to jit.qt.grab to avoid sending same frame to analysis.
- Use qmetro instead of metro(this is a religious statement, ignore  
it if you're atheist and want to burn in hell)
- Are you totally sure you need two brcosa objects?

CV jit is very recommended, and if you're concerned about grayscale -  
don't worry, red and blue alone are grayscale anyway... open  
jit.unpack help file, load your video in it and see what's coming out.

thanks for your reply! Jeah, thats quite what I want. Red gives x,y-coordonates and also Blue. When I calculate them together, they should give me the coordinates of a new point between them. So when the two points are moved, also the new point moves and draws the line.

The two coloured points are always visible in my project! I just film a surface of 800*800mm, the points have a diameter of 40mm and are moved around on the surface.

With the resolution I will have to rest that high, I think, because the line should be very accurately defined (small turns, small displacement, a.s.o...)

Of course I will follow your instructions to optimize my CPU, thank you!

Do you have a proposition for which "cv.jit"-command will work best, maybe?

HI nesa!
thanks for your reply! Jeah, thats quite what I want. Red gives x,y-coordonates and also Blue. When I calculate them together, they should give me the coordinates of a new point between them. So when the two points are moved, also the new point moves and draws the line.
The two coloured points are always visible in my project! I just film a surface of 800*800mm, the points have a diameter of 40mm and are moved around on the surface.
With the resolution I will have to rest that high, I think, because the line should be very accurately defined (small turns, small displacement, a.s.o...)
Of course I will follow your instructions to optimize my CPU, thank you!
Do you have a proposition for which "cv.jit"-command will work best, maybe?
Greetings,
Johannes


if the input video is what you've sent before, then maybe it will not 

be necesarry to use cv.jit, but it is worth studying anyways.

I've posted example patch below, same concept like yours but with few 

spices added, like smoothing the movement using msp(if input video is 

at 15fps, rendered fps can be usually much higher and thus movements 

can be much smoother), and I've also raised min threshold for 

jit.findbounds, because blue dot is sometimes pinkish and therefore 

present in red plane a bit(you can see that in preview window).

if the input video is what you've sent before, then maybe it will not  
be necesarry to use cv.jit, but it is worth studying anyways.

I've posted example patch below, same concept like yours but with few  
spices added, like smoothing the movement using msp(if input video is  
at 15fps, rendered fps can be usually much higher and thus movements  
can be much smoother), and I've also raised min threshold for  
jit.findbounds, because blue dot is sometimes pinkish and therefore  
present in red plane a bit(you can see that in preview window).

Thanks a lot for your patch! Haha, the line is getting more and more clear and perfect!! Great, really!

I go on working now on the final patch, but for the moment here is your patch, a little bit changed to draw the line.

* and I multiplied the calculation of "xy_smooth~" in the subpatch. With that I am not quite sure, if finally that won't be too much, but we will see...

So far, so good. I will see the next days, if this will give the result I need...

Thanks again, Nesa! Wish you all the best!

Hi Nesa!
Thanks a lot for your patch! Haha, the line is getting more and more clear and perfect!! Great, really!
I go on working now on the final patch, but for the moment here is your patch, a little bit changed to draw the line.
Changes:
* the line attribute
* "gllinewidth" for a "fatter" line
* "antialias", smooths also quite a bit
* and I multiplied the calculation of "xy_smooth~" in the subpatch.  With that I am not quite sure, if finally that won't be too much, but we will see...

So far, so good. I will see the next days, if this will give the result I need...
Thanks again, Nesa! Wish you all the best!
Johannes

Sorry for adding to the confusion, but did you check the frame-rate 

with my patch drawing the lines? It drops significantly, very fast, 

because with the (time)smoothing technique you get more lines drawn 

in less time, not neceseraly resulting in smoother line.

For example, with your last modification, you could be drawing very 

short lines from (1.0001 1.0001)->(1.0002 1.0002)->(1.0003 1.003), 

all up to (2. 2), instead of drawing one line from 1.0001 1.0001 to 

2. 2. So you might be needing some kind of data-reduction technique. 

Or, even better, drop xy-smooth~ from line drawing chain.

If you have time, you should check js_jitterspline-example.pat in 

jitter examples/render folder and see if drawing curves instead of 

The patch pasted below shows one method of data reduction, something 

like 'if the current point of line is very close to the previous, 

p.s.. After all this shooting in the dark, I can feel the trouble 

computer feels trying to do 'vision', without knowing anything about 

Sorry for adding to the confusion, but did you check the frame-rate  
with my patch drawing the lines? It drops significantly, very fast,  
because with the (time)smoothing technique you get more lines drawn  
in less time, not neceseraly resulting in smoother line.
For example, with your last modification, you could be drawing very  
short lines from (1.0001 1.0001)->(1.0002 1.0002)->(1.0003 1.003),  
all up to (2. 2), instead of drawing one line from 1.0001 1.0001 to  
2. 2. So you might be needing some kind of data-reduction technique.  
Or, even better, drop xy-smooth~ from line drawing chain.

If you have time, you should check js_jitterspline-example.pat in  
jitter examples/render folder and see if drawing curves instead of  
straight lines might be better for you.

The patch pasted below shows one method of data reduction, something  
like 'if the current point of line is very close to the previous,  
don't draw it'.

p.s.. After all this shooting in the dark, I can feel the trouble  
computer feels trying to do 'vision', without knowing anything about  
what's it looking at...

Sorry for posting that late, had a lot to do the last days...

Thanks for your new patch!! You're right, I recognized the frame-rate decrease.

But the lines are much more like curves in the first patch. When I change the threshold in your new patch, it's getting a bit better, but I prefer the result of the first patch for my work. Because in your new patch, the result is too "angled" for my presentation.

I will have a closer look on both patches again, maybe we could find a solution with both of them?

I already thought about js_jitterspline-example, but as I am not trained in javascript, I dont't understand the command in the patch :$...

What would you think about jit.gl.nurbs? If I would give him just 3 control_points and that in 2 dimensions....

I will have a look and keep you in loop, ok?

Hi nesa!
Sorry for posting that late, had a lot to do the last days...
Thanks for your new patch!! You're right, I recognized the frame-rate decrease.
But the lines are much more like curves in the first patch. When I change the threshold in your new patch, it's getting a bit better, but I prefer the result of the first patch for my work. Because in your new patch, the result is too "angled" for my presentation.
I will have a closer look on both patches again, maybe we could find a solution with both of them?
I already thought about js_jitterspline-example, but as I am not trained in javascript, I dont't understand the command in the patch :$...
What would you think about jit.gl.nurbs? If I would give him just 3 control_points and that in 2 dimensions....
I will have a look and keep you in loop, ok?
Thanks a lot, nesa!!
Johannes


I have to admit that I deliberatly choose to make new patch instead 

of changing your original one, because I did not plan to offer you 

solution(since I have no idea what is your final goal), but just some 

hints that might help you achieve it. So I just showed you some 

techniques, but it's still up to you to choose the best ones to reach 

https://cycling74.com/story/2006/2/14/161736/108

I have to admit that I deliberatly choose to make new patch instead  
of changing your original one, because I did not plan to offer you  
solution(since I have no idea what is your final goal), but just some  
hints that might help you achieve it. So I just showed you some  
techniques, but it's still up to you to choose the best ones to reach  
your goal.

Andrew Benson's recipe 17: twine ball
https://cycling74.com/story/2006/2/14/161736/108

Thank you very much for your help, really!! Due to you, I got much, much forward in my project!

Of course I understand, that you want to create new patches, who doesn't want to ;) ! After some time, I am quite sure to find the best solution for my patch.

If you want, I will send you my progress! In any case, I will go on posting to this forum, either to help with my (unfortunately) small experience or to ask for some ideas.

Thank you very much again for your help!!

Hi nesa!
Thank you very much for your help, really!! Due to you, I got much, much forward in my project!
Of course I understand, that you want to create new patches, who doesn't want to ;) ! After some time, I am quite sure to find the best solution for my patch.
If you want, I will send you my progress! In any case, I will go on posting to this forum, either to help with my (unfortunately) small experience or to ask for some ideas.
Thank you very much again for your help!!
Johannes


Clear out colours