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

[Lee Kamentsky]

Hi all,

On Wed, Jun 19, 2013 at 1:02 PM, Stephan Preibisch <preibisch at mpi-cbg.de>wrote:

> 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?
>

Hmmm... I can have a RandomAccessibleInterval as the source. I totally
missed the Views class which is awesome.

>
> 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.
>
> I was creating an Img and then using a translation to make a view of it
within the valid region... but I did it manually instead of using Views to
do it for me.

>> 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/0bfdb5d4/attachment.html>