On Wed, Jun 19, 2013 at 12:46 PM, Curtis Rueden <ctrue...@wisc.edu> 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.
>
Oops - not destination, a coordinate. Something like:
RandomAccessibleInterval<T> randomAccessibleInterval(RandomAccessible src)
{}
with a get() method that calculates the value at the currente location.
>
> 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
