Today we tested the bleeding edge with my Mac Pro tower running 10.7.x and were not able to get OpenCV to work with the USB camera I had plugged in. I know the camera works on the machine because it works with the Photobooth app. It is a Microsoft Lifecam HD. I was able to get OpenCV working with a MOV video file and with an IP camera as a input feed so it appears that OpenCV mostly works, just not with the USB camera. I have been able to compile OpenCV 2.4.3 and 2.4.7 outside of MRL and get the examples to work with the USB camera on this system but right now we're using JavaCV 0.6 which is paired with OpenCV 2.4.6(.1) which does have a known bug for Macs which might be what is hanging this system up.  I'm not planning to use this system with MRL for anything other than playing around or testing so I don't think it is worth spending a lot of time troubleshooting.

Tonight I tested the bleeding edge with my MacBook Pro running 10.8.5 and it's integrated "FaceTime HD" camera that is attached to the USB bus internally and it SUPA-WORKY!  The camera is a 1080HD camera so the capture image took over most of my high res display.  I used one PyramidDown filter and that brought the resolution to an uncrowded level. I used facedetect with each of the filters and all worked as expected. I wasn't able to get the PS3Eye camera to work with it using the OpenCV input or PS3Eye inputs from the pull down on the OpenCV tab.  That's not very surprising since the PS3Eye is not well supported on OS X.

When I'm not printing part of InMoov, I'll try to test my Kinect with the OpenCV stuff on OS X.

I am using the humblest system among other users... A win xp 32bit just because it is stable... have 2 systems on my pc, can be selected at boot... win 7 created me problems so i mostly use win xp on my robotics projects... I am not a performance guy so i am not also using my 64bit win7 notebook too... Just to wrap things up, I tested the new MRL build 1881 with all services loaded and can say that Tracking works much better now... more fps and more agile tracking especially if you set PID Kp to 10... only annoying thing is when I make a change in the python script, like, adding new setPID command, MRL tries to save that immediately and then the file may be saved with errors, that causes python errors when you try to reload the script from saved position later even with a fresh MRL... so be careful to copy-paste your running script to a different media such as Notepad++ or similar...  that is all I wanted to share...

I've got a paper for an online class due today by midnight, and I intend to get it off my plate first thing this morning.  I've got an Odroid setup similar to DJ's  (Linux image with ROS, OCV and ONI.)  I also have an Xtion Pro Live, and some generic USB cams. What do you need to know?

Also, my daily driver is a 32b Linux tower.  Maybe we can get that chart finished this weekend.

So the BBB ships with Angstrom Linux. There are Debian and Ubuntu distros available for it and even a version of Fedora supposedly.  The different distros may or may not have the NEON hard floating point support compiled in or not. I'm still poking around to find an easy way to test. Which version do we want to support for MRL?  If we want to support them all we might need to dig around to figure out which ones have hard/soft FP and how to check.  I think we can check the compiler flags that are set for the OS.  I've seen a few Google Group threads asking the question and various answers with different compiler flags to use to turn on hard FP. 

Here's one post about making a symbolic link to the right library fixing some issues.

https://groups.google.com/d/msg/beagleboard/hZ39EQr_tyk/Lj6qlUoKsfUJ

Theh post immediately after it lists the compiler flags.