On Wed, Jun 19, 2013 at 12:13 PM, Stephan Preibisch <preibi...@mpi-cbg.de>wrote:
> Hi Lee, > > I think that sounds useful ... can you explain exactly how you want to > implement it? It seems like it could work on and return a > RandomAccessibleInterval on which one can instantiate RandomAccesses. There > could be even two implementations of it. One that precomputes it and one > that always computes it on the fly, just when the RandomAccess actually > queries a value. > > What do you guys think? > > Internally, there's a seperable convolution which means that, for an N^dim kernel, you have O(N * dim) operations per pixel instead of O(N^dim) operations, but you need scratchpad memory to accumulate the result. I'm putting the computational logic into a class, Kernel1d, that holds the kernel for the convolution and I'm supplying methods to calculate the value at a single point and to use an IterableInterval over the source data to calculate the intermediate 1d convolutions on a scratchpad RandomAccessible or RandomAccessibleInterval. public <T extends NumericType<T>> void reduce(IterableInterval<T> src, IterableInterval<T> dest, ImgFactory<T> factory); There are several flavors of methods that use this, but I think the one that I will end up using in my plugin is: public <T extends NumericType<T>> RandomAccessibleInterval<T> reduce(Img<T> src); which will use the factory of src to create a scratchpad Img for intermediate calculations and for the output image. One neat thing is that it should automagically work with Img<ARGBType> ooo score one brownie point for a good design Stephan. I won't use it, but I'll probably figure out an easy way to generate a RandomAccessibleInterval, given a source RandomAccessible and a destination. Also, since it uses a kernel, the pixels along the output's border are undefined. The method I plan to use returns an interval defined only over valid pixels, but a dogged and misguided user should be able to use some out of bounds strategy to get bogus pixel values along the border. > Cheers, Steffi > > On Jun 18, 2013, at 11:32 , Curtis Rueden wrote: > > Hi Lee, > > > Do people think that these have enough utility to add to imglib2 (and > > where should they go?) or is it more appropriate to keep them within > > the project itself? > > How about in algorithms/core? (Or if GPL licensed: in algorithms/gpl?) > > Package prefix: net.imglib2.algorithm.somethingOrOther? (I leave the > choice of "somethingOrOther" to you since I know how much you love naming! > ;-) > > What do others think? > > Regards, > Curtis > > > On Tue, Jun 18, 2013 at 10:25 AM, Lee Kamentsky > <l...@broadinstitute.org>wrote: > >> Hi all, >> As part of an upcoming project, I'm planning to implement the methods >> described in >> >> Unser, The L2 Polynomial Spline Pyramid, IEEE Transactions on Pattern >> Analysis and Machine Intelligence, Vol 15 # 4, April 1993, p 364 ( >> http://bigwww.epfl.ch/publications/unser9305.pdf) >> >> There are two operations, one that decimates an image by half to generate >> a smaller image (REDUCE) and one that reconstructs the larger image from >> the smaller (EXPAND). I'd implement both operations as classes supporting >> the RandomAccessible interface. >> >> Do people think that these have enough utility to add to imglib2 (and >> where should they go?) or is it more appropriate to keep them within the >> project itself? >> >> --Lee >> >> >> >> _______________________________________________ >> ImageJ-devel mailing list >> ImageJ-devel@imagej.net >> http://imagej.net/mailman/listinfo/imagej-devel >> >> > _______________________________________________ > ImageJ-devel mailing list > ImageJ-devel@imagej.net > http://imagej.net/mailman/listinfo/imagej-devel > > >
_______________________________________________ ImageJ-devel mailing list ImageJ-devel@imagej.net http://imagej.net/mailman/listinfo/imagej-devel
