On Mon, Apr 22, 2013 at 11:55 AM, Juan Nunez-Iglesias
<jni.soma@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@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.