Hi Lee, >> public <T extends NumericType<T>> void reduce(IterableInterval<T> src, >> IterableInterval<T> dest, ImgFactory<T> factory);
It seems to me that you should rather take as input RandomAccessibleInterval than IterableInterval. You can simply make it iterable by calling -- public static < T > IterableInterval< T > iterable( final RandomAccessibleInterval< T > randomAccessibleInterval ) from the net.imglib2.view.Views class -- but not really the other way around. Or is there any good reason why it should not work on a RandomAccessibleInterval? Btw, be careful when you work with temporary images and Intervals. Temporary images always start at (0,0, ... 0), Intervals not. Happened to me several times that it actually worked when you take an Img as input to test, but not a View with an offset. >> Isn't that what the net.imglib2.view.Views.interval methods do? Yes ... check out the static Views class, has almost everything you need https://github.com/imagej/imglib/blob/master/core/src/main/java/net/imglib2/view/Views.java Bye bye, Steffi On Jun 19, 2013, at 12:46 , Curtis Rueden wrote: > Hi Lee, > > > 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. > > Isn't that what the net.imglib2.view.Views.interval methods do? > > Regards, > Curtis > > > On Wed, Jun 19, 2013 at 11:44 AM, Lee Kamentsky <l...@broadinstitute.org> > wrote: > > 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
