[ImageJ-devel] Irregular CellContainers?

[Lee Kamentsky]

On 3/5/2013 4:09 PM, Johannes Schindelin wrote:
> Hi Curtis & Tobias,
>
> I woke up last night having an idea I would like to hear your input on:
> one of the problems I see with CellContainer is that very often, you
> actually need not single pixels, but neighborhoods. So whenever you access
> neighborhoods at the margin of a cell container, you need to have the
> neighboring container in memory, too. It gets worst in corners, e.g. when
> you are in a corner of a 3d cube and need to have all neighboring pixels
> in a, say, 3x3x3 neighborhood, you will need 8 cubes.
>
> So how about having a cell container strategy where you do not slice up
> the complete RandomAccessibleInterval in equally-sized cubes, but into
> cubes smaller by a given margin and then "boxes" to fill the rest of the
> original cubes?
>
> Example: let's take a 16k x 16k x 4k volume, the current CellContainer may
> cut it into 1024 x 1024 x 1024 cubes. If we know that we want to work on 3
> x 3 x 3 neighborhoods, I now propose to cut further every such cube into a
> 1021 x 1021 x 1021 cube, a 3 x 1021 x 1021, a 1021 x 3 x 1021, a 1021 x
> 1021 x 3, a 3 x 3 x 1021, a 3 x 1021 x 3, a 1021 x 3 x 3 and a 3 x 3 x 3.
Hmmm.... not so bad. An alternative might be to make the cubes bigger by 
3 on each side, duplicating the data and use a dirty-flag strategy to 
tell the alternate pixel owners to copy the overwritten data, e.g. when 
switching cubes. I think there's less pixel-operation checking in that case.
>
> That would allow us to require only one big cube (with relatively good
> performance opposed to smaller cubes) and a couple of smaller cubes at any
> time during convolution?
>
> Ciao,
> Dscho
>
> P.S.: I am not proposing to work on this now, but we could put it into
> http://fiji.sc/Project_Ideas?
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
> http://imagej.net/mailman/listinfo/imagej-devel