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

[Lee Kamentsky]

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/93a04dc6/attachment.html>