[ImageJ-devel] L2 Polynomial Spline Pyramid (2 of 2)

[Stephan Preibisch]

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 <leek at broadinstitute.org> wrote:
> 
> On Wed, Jun 19, 2013 at 12:13 PM, Stephan Preibisch <preibisch at 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 <leek at 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 at imagej.net
>> http://imagej.net/mailman/listinfo/imagej-devel
>> 
>> 
>> _______________________________________________
>> ImageJ-devel mailing list
>> ImageJ-devel at imagej.net
>> http://imagej.net/mailman/listinfo/imagej-devel
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130619/fcad6bf7/attachment-0001.html>