Hi Moritz, 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.
@ 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: https://share4land.itc.utwente.nl:5566/sharing/fS3tbiWuW Thanks again, Sophie 2017-03-01 16:45 GMT+01:00 Moritz Lennert <[email protected]>: > 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. > 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. > > 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 > Where did the rest of the sentence go? > > / >> * 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 > > _______________________________________________ > grass-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/grass-dev >
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
