<div dir="ltr">Hello<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 19, 2016 at 5:30 PM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Rashad,<br>
<br>
Another reflection: IIUC, in the current implementation all pixel values from all bands are read into memory. This can quickly become a limiting factor when working with very large images.<br>
<br>
For now we can work this way until the general algorithm is clear, but in the long run, I imagine that the segment library should be used to only load parts of the data at a time.<br></blockquote><div>I had asked this question myself :-). <br> But then I don't know how to deal with large datasets in grass. I Couldn't find any method to allow streaming/tiled processing. That would be awesome!<br></div><div><br></div><div>I look forward reply from MarkusM for this.<br><br></div><div>Thanks again.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Maybe MarkusM help us with that ?<span class="HOEnZb"><font color="#888888"><br>
<br>
Moritz</font></span><div><div class="h5"><br>
<br>
On 19/12/16 16:05, Moritz Lennert wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
On 19/12/16 09:38, Rashad Kanavath wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Sun, Dec 18, 2016 at 2:53 PM, Moritz Lennert<br>
<<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a> <mailto:<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonl<wbr>ine.be</a>>> wrote:<br>
<br>
On 18/12/16 14:01, Rashad Kanavath wrote:<br>
<br>
Hello,<br>
<br>
As promised, I had pushed code to G7 addons repo<br>
<br>
<a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/b<wbr>rowser/grass-addons/grass7/ima<wbr>gery/i.superpixels.slic</a><br>
<<a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>browser/grass-addons/grass7/im<wbr>agery/i.superpixels.slic</a>><br>
<<a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>browser/grass-addons/grass7/im<wbr>agery/i.superpixels.slic</a><br>
<<a href="https://trac.osgeo.org/grass/browser/grass-addons/grass7/imagery/i.superpixels.slic" rel="noreferrer" target="_blank">https://trac.osgeo.org/grass/<wbr>browser/grass-addons/grass7/im<wbr>agery/i.superpixels.slic</a>>><br>
<br>
<br>
Great job, thanks a lot !<br>
<br>
<br>
I had tested with some small datasets and is working.<br>
<br>
More testing welcome :)<br>
<br>
<br>
I get the following warning during installation:<br>
<br>
main.c: In function ‘main’:<br>
main.c:514:13: warning: implicit declaration of function ‘min’<br>
[-Wimplicit-function-declarati<wbr>on]<br>
seedx = min(g_width-1,seedx);<br>
^~~<br>
<br>
I think you have to explicitely define min() through a macro, or<br>
AFAIK you can use fmin() as elsewhere in the code.<br>
<br>
<br>
I will push a fix for that.<br>
</blockquote>
<br>
Thanks, but your fix creates another error:<br>
<br>
main.c: In function ‘main’:<br>
main.c:514:18: error: expected expression before ‘double’<br>
seedx = fmin(double (g_width-1), seedx);<br>
^~~~~~<br>
main.c:514:13: error: too few arguments to function ‘fmin’<br>
seedx = fmin(double (g_width-1), seedx);<br>
^~~~<br>
In file included from /usr/include/features.h:364:0,<br>
from /usr/include/stdio.h:27,<br>
from main.c:21:<br>
/usr/include/x86_64-linux-gnu/<wbr>bits/mathcalls.h:360:1: note: declared here<br>
__MATHCALLX (fmin,, (_Mdouble_ __x, _Mdouble_ __y), (__const__));<br>
^<br>
make: *** [OBJ.x86_64-pc-linux-gnu/main.<wbr>o] Erreur 1<br>
<br>
as 'double' is not a function, so double(g_width-1)) doesn't make sense.<br>
<br>
If you want to cast g_width-1 to double before submitting it to fmin(),<br>
then AFAIK this would have to be:<br>
<br>
seedx = fmin ((double) (g_width-1), seedx)<br>
<br>
However, again AFAIK, this type conversion is done implicitely anyhow,<br>
so you can just write:<br>
<br>
seedx = fmin (g_width-1, seedx)<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Also:<br>
<br>
- The output as it is now is not very useful. What we would need is<br>
a map with each pixel containing the label of the superpixel it<br>
belongs to. In the original code, there are both outputs: i) an<br>
image of the superpixel limits overlayed over the original image,<br>
ii) the labeled pixels<br>
<br>
<br>
you need contour segments as seperate output and also the current one.<br>
right?<br>
</blockquote>
<br>
I don't know what you understand by 'contour segments'. What we would<br>
need would be an output similar to that of i.segment, i.e. each pixel<br>
having the id of the superpixel it belongs to (and there would be no<br>
specific boundary pixels).<br>
<br>
The current output is actually not useful at all for us, I think. It is<br>
used for visualisation purposes in the original software, but in GRASS<br>
we can just vectorize the superpixels if we want to display their<br>
contours on top of the original image.<br>
<br>
This means you can just get rid of the entire boundary detection part<br>
(lines 730-817 IIUC), and just output the klabels array to a map.<br>
Something like this seems to do the job (cf superpixel_id_output.png):<br>
<br>
int r, z;<br>
CELL *ubuff[nrows];<br>
for( r = 0; r < nrows; r++ )<br>
{<br>
ubuff[r] = Rast_allocate_c_buf();<br>
}<br>
<br>
z = 0;<br>
for (y = 0; y < nrows; y++)<br>
{<br>
for(x = 0; x < ncols; x++)<br>
{<br>
ubuff[y][x] = klabels[z]+1; /* +1 to avoid<br>
category value 0*/<br>
z++;<br>
}<br>
}<br>
<br>
outfd = Rast_open_new(result, CELL_TYPE);<br>
<br>
for (z = 0; z < nrows; z++)<br>
{<br>
Rast_put_row(outfd, ubuff[z], CELL_TYPE);<br>
}<br>
<br>
for (z = 0; z < nrows; z++)<br>
{<br>
G_free(ubuff[z]);<br>
}<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
- Linked to the above: currently the superpixel boundaries are two<br>
pixels wide. A one-pixel boundary would be enough.<br>
<br>
<br>
you can adjust no of superpixels with k. default now is 200<br>
</blockquote>
<br>
Yes, but this is not what I am talking about.<br>
<br>
Here's an example with the NC demo dataset:<br>
<br>
g.region rast=lsat7_2002_10 -p<br>
i.superpixels.slic red=lsat7_2002_30 green=lsat7_2002_20<br>
blue=lsat7_2002_10 iter=500 k=500 output=superpixels<br>
d.rgb red=lsat7_2002_30 green=lsat7_2002_20 blue=lsat7_2002_10<br>
d.rast map=superpixels values=1<br>
<br>
Then zoom in close, and look at the boundaries (see<br>
<a href="http://superpixels_large_boudaries.pn">superpixels_large_boudaries.pn</a><wbr>g attached). You can see that the boundary<br>
is at least 2 pixels wide. I would expect a one-pixel boundary to be enough.<br>
<br>
But this is actually not very important since, as mentioned above, the<br>
output with the boundaries is not really useful IMHO.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
- I don't know the details of the algorithm well enough, but would<br>
it be possible to extend it beyond the use of r,g,b maps as input.<br>
Ideally, the use should be able to provide a group as input and all<br>
maps in the group are used in the definition of the superpixels.<br>
This should also include the case when you only have one band (e.g.<br>
black and white orthophoto).<br>
<br>
<br>
I need help in understanding this part. because in code, it operates on<br>
lab color space. first it takes RBG and convert to LAB. This is reason,<br>
I had to put red,green,blue parameters.<br>
</blockquote>
<br>
I think that the authors come more from pattern recognition in images,<br>
and link that pattern recognition to human recognizable color space. And<br>
LAB color space is considered closer to human perception.<br>
<br>
After perfunctory reading of their technical paper and a glance over the<br>
code, however, I don't really see any reason why going through LAB color<br>
space would be necessary.<br>
<br>
I think you can just skip the whole translation to LAB space part and<br>
use as many bands as you wish. The only difference would be that you<br>
would use kseedsl, kseedsa, kseedsb, but as many kseedsN as you have<br>
bands (possibly an array of arrays with N arrays of seed arrays where N<br>
is the number bands), and spectral distance would be calculated not by<br>
<br>
dist = (L[i] - kseedsl[n])*(L[i] - kseedsl[n]) +<br>
(A[i] - kseedsa[n])*(A[i] - kseedsa[n]) +<br>
(B[i] - kseedsb[n])*(B[i] - kseedsb[n]);<br>
<br>
but through the equivalent for whatever number of bands you have.<br>
<br>
So, for me, the next steps would be:<br>
<br>
- implementation of id output as above<br>
- implementation of the algorithm using any number of bands (without<br>
going through the LAB color space)<br>
- implementation of user defined compactness, and, better yet, SLICO,<br>
i.e. automatic detection of compactness. More info and the source code<br>
of that are at the bottom of <a href="http://ivrl.epfl.ch/research/superpixels" rel="noreferrer" target="_blank">http://ivrl.epfl.ch/research/s<wbr>uperpixels</a>.<br>
<br>
<br>
Moritz<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br></div></div><span class="">
______________________________<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="http://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman<wbr>/listinfo/grass-dev</a><br>
<br>
</span></blockquote>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br> Rashad</font></div></div>
</div></div></div>