[ImageJ-devel] imglib positionables for dimension 0

[Curtis Rueden]

Hi Steffi,

Your proposal is fine with me—it makes a lot of sense.

-Curtis

On Thu, May 12, 2011 at 8:07 AM, Stephan Preibisch <preibisch at mpi-cbg.de>wrote:

> I think for many (n-dimensional) algorithms 1-dimensional temporary arrays
> of <T> are necessary in some form, as it is now for example in Gaussian
> Convolution and Fourier Transform. It is no overhead for any other
> container. If you do not want to implement it you could simply write:
>
> setPosition(long)
> {
>   // call existing but maybe slower method which does the same
>   setPosition(long,0);
> }
>
> But as temporary Img, where you know it is one-dimensional it gives you a
> clear benefit. And of course, if I make a temp 1-d Img<T> I would only use
> ArrayImg<T> - or CellImg<T> if a dimension is larger than
> Integer.MAX_VALUE/EntitiesPerPixel. It would also be fine with me if only
> those two do it and implement a special new interface.
>
> Steffi
>
> -----Original Message-----
> From: Johannes Schindelin [mailto:Johannes.Schindelin at gmx.de]
> Sent: Thursday, May 12, 2011 1:55 PM
> To: Stephan Preibisch
> Cc: saalfeld at mpi-cbg.de; 'Tobias Pietzsch'; 'Fiji-devel'; 'Imagejdev.org
> Developers'
> Subject: Re: [ImageJ-devel] imglib positionables for dimension 0
>
> Hi,
>
> On Thu, 12 May 2011, Stephan Preibisch wrote:
>
> > what do you think about that:
> >
> <http://pacific.mpi-cbg.de/wiki/index.php/ImgLib2_Discussion#Positionables
> >
> >
> http://pacific.mpi-cbg.de/wiki/index.php/ImgLib2_Discussion#Positionables
>
> I understand the reasoning, but wouldn't it be better to make that a new
> interface? For most truly n-dimensional algorithms, setPosition(long)
> would not be needed, and I could imagine that at least for some containers
> (think Hilbert-curve) setPosition(long) could be pretty complicated for no
> clear benefit.
>
> Ciao,
> Dscho
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20110512/35190353/attachment.html>