<div dir="ltr"><div><div><div>Hi Moritz,<br><br></div>thank you for your extensive answer! Your reply was very clear and solved most of my questions, I added two comments in your mail below.<br><br></div><div>@ Vaclav Petras: You asked to provide the data as well. I uploaded the part of the orthoimage shown in the screenshots to the same folder:<br><span class="gmail-im"><a href="https://share4land.itc.utwente.nl:5566/sharing/fS3tbiWuW" target="_blank">https://share4land.itc.utwente<wbr>.nl:5566/sharing/fS3tbiWuW</a></span></div><br>Thanks again,<br><br></div>Sophie<br><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2017-03-01 16:45 GMT+01:00 Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sophie !<span class="gmail-"><br>
<br>
On 01/03/17 15:59, Sophie Crommelinck wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hello,<br>
<br>
thanks a lot for spending time and work implementing /i.superpixels.slic/.<span class="gmail-"><br>
It was awesome to see how fast the ticket was addressed, in which I<br>
asked if someone would be interested in implementing this addon.<br>
<br>
I did some initial tests on a UAV orthoimage (Extent: 1000x1000m, GSD:<br>
5cm) and unfortunately it delivered quite different results than a<br>
comparable Matlab implementation.<br>
<br>
What I did:<br>
<br></span>
* i.superpixels.slic on parts of the RGB image with /num_pixels/ =<br>
2500 and /compactness/ = 1<br>
* i.superpixels.slic on parts of the RGB image with /num_pixels/ =<br>
2500 and /compactness/ = 20<br>
* i.superpixels.slic on parts of the RGB image with /num_pixels/ =<br>
2500 and /compactness/ = 1 and /-n/<br>
* I ran the matlab implementation with the same settings<br>
<br>
What I observed:<br>
<br>
* i.superpixels.slic outlines rarely align with the road outlines in<br>
the image.<br>
* Numerous very small superpixels are created (especially for<br>
/compactness/ = 1 and /compactness/ = 1 + /-n/). The total number of<br>
superpixel is much larger than the one defined with /num_pixels/.<span class="gmail-"><br>
The output looks rather like that of a classical edge detector in<br>
textured regions (see screenshots attached).<br>
<br>
My questions:<br></span>
* Why does the number of superpixels not correspond to the one defined<br>
in /num_pixels?/<br>
</blockquote>
<br>
You might have to increase the number of iterations. The default number of 10 is quite low.<br></blockquote><div><br></div><div>I also tested increasing the number of iterations to 100. This resulted in a lower number of tiny superpixels, but still some superpixels are far away from being equally shaped compared to the rest. Also this resulted in a processing time of several hours. I didn't check the effect of changing step instead of num_pixels. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Also, consider setting step instead of num_pixels.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How can two implementations both based on Achanta et al. provide<br>
such different results (screenshots attached)?/<br>
</blockquote>
<br>
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.<br>
The basic philosophy of the algorithm is the same. The concrete implementation is not.<br>
I also have no idea if their Matlab code gives the same results as their C++ code...<br>
<br>
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.<br>
<br>
In addition, I think that the original code perturbs the location of original seeds by default. You might want to set the 'perturb' parameter.<br>
<br>
In short: don't expect similar results using same settings. Just experiment with i.superpixels.slic until you get a satisfying result.<br>
<br>
Also don't forget that in GRASS GIS you can input an<br></blockquote><div><br></div><div>Where did the rest of the sentence go?<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
/<br>
* The manual says: '/Contrary to the Achanta et al. version of SLIC0,<span class="gmail-"><br>
i.superpixels.slic takes into account the compactness value chosen<br></span>
by the user even when the *-n* flag is used./' I understand SLICO as<br>
a version of SLIC, for which the compactness//is adaptively refined<span class="gmail-"><br>
for each superpixel. To me, the purpose of SLICO seems to be that<br>
the compactness does not need to be defined and that the superpixels<br>
outlines are more regular-shaped. However, in the manual it sounds<br>
as if -n would rather intend to favor irregular-shaped superpixels.<br>
It is not clear to me, how the GRASS version relates to the usual<br>
SLICO version.<br>
</span></blockquote>
<br>
<br>
Achanta et al use the following formula in SLIC for the distance between a pixel and a superpixel:<br>
<br>
D^2 = (dc / N)^2 + (ds / S)^2<br>
<br>
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<br>
<br>
D^2 = (dc / m)^2 + (ds / S)^2<br>
<br>
which they rewrite to<br>
<br>
D^2 = dc^2 + (ds / S)^2 * m^2<br>
<br>
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)<br>
<br>
In SLIC0, they then rewrite this to<br>
<br>
D^2 = (dc / mc)^2 + (ds / ms)^2<br>
<br>
where mc and ms are the "maximum observed spatial and color distances" of each cluster in the previous iteration.<br>
<br>
However, that takes away the opportunity for the user to provide a weight of spatial vs spectral distance.<br>
<br>
MarkusM thus decided to keep that option of determining a weight (the "compactness").<br>
<br>
In i.superpixels.slic, the equation is always:<br>
<br>
D^2 = (dc / m)^2 + c * (ds / S)^2<br>
<br>
where S determined by the step and m is<br>
<br>
- in SLIC: the maximum spectral distance observed amongst all clusters<br>
- in SLIC0: the maxium spectral distance in each cluster separately.<br>
<br>
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.<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
Moritz</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/grass-dev</a></div></div></blockquote></div><br></div></div></div></div></div></div>