[ImageJ-devel] imglib positionables for dimension 0
Stephan Preibisch
preibisch at mpi-cbg.de
Thu May 12 09:10:47 CDT 2011
Hi Stephan,
I like this way of realizing it, maybe we could also implement it on ImgFactory level. If a Img implements RandomAccessible1D, the factory could also have a special create( long size ) method (in e.g. RandomAccessible1DFactory) which returns for example <I extends ArrayImg<T,?> & RandomAccessible1D>, so no unchecked casts are necessary...
Stephan
-----Original Message-----
From: Stephan Saalfeld [mailto:saalfeld at mpi-cbg.de]
Sent: Thursday, May 12, 2011 3:41 PM
To: Stephan Preibisch
Cc: 'Johannes Schindelin'; 'Tobias Pietzsch'; 'Fiji-devel'; 'Imagejdev.org Developers'
Subject: RE: [ImageJ-devel] imglib positionables for dimension 0
Hi,
I wrote a note into the Wiki. I agree about the need for a faster
controlled jump in a 1D structure. I would prefer a specialized
RandomAccess1D implementation for those Img variants where it makes
sense. That RandomAccess1D would be returned by that Img if n=1. We
have done similarly for the PlanarImg to speed up iteration in the 1D
and 2D cases. That way, you would need to implement it only where it
makes sense. In case you know that you were using an ArrayImg or
CellImg (which you should decide yourself for temporary data holding),
you could cast to the respective RandomAccess1D and get the most inlined
speed possible.
I do not like the idea to add setPosition0 to the
Positionable/RandomAccess interface since it clutters it and does not
make sense in many situations.
What do you think?
Best,
Stephan
On Thu, 2011-05-12 at 14:07 +0200, Stephan Preibisch 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
>
More information about the ImageJ-devel
mailing list