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

[Curtis Rueden]

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/8c4870ee/attachment-0001.html>