Last year came with a heavy agenda. Lots of public events took place during the year. I participated with my ClubElek team-mates at 3 different exhibitions and 4 different contests.

Exhibitions

Mondial des Métiers, in Lyon, France

Takes place early February at Lyon, France. Syntec Numerique invites ClubElek every year to share a glimpse of informatics’ career paths to young students and to explain them why computer science is so cool.

Innorobo

Takes place every year around mid-March at Cité Internationale, Lyon, France. A great place to meet robotics enterprises from all around the world such as iRobot Corporation and Aldebaran Robotics. I can say without fear that our robot wasn’t as cute as NAO the humanoid robot from Aldebaran. But hey! Ours is not plastic made!

Industrie expo

Takes place every 2 years in Lyon, France. It is by far the largest exhibition I’ve ever been. I can’t recall the number of times I got lost in between ~800 exhibitors and  almost 17 thousand visitors. INSA de Lyon and ClubElek stood along high-profile companies such as ABB, Areva, Dassault Systèmes, Siemens, … It was a great honour to showcase the outcome of my computer vision project in this expo.

Contests

All 4 contests I took part this year were Chess Up related, they were all based on the competition rules I announced last year.

ArcerlorMittal robotics contest

This contest was sponsored and organized by ArcelorMittal and took place at their Metz Research Center, France.

It was a great opportunity to test our robot and to discover the company from the inside-out. We visited their research facilities and enjoyed their excellent meals. We didn’t win the competition. However, we won the Jury Prize for the best presentation to the Jury where we explained how our robotics club is organized. The prize: spend the night in a beautiful Chalet. Sauna included. Awesome!

ClubElek robot during a performance at ArcelorMittal 2011 contest. Image Credits Facebook coupeAM2011

Rhônes Alpes Robotics Cup

Better known as “La Coupe Rhône Alpes” in France. It is a robotics contest organized by ClubElek which takes place during the “world-wide” known event called Les 24 heures de l’INSA, at INSA de Lyon, France.

It is a special contest where teams show their robots off to the public and learn how others have solved the same challenges. The best part of it: the BBQ offered by ClubElek at the end of the day. Yummy!

French robotics cup

It was the beginning of June when a bunch robots and their fanatical developers grouped together at La Ferté Bernard to participate at the most important robotics challenge in France: La Coupe de France de Robotique. Our team Clubelek was obviously present. We had built a very compelling robot and we all had very high hopes on to what it could achieve, however (or should I say as usual ^^), the robot faced a lot of small problems that took a huge time end effort to solve, so we weren’t exactly sure if it was going to be able to do everything we planned it to do.

Actually, everything went bad the first few matches against the other robots. Fortunately, we got very good scores in the end; therefore, we got an entry pass to the sixteenth-finals! Call it luck, preparation, hard work or whatever you’d like but we managed to get into the podium after several other matches!

The video of the last match that gave us our beloved 3rd place (Our robot is the one at the top red square) :

Eurobot

As you might already know, being either the 1st or the 2nd best French team, you get to participate at the European robotics contest called Eurobot. And because BHTeam, the 2nd French team, desisted to go, ClubElek got its free ticket to Eurobot 2011 in Russia. Last year’s Eurobot took place in Astrakhan, Russia.

Russia was a great experience, I got to meet lots of beautiful places and people, tasted new flavours and even learned some new words like привет! All while showing off our little robotics creation. Crazy stuff!

Saint Basil's Cathedral, Moscow, Russia.

Projects

My 2 main ClubElek’s projects in 2011 were:

1. A new A* based pathfinder library. A refactor of something I had already done last year but faster and more user/developer friendly.
2. The second project was even more incredible. To give artificial vision to the robot.

I also did a summer internship in Atos Worldline where I worked with great people and with some new fancy mobile technologies.

In all 2011 was an amazing year !

Happy 2012!

Let’s do a summary of what we have done so far:

• COT: colour thresholding. We separated yellow objects from the rest.
• BLED: blob edge detection. We retrieved the bottom edges of blobs (pawns).
• T: transformation. We transformed the image’s pixels into game field points (aka. pixels to meters).

And the last step CID: Circles Detection.

As you may have already noticed, pawns and tower of pawns are in fact circles when viewed from above. Therefore, the bottom edges we found with BLED are also circles’ segments when transformed into game field coordinates (step T). This is the property we’re exploiting below.

Algorithm

The secret here is to find the centre of the circles defined by the transformed edges. Then, we need to remove those which lay outside the game field, and finally we should merge those circles which are too close to each other.

Transform the bottom edges to field coordinates.
For each bottom edge
  Retrieve the 2 points that are the farthest from each other (The longer the edge, the more precise the centre is likely to be) :
    pLeft  = beginning of the bottom edge
    pRight = end of the bottom edge
  Given two points and the circle's radius (pLeft, pRight, r), find the circle's centre c

Remove any circle placed outside the game field

If any circle c overlaps any other circle c' then
  merge the circles' centre by averaging their positions with the means of a weighted mean to increase precision. The weight being the length of the edge.

Finding a circle’s centre is just a matter of solving for given 2 points , and the radius .

It can be shown that the centre of the circle is given by:
where

This equation has 2 solutions but only one gives the expected result. To choose the right sign, check whether and go counter-clockwise if yes the the sign should be . In our case we go counter-clockwise because the points are always given from left to right.

Results

The original image:

The binary thresholded image:

The bottom edges:The transformed bottom edges with the circles rendered on top of them:

The final render :

Discussion

We presented a simple yet effective method for finding circles’ centres. This is evidently not the only way of finding them, the more usual approach is by using Hough Cirlce Transforms. However, our method is much faster and does not have any special memory requirements as it is not probabilistic and requires only two points, and because the radius is known, high precision is achieved.

Another method we tried was the Least-Squares fit by R. Bullock, which gave pretty much the same results with a sightly heavier computational approach. The advantage of this last method is it uses all points from the edge to compute the circles’ centre, this may give better results when the first or the last points of the edge are not correctly found and have an offset. Practically this case rarely happened because pawns, which are yellow, have a very different colour from their entourage which is usually red, blue, green or black, and therefore pawns’ bottom edges are usually correctly determined.

What’s next

The fancy algorithms end here. Yeap, sorry about that. No more maths for today.

A conclusion and a summary of what has been done, what could be improved and what I have learned on the next post.

With the last step we know where the bottom edges of the pawn are located on the image, we just need to find a way to transform the coordinates of those pixels into game field coordinates.

Given a point from the Image plane, we’d like to transform it into from the Game field plane. We can write:

We observe that straight lines are kept straight, thus H is called the homography matrix which can be computed if at least 4 different matching points are given for both planes.

It’s worth noticing that both  and  points are given in homogeneus coordinates.

Algorithm and code

1. In order to compute H, the homography matrix. We use the ready to use openCV’s function: findHomography.

// Create a column vector with the coordinates of each point (on the field plane)
cv::Mat xField;
xField.create(4, 1, CV_32FC2);
xField.at(0) = ( cv::Point2f(x1, y1) );
xField.atPoint2f>(1) = ( cv::Point2f(x2, y2) );
xField.atPoint2f>(2) = ( cv::Point2f(x3, y3) );
xField.at(3) = ( cv::Point2f(x4, y4) );

// same thing for xImage but with the pixel coordinates instead of the field coordinates, same order as in xField
cv::Mat xImage;
xImage.at(0) = ( cv::Point2f(x1_bis, y1_bis) );
...

// Compute the homography matrix
cv::Mat H = cv::findHomography( xImage, xField );

2. Whenever we want to find the coordinates of a point on the game field, given a pixel on an image. We only need to transform into :

// pImage = p'(x,y)
// pImage is in the projective plane
cv::Mat pImage = (cv::Mat_(3,1) << x, y, 1);
cv::Mat pField = H * pImage;
// pField is in the projective plane (homogeneous coordinates): (X, Y, W). Transform it back to the euclidean plane: (X', Y', 1)
pField        /= pField.at(2);

// p(xField, yField) represent the same point as p'(x, y) but in different planes.
double xField = pField.at(0);
double yField = pField.at(1);

Optimizations

Because (2) is used really often we can avoid doing matrix products during run time by pre-calculating all possible transformations of the image. All game field points corresponding to every pixel of the image are computed in advance and saved into an bi-dimensional array for efficient access. To correlate  to  we do:

p = pixelsToMeters.at(p')

Just for fun

Using the pixelsToMeters array we can print the area the camera sees of the field:

What’s next

You guessed right we now have the full ‘tool-kit’ to precisely link pawns on the image to their positions on the game field plane. How to do it is the subject of the next post.

There is still too much information we do not need on the B&W image we got on the last step. That’s why we need to extract the features we do need. One way of accomplishing this is by performing a connected component analysis in binary images, aka blob labelling. However as you’ll will see, this method is not completely adapted to our needs, so a new approach is proposed: Blob Edge Detection.

First approach : blob detection

cvBlob is a nice library that has many interesting functionalities such as: binary labelling and features extraction, blob tracking and contour detection. It is powered by openCV under the hood.

In the beginning of the project I wondered whether this library would be useful for what we were trying to accomplish. I ran some tests and even though the binary labelling approach proposed by cvBlob was good and very fast, it wasn’t good enough. By using their approach we could have only found the position of single pawns. For instance, the following image uses cvBlob and shows some pawns being correctly recognised, each pawn is labelled with different colours.

Problems appeared in more complex situations where several pawns were labelled as a single pawn or where a pawn was labelled twice. The following image shows a group of 3 and 2 different pawns being labelled with the same colour pink and green respectively. This behaviour is caused because those pawns are connected and form a single blob on the binary image (not shown) and thus are labelled with the same colour.

The other problem with this method was that some pawns were detected twice. The following image shows a pawn at the right bottom corner being labelled twice (pink and purple) due to the fact that the pawn on the binary image is composed of 2 separate blobs.

In order to achieve better object detection results, a more robust algorithm was implemented.

Algorithm

The main idea behind the algorithm is to separate tower of pawns or single pawns from other pawns. One way of doing it is by searching and labelling blobs’ bottom edges.

1. Find the blobs’ bottom edges

Take the B&W image
for every column of the image do
  for every row
    if the pixel is black and the N previous pixels above it are white
    and if the black gap after the current pixel is big enough then
        mark the pixel as being a bottom edge of a pawn
    end if
  end for every row
end for every column

2. At this point we have a set of pixels P that belong to the bottom of pawns. They are however scattered throughout the rows. The next step is to regroup those pixels by pawns as much as possible. This means to check whether a pixel p from P belongs to the same bottom edge of a given pawn.

Take the set of pixels P that belong to the bottom of pawns
P(1) being the set of pixels P whose column is 1
Create a new list of bottom edges for every pixel p belonging to P(1) and add every p as a first element to them
for every column c of the image, starting with the 2nd one
  for every set of pixels p in P(c)
    if p is near any other pixel w in P(c - 1) then
      add p to the list where w is located
    else
      create a new list of bottom edges
      add p to the list
    end if
  end for set of pixels
end for every column

3. Now we have a list of bottom lines L, each containing a list of pixels that belong to the bottom of a pawn or a tower of pawns. Unfortunately some contiguous lines do not belong to the same pawn. The following image shows an example of such kind of errors.

This has to be fixed otherwise we’ll be unable to find the right position of the pawn. The following algorithm fixes this problem.

for every bottom line l of L
  if the line l has a spike, split l at the spike
end for

Results

The algorithm’s output for the B&W image shown at (1) is shown in the following rendering. Every bottom line l from (L) has been coloured differently to better show the result of the algorithm. A similar approach has been applied to detect the upper edges of the pawns.

As you may see, any one line belongs to the bottom of one and only one pawn. The reciprocal is not true: two or more lines might belong to the same pawn. This is not a problem as you’ll see later on.

Discussion

Advantages

The advantages of the BLED algorithm are :

• Tower invariant: tower of pawns are not special cases, they are treated and located as if they were single pawns.
• Faster than a simple labelling algorithm: the algorithm is faster because only blobs’ bottom edges are connected and labelled. Whereas the other algorithm connects all pixels of a blob.
• Noise resistant

Optimizations

The algorithm in (1) is slow because its searches every pixel of every row of the image. One way of optimizing it is by searching every T rows for white to black changes where T is the minimum gap size between two blobs to be considered different blobs. Once a colour variation is found, search down the image to precisely detect where the white to black change happens. This optimisation is somewhat similar to the idea behind pyramids but without the aliasing nor the copy of image data overhead.

Disadvantages

• The current algorithm cannot find the height of towers.
• Pawns that are exactly behind other pawns are simply ignored and not found.
• If an object, such as a robotic arm, is placed between the camera and the middle of a tower of pawns, the algorithm might consider the tower as being two different pawns at different positions.

Other approaches

In order to detect the pawns’ edges, we could have simply used the more common Canny Edge Detector. However, we might have needed to use morphological operations on the image before applying the edge detector, to reduce the heavy noise inherent to the previous colour thresholding step. Moreover, this approach would have found all edges: bottom, upper, left and right of a pawn. A second step would have been necessary so as to extract the bottom edges only, which may be far too complex to do. In summary, by using the Canny Edge Detector we would have added too much of an overhead.

What’s next

We now know where the pawns are on-screen, but how does that help us to know where they are on the game field ? That’s the whole point of the next post : Transformation.

Images are usually too complex to be treated by computers as is. In most cases, they have to be enhanced and simplified before any algorithm can be applied on them. Fortunately for us, the rules of the contest specify that yellow is the colour of pawns and figures we are looking to detect.

Generally speaking, the purpose of Colour Segmentation is to extract information from an image by grouping similar colours. In our algorithm, we implemented colour segmentation by thresholding yellow colours, that is to say, the computer builds a black and white image from the original image where white colour represents yellow colour and black is everything else. This is called colour thresholding.

The problem is, as you may have already guessed, the notion of “yellow” colour. For humans, it is relatively easy to tell whether a colour belongs to a group of colours, but for computers this is a whole different story.

Colour spaces and thresholding

Computers work with a limited set of colours, which are usually represented by three additive components Red Green and Blue, RGB for short. All these colours can be represented inside a cube called the RGB Colour Space which, in computer vision, is very difficult to work with. Mainly because colours tend to change too much from a given point A to any other point near of it. There is no “easy” way of telling whether a point B belongs to a group of colours due to the fact this subset is not easily represented using cartesian coordinates. In other words, in this space it is very difficult to say whether a given colour C is pink, or yellow, or even orange.

For instance the following next 2 images represent, in RGB colour space, all colours which are present in the previous image. As you may see, it is impossible to find a simple shape (such as a smaller cube or a cuboid) that fully envelops all yellow colours.

This is one of the reasons why the HSV colour space exists. In this space, colours are represented and organized more like the human eye interprets them, in group of colours. HSV stands for Hue, Saturation an Value and is represented by a cylindrical coordinate system. In this space, many colours such as yellow, are much more easily thresholded because colour segments or subsets may be approximated by “pies” which are easily expressed in polar coordinate systems: .

For the same image as above, the HSV transformation gives :

Look how colours may be segmented with different azimuth and radius values.

Nevertheless, as you might have noticed, a single pie is a bit too rough of an approximation of the yellow colour subset. That’s why we used up to three different “pies” at different levels to better threshold the image.

Algorithm and code

OpenCV, has done must of the hard work as it can transform colours and threshold them. The code is pretty straight forward :

// Convert the image into an HSV image
cvtColor(originalImage, hsvImage, CV_BGR2HSV);

// Threshold the hsv iamge
cv::Mat binaryImage;
cv::inRange( hsvImage, cv::Scalar(hueMin, satMin, valueMin),
                       cv::Scalar(hueMax, satMax, valueMax),
                       binaryImage);

The threshold was repeated up to 3 times with different min and max values to better approximate the yellow set. Unifying the image into a single B&W image was done with help of cv::bitwise_or.

Results

In short the algorithm transforms an image from RGB to HSV and then thresholds it several times and merges them into a single black and white image :

Input :

Output :

Discussion

Noise

The output binary image has a lot of noise and many objects that are not inside the game field still appear on the image.

We could have used a combination of  dilate and erode filters to reduce the small noise (cf. Closing filter, Noise Reduction), but we decided to leave the image as is and do the filtering in a later step to increase performance.

The objects that are outside the game field aren’t a problem, as they are rejected later on.

Lightning

Another problem we faced was the high illumination variations which resulted in a change of tones and even colours themselves. Even though, the HSV colour space is more robust against lightning variations than the RGB colour space, it is not robust enough as well as many other factors such as lens and cameras’ sensors affect them.

Our solution was to calibrate colours to find the best thresholding values before running the COTBLEDTCID algorithm.

You should better understand the problem with the following images : yellow colours are completely different from one image to the other, even for the human eye. When looking at their HSV representation, we can see a slight yellow HSV variation from the first image to the second one. This variation, even though it is small, is too much of a difference for both images to be sharing the same thresholding values.

NB : these 2 pictures were taken with different cameras. That’s why colour distribution is so different. But, hey. You got the point right ?

Other approaches

Colour segmentation is a very well-known problem in computer vision. Many papers have been written on this topic. We could have certainly used a more robust algorithm to detect homogeneous colours such as the one described in this paper. This could have removed the need of constantly doing colour calibrations but would have certainly added a non negligible overhead when separating yellow colours from the rest. As one of our functional requirements was performance, a statical colour model was better suited for our needs.

What’s next

In this step the computer still does not know much about what we’re looking for, nor about the image it’s viewing. In the next post I’ll explain the algorithm that will help the computer understand a bit more about its environment.

About the colour space visuals

All renders were made with ColorSpace. Many thanks to Colantoni Philippe for such an useful software.

A fancy acronym that stands for the process of COlour Thresholding, Blob Edge Detection, Transformation and CIrcle Detection used for locating 3D objects on a plane. The next series of posts will explain the software algorithms used by ClubElek on 2011 to achieve computer vision. The problems we faced, the solutions we implemented and most importantly what we have learned by doing this project.

These posts are targeted to a wide audience with some background in maths and preferably some background in computer vision. Mostly because there are some maths and magic behind the algorithms used, but I’ll try to keep them as simple and clear as possible. Should you have questions or remarks do not hesitate to comment !

This software was designed to detect “pawns” and “figures” defined by the Eurobot 2011 rules and was demoed during “Industrie Lyon” from 5 april to 8 april 2011. Before continuing reading this post you should read the summary about the rules of the contest so you don’t get lost.

Besides the 5 previously mentioned steps, 2 other steps were necessary before attempting any computer recognition: terrain calibration and colour calibration. These 2 processes will be explained on separate posts as they are far more complex than the COTBLEDTCID itself.

After the pawns’ positions had been detected by the means of COTBLEDTCID, they were sent wirelessly to the robot through a XBee connection.

Additional requirements

• The software should be used in a real-time environment. The fastest the algorithm, the better.
• The software should be easy to use and fast to configure. (Teams have only 1 minute and 30 seconds before a match to completely set up the robot and its peripherals).

Hardware set-up

• A Fit-PC-2 disk-less and fan-less computer running a customized ubuntu version controlled through ssh.
• 3 identical Microsoft LifeCam Cinema webcams. Why 3 cameras should you ask. Well, during a match, there are two robots that constantly move around the table and obfuscate large parts of the terrain, with 3 cameras chances are we see most of the objects on the playing table at any time.

Assumptions made

• Light intensity remains constant during the match and after calibration.
• The cameras do not move during the match.

Both assumptions resulted to be inaccurate but did not affect the result as the detection and pose estimation algorithm is fairly robust.

Shiny pics

What the computer sees (note that the robot’s game field wasn’t entirely finished by the time):

What the computer understands: (compare the pawns’ position in both images. You may use the red top corner or the black area at the bottom of the image as a reference)

It’s fairly accurate isn’t it ?

What’s next

In the next section I will explain how the Colour Thresholding works and why we need it (COT for short).

For instance, let’s say you have a webcam that can run at HD resolution ( 1280 x 720 px ), you can use the opencv’s class cv::VideoCapture to get the frames but you’re going to have a hard time on getting the full resolution out of your device.

To sort out this problem, one could use specialized libraries. The disadvantage :  they’re not usually multi platform so you’ll find yourself writing classes for every platform where you’re camera device operates.

Theo  developed a very useful video capture library for windows called videoInput.

You can find the sources here, and the old site here.

This library is already used internally in opencv and can be found somewhere in the source code. However, I find it easier to copy all necessary files into a 3rd party folder and configure the project using those files and cmake.

In this post I will show you how to easily interface the videoInput library with OpenCV. The project is functional but incomplete. Feel free to modify it and to use it as inspiration for your own projects.

I Files organization

The root folder is organized in two subfolders :

• 3rdParty :
  • VideoInput/DShow : includes all libs used by VideoInput library itself.
  • VideoInput/include : contains the header that will be used in our project.
  • VideoInput/videoInputLib.a : the precompiled VideoInput lib to be linked to our project.
• src :
  • CameraWindows.cpp : the camera class that uses VideoInput as its backend.
  • CameraWindows.h :  the class header.
  • main.cpp
  • CMakeLists.txt : the configuration file for our project.

II Software architecture

The CameraWindows class manages all the camera functions and settings. The constructor initializes all camera properties, there is a method to fetch new frames from the camera, a method to get the previously captured frame and the destructor which disconnects the device and frees up all resources.

class CameraWindows
{
public:
	CameraWindows( const int deviceNb = 0, const int width = 1024, const int height = 720);
	bool fetchNewFrame();
	cv::Mat &getFrame();
	virtual ~CameraWindows();

protected:
	videoInput mVideoInput;
        ...
	unsigned char * mBuffer;

	cv::Mat mFrame;
        ...
};

The constructor implementation uses videoInput :

CameraWindows::CameraWindows( const int deviceNb, const int width, const int height ) :
	mDeviceNb ( deviceNb )
{
	...
	// Setup device with video size and connection type
	mVideoInput.setupDevice(mDeviceNb, width, height, VI_COMPOSITE);

	// As requested width and height can not always be accomodated
	// make sure to check the size once the device is setup
	mWidth = mVideoInput.getWidth(mDeviceNb);
	mHeight = mVideoInput.getHeight(mDeviceNb);
	mSize = mVideoInput.getSize(mDeviceNb);

	// Create the buffer where the video will be captured
	mBuffer = new unsigned char[mSize];

	// Disable autofocus and set focus to 0
	mVideoInput.setVideoSettingCamera(mDeviceNb, CameraControl_Focus, mDefaultFocus, CameraControl_Flags_Manual);

	...
}

The key point here is the use of getPixels method that will write what the camera sees into the buffer. Then if everything goes smooth, we proceed to create an image using the buffer and finally we pass that image on to the frame.

bool CameraWindows::fetchNewFrame()
{
	//fills pixels in buffer as a BGR (for openCV) unsigned char array - flipping
	bool success = mVideoInput.getPixels(mDeviceNb, mBuffer, false, true);

	if( success )
	{
		cv::Mat image( mHeight, mWidth, CV_8UC3, mBuffer );
		mFrame = image;
		return true;
	}
	else
	{
		std::cout << "Error loading frame from camera (Windows)." << std::endl;
  		return false;
  	}
}

The program displays the camera contents in a window until a key is pressed.

int main( int argc, char** argv )
{
	CameraWindows camera;

	cv::namedWindow("camera");
	 
	for( ;; )
    {
        if ( camera.fetchNewFrame() )
        {
        	cv::imshow("camera", camera.getFrame() );
        }

        if( cv::waitKey(30) >= 0 )
		{
        	break;
		}
    }
	
	return 0;
}

And the CMakeLists.txt file. It might be a bit hard to understand if you’re not used to cmake.

# Project properties
SET( projectName cameraWindows )
PROJECT( ${projectName}_PRJ )
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)

# OPENCV
FIND_PACKAGE( OpenCV REQUIRED )

# VIDEOINPUT
FIND_PATH( VIDEO_INPUT_INCLUDE videoInput.h ${CMAKE_CURRENT_SOURCE_DIR}/../3rdparty/VideoInput/include )
FIND_PATH( VIDEO_INPUT_LIB_DIR videoInputLib.a ${CMAKE_CURRENT_SOURCE_DIR}/../3rdparty/VideoInput )

link_directories( ${VIDEO_INPUT_LIB_DIR}/DShow )

INCLUDE_DIRECTORIES( ${VIDEO_INPUT_INCLUDE} )
INCLUDE_DIRECTORIES( ${VIDEO_INPUT_LIB_DIR} )

SET( VINPUT_LIB ${VIDEO_INPUT_LIB_DIR}/videoInputLib.a )
SET( VINPUT_LIB2 ddraw dxguid ole32 oleaut32 strmbasd strmbase strmiids uuid )

# EXECUTABLE
ADD_EXECUTABLE( ${projectName} main.cpp CameraWindows.cpp)

TARGET_LINK_LIBRARIES( ${projectName} ${OpenCV_LIBS} ${VINPUT_LIB} ${VINPUT_LIB2} )

III Setting up the CMake project

As usual launch cmake and fill in the blanks. If you’re using eclipse don’t forget to indicate whether you’re using debug or release mode (CMAKE_BUILD_TYPE) and to link it with the correct opencv  ( OpenCV_DIR ).

Then you can open the project cmake created for you. Double click the solution file if you’re using visual studio, or import the project to your workspace if using ecplise.

IV Final Words & Links

VideoInput is very useful but I find it is poorly documented. Fortunately it is open source. You can see for example that the method setVideoSettingCamera(…) in VideoInput.h does not describe the properties nor the values you can use to set up the camera.
By looking at the code, you will discover the function uses IAMCameraControl internally which is well documented here. That is how I discovered how to disable the autofocus of the camera (used in this example).

PS : if you didn’t notice you can easily modify the code of main.cpp to use multiple cameras and multiple resolutions

The project source files can be found here.

Voilà. I hope this post will help you getting started using advanced features of your camera.
Comments, remarks and questions are highly appreciated.

The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 9,000 times in 2010. That’s about 22 full 747s.

In 2010, there were 12 new posts, growing the total archive of this blog to 33 posts. There were 17 pictures uploaded, taking up a total of 21mb. That’s about a picture per month.

The busiest day of the year was November 29th with 69 views. The most popular post that day was Start coding with OpenCV and VS2010 in no time.

Where did they come from?

The top referring sites in 2010 were en.wordpress.com, sfml-dev.org, planete-sciences.org, facebook.com, and reddit.com.

Some visitors came searching, mostly for sfml tutorial, sfml game tutorial, sfml tutorials, sfml games, and sfml game.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Start coding with OpenCV and VS2010 in no time October 2010
5 comments and 1 Like on WordPress.com,

Your first SFML game, Part IV: The main loop August 2009
2 comments

Your first SFML game, Part I : Introduction August 2009
2 comments

Your first SFML game, Part II : The board August 2009
3 comments

Your first SFML game, Part III: The User Interface August 2009

The first one was originally made to recruit new members for the ClubElek’s team. It was later modified to be part of a CD we offer to our sponsors. I really think the video made it’s purpose as there’s a troop of new people coming each week to our chamber of secrets ( also known as the ClubElek’s cave)

The second video was made just for fun . It’s an assemble of a recorded match made of three different angles.

Now go get some popcorn, take your favourite seat and enjoy ! (PS: Sorry if you don’t completely understand the first video because the text is in French).

Fortunately CMake has made this a really easy step. You only create the CMakeLists.txt file where your project properties reside and CMake does the rest.

In this tutorial I’ll try to explain how to get up and running in no time with OpenCV and Visual Studio 2010.

First we’ll install OpenCV from the SVN repository and then we’ll create a Visual Studio project with the help of CMake.

A – Installing TortoiseSVN

If you’re unfamiliar with Version Control software you might not know that SVN helps you maintain revisions of your code. It’s like creating multiple backups of your project.

In windows, TortoiseSVN is the default utility for SVN. To install it :

1. Go to TortoiseSVN downloads site and choose the right version for you.
2. Follow the Installer instructions.

B – Installing CMake

1. Grab the CMake Windows Installer.
2. Follow the Installer instructions.

I – Grabbing the latest version of OpenCV from SVN

A simple way of doing this, based on the official Installation Guide :

1. Go to the Folder where you want to download the sources. i ex. “C:\Libs”.
2. Right click and choose “SVN checkout” from the Context Menu.
3. Fill in the URL : “https://code.ros.org/svn/opencv/trunk”.
4. Choose your checkout directory, for instance “C:\Libs\opencv”.
5. Click OK. It should start downloading the sources.

II – Creating the config files with CMake

CMake will create the necessary files to build the OpenCV sources with your favorite compiler. In our case, we’ll be using Visual Studio 2010 :

1. Open CMake (cmake-gui).
2. Choose the source code path ( Where you downloaded OpenCV ). i. ex. “C:\Libs\opencv”
3. Choose the output directory ( Where to build the binaries ). i ex. “C:\Libs\opencv\vs2010″. Click Yes to create the directory if doesn’t exist.
4. Click on the Configure button.
5. Choose the compiler/IDE you want to use. In this case, choose Visual Studio 10. And leave the default native compiler active unless you have a reason not to.
6. Choose the options you want to use. Such as Build Examples, build doxygen docs, etc.
7. Click on the Configure button until all the conflicts are resolved ( all red lines change their color to white).
8. Click Generate.
   

III – Building OpenCV

We’ll now proceed to build openCV with Visual Studio 2010.

1. Open the Solution file located in the binaries directory. i. ex. “C:\Libs\opencv\vs2010\OpenCV.sln”
2. Wait until all the files are completely loaded.
3. Press F7 to build the Solution.
4. That’s it .
   

IV – Creating a Project for Visual Studio

The following instructions are based on the OpenCV page Getting Started.

1. Create a directory for your project. i. ex. “C:\Projects\myFirstOpenCvTest”
2. Add the following C++ file to the directory. Name it “main.cpp” :
   

   #include <cv.h>
   #include <highgui.h>
   
   int main ( int argc, char **argv )
   {
   // Create a window to show the image
   cvNamedWindow( "My Cool Window" );
   IplImage *img = cvCreateImage( cvSize( 300, 100 ), IPL_DEPTH_8U, 3 );
   
   double hScale = 1.0;
   double vScale = 1.0;
   double shear  = 0.0;
   int lineWidth = 2;
   
   // Initialize the font
   CvFont font;
   cvInitFont( &font, CV_FONT_HERSHEY_SCRIPT_COMPLEX, hScale, vScale, shear, lineWidth );
   
   // Write on the image ...
   CvScalar color = CV_RGB( 0, 51, 102 );
   cvPutText( img, "Hello World!", cvPoint( 60, 60 ), &font, color );
   
   // ... and show it to the world !
   cvShowImage( "My Cool Window", img );
   
   // Wait until the user wants to exit
   cvWaitKey();
   
   return 0;
   }
   

3. Create the “CMakeLists.txt” file, don’t forget to use the real name of your project :
   

   SET( PROJECT_NAME project_name_goes_here )
   PROJECT( ${PROJECT_NAME} )
   CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
   FIND_PACKAGE( OpenCV REQUIRED )
   ADD_EXECUTABLE( ${PROJECT_NAME} main.cpp )
   TARGET_LINK_LIBRARIES( ${PROJECT_NAME} ${OpenCV_LIBS} )
   

4. And let the magic of CMake do its trick :
   • Open CMake and choose as the source directory the directory where you have the main.cpp and the CMakeLists.txt file.
   • Follow the same steps as in II (Creating the config files with CMake).

V – Testing your project

1. Open the Solution file of your project, located in the vs2010 directory.
2. Press F7 to build it.
3. In the Solution Explorer, right-click the name of your project/ Debug / Start new instance.
   You should see your Hello World text appear.
   

You now have a fully configured VS2010 – OpenCV project.

A piece of cake, wasn’t it ?

As a matter of fact. This procedure can easily be translated to almost any ide/compiler.

Questions and remarks are appreciated.

Eclipse IDE for C/C++ Developers