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. 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
