Hey Alex Im getting the similar high CPU usage, i think its because you have enabled video in the OSC thats causing the major problems… I’ve tested your version with the Unibrain Fire-I as well as the Philips SPC900NC and Xbox360 Vision Cam… running them all at 640x480 i get the following results.
My results are similar to the ones above (Taha’s):
@ 640 x 480:
Built in laptop camera: ~7.5fps @ 35-45% CPU
Unibrain Fire-i: ~29.5fps @ 55-60% CPU
Philips SPC900NC: ~25 @ 50-55%
With older version(s) of touchlib I get (without fps calculator):
Built in laptop camera: 36% CPU (from the looks this about same fps as above)
Unibrain Fire-i: 36% CPU (from the looks this is 5-8fps slower than above)
Philips SPC900NC: 32-38% CPU (from the looks this is about 5-8fps slower than above)
These are my laptops specs:
Windows XP SP2
Intel Core2 Duo @ 2.2Ghz
4Gb RAM
OSC should be a lot faster if we turn debug mode off for OSC which is what shows the videos. In OSC, I generally get around 4-12% CPU (with the debug windows closed).
Alex, can you post the source? If anything we definitely need a toggle for FPS reader. Then we could have a better comparison between the your fixed version and previous versions in both CPU and fps.
Hey Alex Im getting the similar high CPU usage, i think its because you have enabled video in the OSC thats causing the major problems… I’ve tested your version with the Unibrain Fire-I as well as the Philips SPC900NC and Xbox360 Vision Cam… running them all at 640x480 i get the following results.
Windows XP SP2
Intel Core2 T2700 @ 2.00Ghz, 1.99Ghz
2Gb RAM
Could you perhaps post the source of your fix that would be awesome.
It is understandable that you are getting thid high CPU usage, since you are processing frames that are 640x480. I doubt that merly displaying the video frames costs much, although if you don’t have separate video card it could. The reason why I turned this on the display in OSC is because it would not run without it. I didn’t want to spend too much time debuging it. It could have been my machine as well.
Your CPU is T2700 which is on the low-end side, so ~50% is realistic number for this. Try capturing at 320x240 and see the difference.
The older version of TouchLib, does not have a fixed blob tracking frame rate, since processing run asynchronously to the capture, so you would definitely get lower CPU usage, but your frame rate would be lower as well. If this is acceptable to you, try running this older TouchLib version.
I will look into removing the video in the OSC app, and post the new version soon. This will hopefully reduce your CPU usage.
Well on the laptop i have a discrete gfx card its a ATI Radeon X1400 with 512MB… and my processor is a core2 duo its not like is a P4 HT or anything and its like a year old only, i wouldn’t think it would cause the cpu to be this high though cause using reactvision or V4 the cpu load isnt this high and with reactvision im getting the full 30fps as well.
Well on the laptop i have a discrete gfx card its a ATI Radeon X1400 with 512MB… and my processor is a core2 duo its not like is a P4 HT or anything and its like a year old only, i wouldn’t think it would cause the cpu to be this high though cause using reactvision or V4 the cpu load isnt this high and with reactvision im getting the full 30fps as well.
How do you know that reactvision is actually processing blobs at 30fps?
As I said, the camera capture frame rate and blob processing rate are not necessarily one and the same.
In my version they are the same, assuming that you have a machine that is fast enough to process everything in real-time.
This was the main objective of my fix - to make the blob processing/tracking frame rate not limited by the TouchLib blob processing sleep delay.
Ohh ok thanks, i understand what you mean now… i’m planing on buying a new computer soon for this what would you say i buy any recommendations… on the what CPU to get?
Alex, it seems as if the CPU is running at the max it can (kind of like opengl I think) which may be do to not sleeping at all. CPU isn’t really a good way of judging performance though. FPS is a much better judge. Would you say the CPU thing might just be misleading? It seems high CPU issues in applications that have no limit on FPS of the application is a popular issue actually. Just the other day I saw someone mention high CPU in processing since they didn’t limit the FPS of their application.
Would it be possible to set the sleep rate to the rate of the max FPS of the camera? Therefore, instead of running touchlib as fast as it can run while only processing on a new frame, we can sleep at a rate that matches the cameras FPS. That’s just a thought and something I’m hoping to do with the new openframeworks version of touchlib.
I have a 8600 gt graphics card. It’s a mobile card, but definitely not like onboard video. My computer is also faster than taha’s with more ram, yet we have similar results. I can test this on a desktop quad core next week possibly. You previously said you were getting 110fps around 15% CPU on a relatively ‘normal’ computer. Although that was at 320 x 240, my 320 x 240 results are still above 30-40fps on all cameras. It’s lower, but considering it’s only doing 30fps vs 110fps, it would seem the CPU would be below your 15%.
Although the old touchlib stuff is processing at a lower fps, it’s not a drastic difference for cameras that run around 30fps. Maybe instead of running at 30fps, they run around 22-25, but also the CPU is about 15-20% lower in configapp. Turning the video drawings off (debugmode set to false) generally decreased CPU from 10%+ which is why we had turned it off in OSC in the later version releases.
Is it possible to get the class change you made to add FPS processing calculator. I can then compile a version with the older touchlib so we can benchmark the difference.
Alex, it seems as if the CPU is running at the max it can (kind of like opengl I think) which may be do to not sleeping at all. CPU isn’t really a good way of judging performance though. FPS is a much better judge. Would you say the CPU thing might just be misleading? It seems high CPU issues in applications that have no limit on FPS of the application is a popular issue actually. Just the other day I saw someone mention high CPU in processing since they didn’t limit the FPS of their application.
Would it be possible to set the sleep rate to the rate of the max FPS of the camera? Therefore, instead of running touchlib as fast as it can run while only processing on a new frame, we can sleep at a rate that matches the cameras FPS. That’s just a thought and something I’m hoping to do with the new openframeworks version of touchlib.
I have a 8600 gt graphics card. It’s a mobile card, but definitely not like onboard video. My computer is also faster than taha’s with more ram, yet we have similar results. I can test this on a desktop quad core next week possibly. You previously said you were getting 110fps around 15% CPU on a relatively ‘normal’ computer. Although that was at 320 x 240, my 320 x 240 results are still above 30-40fps on all cameras. It’s lower, but considering it’s only doing 30fps vs 110fps, it would seem the CPU would be below your 15%.
Although the old touchlib stuff is processing at a lower fps, it’s not a drastic difference for cameras that run around 30fps. Maybe instead of running at 30fps, they run around 22-25, but also the CPU is about 15-20% lower in configapp. Turning the video drawings off (debugmode set to false) generally decreased CPU from 10%+ which is why we had turned it off in OSC in the later version releases.
Is it possible to get the class change you made to add FPS processing calculator. I can then compile a version with the older touchlib so we can benchmark the difference.
I t agree with you that CPU usage is not a good measure of performance.
Of course people would like this to be low, but in reality there are so many factors invloved.
You probably misunderstood me what I was trying to do. The TouchLib with my fix does not run as fast as it can. This would mean that blob processing is running async to the camera frames. This is exactly how the old code worked (with addition of sleep to limit the blob processing frame rate and consequently the CPU usage).
What I did is simply synchronized the blob processing rate ot the frame capture rate, with a minimal amount ot latency between them.
Of course that the CPU goes to sleep between the video frame blob processing. But this sleep is now linked to the camera and not fixed like before.
This is why now the blob processing can run at the came rate as the camera captured frames (ie. 110fps).
// video capture thread
while(true)
{
Wait_for_camera_frame()
Capture_frame()
Signal_blob_tread_frame_captured()
}
The Wait_for_video_frame_from_the_camera() waits on the event that is pulsed every time camera captures new frame by calling Signal_blob_tread_frame_captured(). For blob processing thread this is effectively equivalent to calling sleep().
So now this whole thing translate to synchronised producer-consumer implementation.
I’ll post the FPS calculator code here when I get the chance, so you can add it to the unmodified TouchLib code.
Would first of all like to say thanks for your speedfix, when using my desktop it’s great, really responsive. On an older laptop though, CPU usage is high and I would also like to be able disable the video in OSC to save on this. Shutting each new window down manually is a drag, and also occasionally causes a software crash. Can this be done?
Hi, i finally got my pt grey cameras, but installing them using the flystream drivers on my system and the speedfix only gets me 15fps. i’ve modified the dsvl config file from 30.0 tio 60.0 but still only 15-16fps in the output window. anybody else with this issue? i’ve searched around and haven’t found the answer yet, apologies if this has already been answered
i’m using vista 32 sp1 and keeping it at 640x480
thanks
I’m brand new and just starting my MT project. Planning on a FTIR setup first. (The firefly MV will work with a FTIR setup? sorry for the ignorance.)
Wondering if a higher framerate will decrease latency even further, or will it just increase cpu usage? I was looking at the Dragonfly Express @320 fps at ptgray.com.
