Introducing ccv, a modern computer vision library
libccv.org
libccv.org
sudo apt-get install clang libjpeg-dev libpng-dev libfftw3-dev libgsl0-dev libblas-dev liblinear-dev libblas-dev
cd bin/
makelibgsl and liblinear are required for all the training programs (bbfcreate, dpmcreate). libfftw3 can help with dpmdetect performance.
Naturally, there are advantages and disadvantages to both approaches.
Computer vision task is very different, from, for example, a game engine. From engineering perspective, computer vision tasks are very functional. You throw an image to it, get some semantic information out of it, and done. The only objects there are images, and it is boring (Really? You need a inheritance relationship between different type of images? Tell me what's the behavioral difference!). Thus, object-oriented style is not the best abstraction for this kind of task at all. However, C++ is all about object-oriented programming! (and it is really useful for game engines, where you actually have a lot different objects and interacting with each other).
(Then here is the question, how to support different types of image? From the people I talked with, it seems to me the general conscious is to use generated code no matter you use c or c++. Generated code can be type safe, and still very fast. Effectively, this is what template does for OpenCV and macro does for ccv, although, both approaches are not the best.)
Take the end result, it is easy to use OpenCV's new interface (if you are familiar with Matlab), but hard to hack in. OTOH, it does provide quite a lot algorithms for you to experiment with, but then, if you need to write something new (the end goal of experimentation after all), it is really not an easy undertaking.
ccv takes a different path. Don't experiment with it, use it in your application, trust the underlying implementation is the best-of-its-kind, and you will be happy.
That really depends on how you use the language. Looking at the code I normally see there's almost no inheritance, but lots of static polymorphism through templates. Data tends to be stored in structs, tuples and the default data structures (vectors, mostly), and a lot of use is made of the new lambdas and the functional bits of the STL.
I know that you can write Java in C++ (and that many people do), but it's not really the language's raison d'être.
On their github page, COPYING has a licence ( https://github.com/liuliu/ccv/blob/unstable/COPYING ). Looks BSDlike
You can use patent algorithms if you have proper license, but it shouldn't forbidden various implementations from ground up. (however, you can form the argument that the implementation is dedicated to violate the patent rights, thus, should be responsible as well).
As always, software patent is a bch. Without a court trial, no one knows the exact answer.
http://megawave.cmla.ens-cachan.fr/
the library design is a bit dated but the code contributions are outstanding!
Does anyone else recognize this? Has it been rigorously treated? Seems like a similar approach to more applications in general using bagwell tries would be useful for both scala and clojure.
It is quite used in the research community, with new algorithms coming soon (check this: http://eccv2012.unifi.it/program/tutorials/modern-features-a...).
Their documentation is very nice, and back then when I implementing linear MSER for OpenCV, I learned a lot from their semilinear MSER implementation.
But, I never understand why they want to mimick object-oriented interface in their implementation. Especially, their abstraction strikes me as "weird". Each algorithm implementation is an "object" to encapsulate some intermediate data, or to retain some parameter settings? It is a far stretch to what these computer vision algorithm does.
In my mind, computer vision algorithms are functions, which takes image/image sequence in, and emit semantic information out. Reusable intermediate data should be implementation detail, it shouldn't overshadow how the interface looks like.
Sorry if I am acting too opinionated on this topic, I am too passionate about good interface design.
Keeping the "status" of the algorithm in an object gives the following advantages:
- The interface encourages cleaner code: computer vision algorithms often come with many parameters. One has to use his own data structure, or many variables or constants to keep them in memory, and then call a function with a very long signature. This produces not so clean code, and the long signature could lead to mistakes in the parameter values. Using an object with get/set functions make easier to define in an iterative manner the parameters and call the function in a clean an less error-prone way.
- Many computer vision algorithms are iterative. For this kind of algorithms, having an object representing the status of the algorithms allows to stop/restart/continue it easily. The possibility to check the convergence of certain algorithms is vital in computer vision (SVMs for example).
You are right when you say that implementation details shouldn't interfere with the interfaces. But vlfeat doesn't have a general "extractFeatures" function, it implement different famous algorithms. So it makes sense to assume that if one uses SIFT, have a basic knowledge of how it works and prefers to exploit it at its best (in the documentation you can find basic information of any algorithm anyway).
So I think the two library are different, libccv focus on those developers that want to use computer vision algorithms without a deep knowledge of them, while vlfeat requires the developer to have a proper computer vision knowledge, but gives more power to him.
Cool though, looks good.
Suggestion for liuliu: list supported platforms in your Readme - it may save you some email. And it seems you're targeting Macs from all the Xcode comments.
If you're seriously asking, and this isn't some kind of internet meme/joke I'm not familiar with, you might find it interesting and instructive to have a look at the datasheet of the AtMega328[1], the chip an Arduino Uno uses, and compare it to, say, what you might find in a typical intel desktop machine.
Just as one crude scalar comparison to illustrate the sort of differences, the atmega328 doesn't have the ability to do floating point operations in hardware , so you have to emulate them in software using the core's fixed point hardware (the toolchain will do this for you). This means potentially hundreds of cpu cycles per floating point operation. In the past i have managed to get an atmega328, at 16Mhz, to perform about 60,000 floating point multiplications per second. According to the wikipedia[2], a 2010 Intel Core i7 cpu can do about 109 billion floating point operations per second. That's nearly 2 millions times the speed!
If you want something of arduino size and arduino price, that will let you play with machine vision, the Raspberry Pi might be far more useful to you.
Finally, I'm not saying you can't do CV on an 8-bit embedded micro, I have done some in the past myself, but it's a very different and far more limited beast to what most people would understand as modern CV and required in my case an great deal of hand optimisation and gory bit-hacks.
[1] http://www.atmel.com/devices/atmega328.aspx [2] http://en.wikipedia.org/wiki/FLOPS [3] http://www.raspberrypi.org/
But Arduino also has the upcoming Arduino Due which is based on a 32bit ARM Cortex M3, which still may be powerful enough. I guess I would revise my question to be would it be possible to get this (or something similar) running in the Arduino Environment, regardless of speed (without a full OS stack)?
all of this is just speculation based off of what i found googling the chip on it, and then the libccv might not even fit on the 512kb flash it has for the program you put on it.
my thought would be, bight the bullet and go with a raspberry pi or something like that for doing image processing, faster cpu, more ram, and you could hook it up to something like the arduino due, to do other logic, and have the due ask it questions like, "where is the ball" etc.
source: http://www.linkedin.com/groups/Arduino-Due-featuring-Atmel-A...
"The APC’s spec includes a VIA WonderMedia ARM 11 processor at its core, 512MB DDR3 RAM, 2GB of on-board flash storage, 4 USB 2.0 ports, a microSD slot, Ethernet port, and both VGA and HDMI display ports. As for power consumption, it tops out at 13 watts under load and 4 watts when idle."