Describing superpixels

[Chintak Sheth]

@stefanv Yes, I'm reading up on some material by which I could have a
better and more memory efficient algorithm for flood fill. I'm definitely
interested in this.


On Mon, Apr 22, 2013 at 6:02 PM, Stéfan van der Walt <stefan at sun.ac.za>wrote:

> On Mon, Apr 22, 2013 at 11:55 AM, Juan Nunez-Iglesias
> <jni.soma at gmail.com> wrote:
> > It's very convenient to have direct access back to the pixels/voxels
> making
> > up each superpixel. Therefore, I stored on each node an array containing
> all
> > the linear indices into the `ravel`ed version of the image. This is
> pretty
> > expensive, though, so if could do it over, I would store the index of a
> > single pixel belonging to that superpixel and pair it with a flood fill
> > algorithm, so that a function `g.get_pixel_indices(superpixel_id)` would
> > transparently return the pixel list, but in O(superpixel_size) time while
> > only using up a singe int of space.
>
> Thanks for sharing that good advice. Juan.  There is also an
> intermediary storage format, one that I used before with some success.
>  Think of a 2-D example: you store the start and end indices of each
> column that comprises the object, paired with an index into the rows
> (very similar to CSR).  Perhaps it will be a bit painful to extend to
> N-d, but it is doable.
>
> Another option is to store a graph in an array.  This goes along very
> well with the implementation of ``graph.label``.  At each position in
> the array, you store the index of the previous pixel to which it is
> connected.  For any super-pixel, you can then store only the last
> pixel, and traverse indices backward to get the entire super-pixel.
> Con: 2 x storage.
>
> > Related note: does skimage have an nd implementation of flood fill?
>
> I think one of the recent PRs made an attempt at a 2D version called
> ``connected_component``, but otherwise no.
>
> Stéfan
>
> --
> You received this message because you are subscribed to the Google Groups
> "scikit-image" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to scikit-image+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20130423/82ad1869/attachment.html>