SLIC Superpixels on OpenCV

Standard

Sorry for the shilling, but here’s my upcoming project:

https://plusplusone.herokuapp.com

Please register your email address if you’re interested in it.


 

Here’s a sample implementation of SLIC (Simple Linear Iterative Clustering) Superpixel algorithm using OpenCV, C++, and Intel TBB. It’s an adaptation of Pascal Mettes’ version which you can find over here: https://github.com/PSMM/SLIC-Superpixels

Basically the rationale behind superpixels is that, normal pixel grid is an unnatural representation of image. When we view a scene with your eyes, we don’t visualise them as grids, but more like patches or splotches of similar colors. Superpixel is a way to represent those set of colour splotches in images.

The underlying algorithm is similar to K-means. While K-means try to find k number clusters throughout the whole image, SLIC superpixels tries to apply K-means on large number of clusters, but with smaller search region. Commonly superpixels algorithm is used to preprocess image before performing object segmentation.

Here’s some of the results of applying the algorithm, with 400 superpixel clusters

Screen Shot 2014-04-23 at 12.05.07

Original RGB image

Screen Shot 2014-04-23 at 12.05.11

Image in CIELab color space

Screen Shot 2014-04-23 at 12.05.20

Representation using average cluster colour, it’s hard to see, but look at the loss of texture

Screen Shot 2014-04-23 at 12.05.24

Visualizing the contours between the clusters

You can read the original literature on SLIC superpixels here: http://infoscience.epfl.ch/record/177415/files/Superpixel_PAMI2011-2.pdf

And here’s my implementation of SLIC superpixels algorithm using C++, OpenCV and Intel TBB:

https://github.com/subokita/Sandbox/tree/master/SLIC%20Superpixels/SLIC%20Superpixels

Advertisements

16 thoughts on “SLIC Superpixels on OpenCV

    • Sadly I’m a beginner in python / numpy. So it’s either you write a wrapper for the underlying C library, or deeply parallelize the algorithm.

      • Ian Decks

        Sorry I couldn’t explain in the beginning. The problem is that contours are too noisy in the visualization. But, I think I find the problem. “m” value is default “10”. I changed it to “40”. This time, I got my results like you, am I correct? Which m value used in your example?

      • I haven’t touched the code for awhile, now I remember that m is supposed to be gaussian smoothing factor used in CIELab space (standard deviation, if I recalled correctly in the SLIC code).

        For my example I used 10 for m. And yes, you’re supposed to tune the parameters to get your desired result.

      • ntraft

        Oh. I was just confused because he says his implementation “is created to work with the strutures of OpenCV.”

      • After checking his code again, I remembered. He was using the older OpenCV, thus all the cvMat types. I opted for the newer more object oriented OpenCV (e.g. cv::Mat). IIRC I already had something written in newer APIs, and don’t want to do all those conversions.

  1. gg99

    Hello, thanks for your code.

    Isn’t there a problem with that line (SLICSuperpixel::generateSuperPixels):
    for (int y = center.y – S; y < center.y + S; y++){
    Vec3b * ptr = image.ptr(y);

    if the center has been shifted to the left in the 3*3 local minimum search such that center.y-S < 0, then it results in bad (negative) indexing.

    • It will cause error if that’s the case.

      But the question is why would you want to have such a fine-grained super-clusters at first place, that it degenerates into more or less like conventional pixels?

      If the number of super pixels are not too high (e.g. 400 clusters for 800 x 500 image), then each super pixel has a coverage of 31 pixels, more than enough to move around in 3×3 neighbourhood.

      I mean, feel free to add the check on boundary conditions, but I wonder if it’s really necessary.

  2. gg99

    Hi Sub,

    Error doesn’t necessarily happen with fine grained superpixels (i.e it happens independently of S). Let’s take the case of the first superpixel (topleft), its center is initialized at (S,S) (one could argue it should be around (S/2, S/2)). The local minimum code can then cause it to be moved to e.g. (S-1, S-1), which causes trouble when it starts iterating with index: center.y-S = -1. Do you agree ?

    You are right that I should take time to fix this though.

    One thing I noticed is missing from the original paper is the connected component post processing part : I noticed non connected superpixels on some images I tried.

  3. Mak

    Hello, thanks for the nice work , please am using code blocks and I want to use your method how can embed your code, lib and the other stuff in my code block c++ project. thanks for the help.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s