[GRASS-dev] [GRASS GIS] #3142: Implementing SLIC image segmentation

[GRASS GIS]

#3142: Implementing SLIC image segmentation
---------------------------+-------------------------------------
  Reporter:  SCrommelinck  |      Owner:  grass-dev@…
      Type:  enhancement   |     Status:  new
  Priority:  normal        |  Milestone:  7.2.0
 Component:  Imagery       |    Version:  unspecified
Resolution:                |   Keywords:  SLIC image segmentation
       CPU:  Unspecified   |   Platform:  Unspecified
---------------------------+-------------------------------------

Comment (by mmetz):

 Replying to [comment:7 mlennert]:
 > Replying to [comment:6 rashadkm]:
 > > Replying to [comment:5 mlennert]:
 > > > Replying to [comment:4 rashadkm]:
 > > > > Replying to [comment:3 mlennert]:
 > > > > > After some discussion with MarkusM, I see three options, all
 based on the source code published at
 [http://ivrl.epfl.ch/research/superpixels], which is GPL3:
 > > > > >
 > > > > >  * Integrate the code as is into GRASS. Disadvantage: it's C++
 and we would have to maintain it. Advantage: code exists, so less work, we
 would "only" have to write the GRASS io wrapper
 > > > > >  * Translate the original code to C and integrate into GRASS.
 Disadvantage: more work, we have to maintain; Advantage: no C++, no
 installation by user, native implementation in GRASS
 > > > > >  * Write a GRASS module that calls the compiled command line
 tool. Disadvantage: the user would have to install and compile the code.
 Advantage: less work for us, others maintain
 > > > >
 > > > > mortiz,
 > > > > the second option seems better than others. right?
 > > >
 > > > I personally would prefer it, yes, but it means more work and
 someone has to do it. Are you volunteering ? :-)
 > > I am interested to work.. given help from all grass devs ;).
 >
 > Well, maybe not all, but I'm willing to help, and we should definitely
 have MarkusM on board.

 I am on board. SLIC(O) is an interesting method, and I would be happy to
 help with the implementation. I would also prefer the second option, even
 if it means more work, but the result might be more stable/portable.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3142#comment:9>
GRASS GIS <https://grass.osgeo.org>