|
openCV 2.0Hey, openCV 2.0 has just been released. I guess you developers already have an opinion on the subject. So, dya think this version will effectively behave as advertised: faster and easier ? How about the new IPP optimizations ? Is KnM planning to incorporate 2.0 lib is a future CVtools ?
|
2.0 was available when we were finishing up the public release of CVTools. I didn't do an exhaustive look at it, but I did actually spot check a few functions against the older 1.x to see if performance was measurably better (some of the hotspots in CVTools are for face detection and for optical flow, along with the ever present texture download cost that QC/GL imposes). Unfortunately, it wasn't any better (in many cases it was the exact same code). Some of the APIs likely changed (a drop-in of the code didn't compile, which is somewhat expected: FBXSDK doesn't usually work with kineme3d without tweaks too), though I don't know if it's an improvement or not.
While doing some auditing prior to the release, I spotted silly things like manually coded mem copies instead of using memcpy (on OS X, it's impossible to outperform memcpy for both fixed and variable sized blocks)) which I then replaced. There are no doubt many more silly things like that (it's coded by a bunch of college students, after all), but that sort of trend/practice doesn't build much confidence for me :/ I'll reserve a final "it's better/It's the same" declaration for when I've done more complete testing.
With CV in QC, a very large portion of the time (more than half) is spent in stupid texture downloads -- that's not CV's fault, and thus won't be addressed at all in 2.0, leaving a lot to be desired.
thanks for the precise answer. marketing .....
I'm working on a CV project (using OpenCV or possibly IVT) and was thinking of doing pretty much what you've done with CVTools. However, my focus is on stereo-vision and thus camera calibration and stereo correspondence functions, among others.
I was hoping you could elaborate on your evaluation of OpenCV+QC; you mentioned that a lot of time is spent transferring textures... Since you mention GL, I assume the transfer you're referring to is on a hardware bus (please correct me if I'm wrong), not transforming between APIs or some such. In QC, does it happen only at the initial capture stage, display/viewer stage, or at each QC connection? And other than the texture overhead, are there any major performance issues?
I was also wondering if you would release the source for the plugin. Given that QC performs well enough, I'm going to be writing a lot of stuff for it-- however I'd rather not duplicate your work if I don't have to.
Cheers, Will
i like the CMake system that is now integrated with openCV. it makes building much faster. it did take a couple of tries to build with open MP. openCV for qc seems to be working pretty good with this new release for me. yeah for haar. i'm working on making a haar kit for QC so classifiers can be built. just need to make some sort of converter to get the image format needed for haar training. i guess basically im making a the haar object marker program needed to mark up your photos. will definitely share when its finished. unfortunately it takes so long to produce the .xml needed to verify how the tracking works that i don't think i will be finished anytime soon.