I'm currently searching for optical flow code of all sorts (mainly implementations of algorithms), for the purpose of gathering them into a list, which can later be published in the form of a website.
Has there been any such effort before? If so, did it get anywhere?
Yes, Matlab/C++: http://people.csail.mit.edu/celiu/OpticalFlow/
CS UMD EDU: http://www.cs.umd.edu/~ogale/download/code.html
I found quite a few more references by Googling it.
Hope that helps.
Also see, CVPapers
Matlab/C++/ OpenCL-GPU Robust Local Optical Flow
Matlab C++ The FlowLib
C++/ Cuda GPU KLT+SIFT
Related
I want to build flash application that can detect the user eyes color and hair color etc'
Does anyone know about free library that I can use for this kind of project?
Thanks,
Perhaps you are looking for this library:
http://code.google.com/p/face-recognition-library-as3/
Never tried it myself, but this demo looks promising.
shaunhusain I think that you mistook face detection for face recognition although face-recognition-library-as3 enables both. Comments in source files of library are in Polish for now, but there is documentation in English available online for that library.
In answer to main question of this thread it should be possible to detect only eyes using this library. To do that you should replace HaarCascades in face.zip file to those for detecting eyes, which are part of OpenCV. To detect hair color you could detect face and then analyze pixels just above detected region with face.
Hope that helps.
This kind of visual processing is generally too intense to handle within the single thread and VM that AS3 provides, it's a task better suited to a language that compiles to machine code and has threading capabilities such as C or C++.
Here's something related to the topic, I believe you would be better off just trying to use OpenCV, but it should also contain the appropriate algorithms to port if you have the time and mental capacity to do so: http://www.quasimondo.com/archives/000687.php
Alternatively to avoid all the leg-work you may want to consider using a server side solution like http://face.com/
I have good knowledge of C++ but never dwell into STL. What part of STL I must learn to improve productivity and reduce defects in my work?
Thanks.
I have good knowledge of C++
With all due respect, but no – you don’t. The standard library, or at least large parts of it (especially the subset known as “STL”) is a fundamental part of C++. Without knowledge of it you don’t know very much about C++ at all.
In fact, much of the modern design of C++ (essentially everything since the 98 version) was guided by design considerations stemming from the standard library, and much of the changes in the language since then are changes to the standard library. If you take a look at the official C++ language description a good part of the document is concerned with the library.
Usually the first reaction (at least in my opinion, of course) for people who have not worked with the STL before is to get upset with all the template code. So I would start by studying a little bit on this subject.
In the case you already know template fundamentals I would recommend taking a brief look over an STL design document. This is actually the second stage of hassle for people not yet familiar with it. The reason for this is that the STL is not designed under a typical object oriented paradigm, but under the generic programming paradigm.
With this in mind, a good start could be this introductory article. The terms used throughout the STL components are explained there. Please notice that is a relatively old text focused on the SGI implementation (which predates the C++ standard and incorrectly mentions, for example, the hash based containers as part of it). However, the theory is still valid.
Well, if you already know most things I've said up to this point, just jump directly to the topcis the others provided.
You mention about improving your productivity and reduce defects. There are general guidelines that you can use for this. I assume c++11, and I mention a bit more than stl (smart pointers):
Use containers, they will manage memory for you. You get rid of new for C arrays and later having to delete them, for example.
For dynamic arrays, use std::vector. You also have hashtables in std::unordered_map and balanced trees with std::map. There are more containers, take a look here.
Use std::array instead of plain C arrays whenever you can: they never decay to pointers when passing as arguments to functions, which can avoid very disgusting bugs.
Use smart pointers and forget forever for a naked new and its matching delete in code.
This can reduce errors far more than you would expect, especially in the presence of exceptions.
Use std::make_shared when possible. You can use it to allocate a shared_ptr directly as an argument to a function that takes a std::shared_ptr. With a naked new this is not possible.
Use algorithms instead of hand-coded loops. The code will be far more readable and usually more performant.
With this advice your code should look closer (but not necessarily equal or semantically equivalent) to C# or Java, in which manual memory management disappears. This is even better than garbage collection in many scenarios, since you have deterministic guarantees for when a resource will be freed.
I'd say the algorithms from <algorithm> will really clean up your code and at the same time make your code more concise.
Obviously, knowledge of all the containers will help you to optimize the bottlenecks of your code caused by a certain choice of container which is not optimal (but be sure to profile first).
These are pretty much the basics and they will help you a lot to make more robust code.
After that you can delve into smart pointers like std::shared_ptr which are almost always better than regular pointers (in my case, at least).
I think can start with containers(vector, list) and alghorithms(binary search, sort).
And as Jesse Emond wrote, the more you know, the better you live)))
I have been struggling with an idea for a few weeks and wanted to see if someone can help me out here.
Programming today is full of abstractions, and people who do not understand the abstractions, do not truly understand the reason or design than went into building that abstraction/layer/framework and will struggle as soon as they step outside the comfort zone.
I was wondering if there is a learning resource that goes about teaching programming in an incremental fashion. This will lead to understanding the full stack.
take a small problem
implement a simple solution
talk about the the solution and the designs used
convert the solution into a framework or utility of some sort
now extend the problem space and repeat from step 2.
This way when someone then picks up any framework/library, they can easily visualize the problems the framework is trying to solve, the design decisions taken and the reasons thereof.
[Added to clarify the intent]
Based on the answers and comments below, I want to clarify that I want to move further up the stack. Building your own ORM to understand ORM better, same goes for ActiveRecord, IOC container, data binding, templating engine, and the host of other magic/glue/plumbing we use day-to-day.
Thanks.
Here's what I recommend : Have a brush with assembly (just one book or one month is enough). Have a good strong review of C++ (hopefully it will teach you some of C as well). Now the world is yours. Python is made in C/C++ , Object C is pretty close to c++, .NET is in C++ and C#/VB.NET , The windows API is oriented for C.
I picked C# as my abstract language of choice after this by the way.
Read the source. It is a good idea to build something you want to understand, but you can enhance your understanding of concepts significantly by looking at how something is built. This is especially true for infrastructure pieces (ORM/DI/Templating) which you seem to be interested in.
Get the software to build on your machine, attach a debugger and trace through the code. This is pretty easy for C#/Java with a good IDE. For dynamic languages like Python and Ruby, it takes a good editor and a lot of grepping.
If it is a good software package, it will usually have tests. Tests are a great place to start digging into code. They usually make clear the intent of the code, and also provide you a logical starting point to peel off the layers and actually peek under the hood.
Build a fully functional compiler from scratch in a systems language like C or C++. Maybe it isn't the full stack, but it's a large part of it. This is something I want to do as well. If only I could find the time and space.
The best example of the sort of learning resources I am seeking is the MIX session by Rob Eisenberg on "BUILD YOUR OWN MVVM FRAMEWORK". It goes step by step on explaining the pattern and also implementing it at the same time, attacking one problem area at a time.
http://live.visitmix.com/MIX10/Sessions/EX15
Hope there are more out there.
So I've spent the last few days looking for a way to create a simple image drawing app with wxPython, and I think the key to doing just that is understanding how to use Device Contexts. The problem is that the wxPython demo program doesn't demonstrate DCs, and the docs for both wxPython and wxWidgets don't explain as much as I'd like to know so I've decided to try and 'reverse engineer' an existing app to see how its done.
The first problem I have is that I don't know of any drawing apps written in wxPython (or any written in Python for that matter o.o), and the second is I don't know how I'd go about doing it. Am I right in saying that I'm going to need a copy of an application's Python source and something like Winpdb? What do professional programmers do when they find themselves in a situation like mine, needing answers that the docs don't provide?
If you need to understand the concepts, but the docs don't cut it, it's worth it to look at docs for similar APIs. In the case of drawing contexts, there are a lot of similar APIs in other languages. Java has Swing for instance.
Reverse engineering is easier in tools that aren't big event-driven GUI things. The converse is that event-driven GUI things tend to copy each other, so you only need to figure them out once or twice before they all make sense.
In .NET world, I have Reflector as indispensable tool.
In my company, we use to program SharePoint websites. There are many "gotchas" we just figure out by reverse engineering that product assemblies, exactly because documentation is plain wrong, just missing or simply doesn't exists.
I am designing software that needs to draw several different kinds of charts--bar charts, pie charts, flow charts/graphs, charts over time. I am looking for resources related to both the programming side of the issue as well as the UI/display side. Books, online resources would all be helpful. Thanks.
It does depend on the language a bit: here may be some pointers for you. Hope they help:
code.google.com/apis/chart/
home.gna.org/pychart
Practical C# Charts and Graphics
The Excel library can be imported by the Office API, but it does require you to have Excel installed.
Gnuplot
The grammar of graphics: book from the guy that wrote the plotting lib of spss. Somewhat theoretical, but nice xml treatment... gives you the graph xml schema for spss.
But I'm sure there are quite a few others that other people will know.
Do you have to draw it your self. If you want to save time (and probably money) then you can try embedding one of these into your apps http://code.google.com/apis/chart/
Ditto with Chris; If you are developing a new way of building charts, that's great!
Assumption: I have no idea of your needs but it would initially strike me (and thus form my assumption) that you are trying to develop a better charting software and that's usually interface.
Consider checking out the libraries in other programming languages that already do charting.
Adobe Flex/Air have one, PHP does, Java Does, .NET does.. etc.
Checking out the existing charing libraries for your language of choice helps a lot. In my case, it helped so much I decided not to write my own. ;)
For .net apps we settled on .netCharting, which can be pretty amazing.
The real lesson I took from it though, is this: there are way, way more kinds of charts than I thought there were, and I work with a lot of charts. Make sure you end up with something modular enough to handle clicking in new chart types / configurations with minimal effort.
You want to take a look at EyeSee.
http://moose.unibe.ch/tools/eyesee