[ImageJ-devel] Irregular CellContainers?
leek at broadinstitute.org
Tue Mar 5 15:24:46 CST 2013
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?
> P.S.: I am not proposing to work on this now, but we could put it into
> ImageJ-devel mailing list
> ImageJ-devel at imagej.net
More information about the ImageJ-devel