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
[email protected]
http://imagej.net/mailman/listinfo/imagej-devel
_______________________________________________
ImageJ-devel mailing list
[email protected]
http://imagej.net/mailman/listinfo/imagej-devel
