[GRASS-dev] Testing i.superpixels.slic

[Moritz Lennert]

Hi Sophie !

On 01/03/17 15:59, Sophie Crommelinck wrote:
> Hello,
>
> thanks a lot for spending time and work implementing /i.superpixels.slic/.
> It was awesome to see how fast the ticket was addressed, in which I
> asked if someone would be interested in implementing this addon.
>
> I did some initial tests on a UAV orthoimage (Extent: 1000x1000m, GSD:
> 5cm) and unfortunately it delivered quite different results than a
> comparable Matlab implementation.
>
> What I did:
>
>   * i.superpixels.slic on parts of the RGB image with /num_pixels/ =
>     2500 and /compactness/ = 1
>   * i.superpixels.slic on parts of the RGB image with /num_pixels/ =
>     2500 and /compactness/ = 20
>   * i.superpixels.slic on parts of the RGB image with /num_pixels/ =
>     2500 and /compactness/ = 1 and /-n/
>   * I ran the matlab implementation with the same settings
>
> What I observed:
>
>   * i.superpixels.slic outlines rarely align with the road outlines in
>     the image.
>   * Numerous very small superpixels are created (especially for
>     /compactness/ = 1 and /compactness/ = 1 + /-n/). The total number of
>     superpixel is much larger than the one defined with /num_pixels/.
>     The output looks rather like that of a classical edge detector in
>     textured regions (see screenshots attached).
>
> My questions:
>   * Why does the number of superpixels not correspond to the one defined
>     in /num_pixels?/

You might have to increase the number of iterations. The default number 
of 10 is quite low.

Also, consider setting step instead of num_pixels.


>   * How can two implementations both based on Achanta et al. provide
>     such different results (screenshots attached)?/

i.superpixels.slic is based on the original Achanta et al C++ code, but 
it is not identical to it. Several choices were made based on the 
experience with our implementation and based on critical review of the 
original code.
The basic philosophy of the algorithm is the same. The concrete 
implementation is not.
I also have no idea if their Matlab code gives the same results as their 
C++ code...

The meaning of some parameter values is not exactly the same, notably 
compactness. The "compactness" indicator is a weighting criteria between 
the spatial and the spectral distance between a pixel and a superpixel. 
This value is somewhat arbitrary and it is treated slightly differently 
internally in i.superpixels.slic from its treatment in the original 
code. So, you cannot compare compactness=1 between the two implementations.

In addition, I think that the original code perturbs the location of 
original seeds by default. You might want to set the 'perturb' parameter.

In short: don't expect similar results using same settings. Just 
experiment with i.superpixels.slic until you get a satisfying result.

Also don't forget that in GRASS GIS you can input an

>     /
>   * The manual says: '/Contrary to the Achanta et al. version of SLIC0,
>     i.superpixels.slic takes into account the compactness value chosen
>     by the user even when the *-n* flag is used./' I understand SLICO as
>     a version of SLIC, for which the compactness//is adaptively refined
>     for each superpixel. To me, the purpose of SLICO seems to be that
>     the compactness does not need to be defined and that the superpixels
>     outlines are more regular-shaped. However, in the manual it sounds
>     as if -n would rather intend to favor irregular-shaped superpixels.
>     It is not clear to me, how the GRASS version relates to the usual
>     SLICO version.


Achanta et al use the following formula in SLIC for the distance between 
a pixel and a superpixel:

D^2 = (dc / N)^2 + (ds / S)^2

where dc is the spectral distance, ds is the spatial distance, S is the 
samplig interval (total number of pixels divided by number of 
superpixels) and N is the maximum spectral distance which varies from 
cluster to cluster. They decided to replace N by a constant m and thus 
change the formula into

D^2 = (dc / m)^2 + (ds / S)^2

which they rewrite to

D^2 = dc^2 + (ds / S)^2 * m^2

and they consider m as compactness (i.e. when m is high the spatial term 
ds/S gets more important than the spectral term dc^2)

In SLIC0, they then rewrite this to

D^2 = (dc / mc)^2 + (ds / ms)^2

where mc and ms are the "maximum observed spatial and color distances" 
of each cluster in the previous iteration.

However, that takes away the opportunity for the user to provide a 
weight of spatial vs spectral distance.

MarkusM thus decided to keep that option of determining a weight (the 
"compactness").

In i.superpixels.slic, the equation is always:

D^2 = (dc / m)^2 + c * (ds / S)^2

where S determined by the step and m is

- in SLIC: the maximum spectral distance observed amongst all clusters
- in SLIC0: the maxium spectral distance in each cluster separately.

I agree that one can argue about the question whether this 
implementation should still be called SLIC0, but it it sufficiently 
close to the original, while, IMHO, improving it, that I think that it 
still warrants the name.

Moritz