[ImageJ-devel] imglib2

Stephan Saalfeld saalfeld at mpi-cbg.de
Sat Feb 26 06:18:25 CST 2011


Hi Tobias and all ImgLibers,

on Friday afternoon, Johannes, Tobias and me (Preibisch is still busy
currently) had a discussion on how to proceed with ImgLib2 development
in a way that we do not block each other.  The result of the discussion
was that Tobias and me will branch off the current imglib2 branch into
the branch imglib2-dirty and remove everything that is not working
currently from imglib2.  That way, imglib2 will be a reduced but working
library to work with.  Those that develop imglib2 will keep working on
the new branch imglib2-dirty and, whenever anything is fixed, move it
into imglib2.  Those that develop anything using imglib2 as a library
will use the imglib2 branch.

This procedure will be done by Monday.  It includes that we consider the
design of the imglib2 core as stable from Monday on.  I am saying this
because we made a last noticeable change on Thursday night.  Here come
the rationals:

* We made RandomAccessibleInterval extend RandomAccessible (as well for
real) because there is no way to generate a
RandomAccess-with-OutOfBounds without a
RandomAccess-without-OutOfBounds.

* We found that the term Container does not exist in the hierarchy of
ImgLib2 any more.  It is equivalent to Img.  For Img being shorter than
Container and everybody using Img meanwhile, we decided to replace all
references to the term Container by Img instead of vice versa.  We
cleaned up some inconsistencies in the naming scheme for Img
implementing classes.  Check the updated diagram, it makes total sense.
The term Container can still be used in informal speaking about an Img
but Img is preferred.  An Img is random accessible and iterable pixel
data in an interval whose min coordinates are at 0^n.  Modifying the T
accessed through an ImgSampler<T> will change the data in the Img<T>.  A
follow-up to the same location will return the changed value.  That is,
a ShapeList is not an Img!


Another issue:

ImgLib2 aims at compile time type safety.  We will therefore remove
runtime test constructs from the imglib core.  If needed at all, they
can go to the (sub)-project where they are required, e.g. type-checking
in imglib-io or imglib-algorithm.

> > I changed three Positionable implementations, as they obviously
just 
> > needed their moveTo() methods be renamed to move().
> 
> Stephan is working on fixing those, as well.
> 

Renaming doesn't do it, move is meant relative, moveTo was not and is out.

> > Stephans (including Stephan 3): are you okay with merging this into
> > the imglib2 branch?
> 
> Let's wait until Stephan 1 pushes.
> I think that the imglib2-cleanup changes will be already in imglib2.
>

I've pushed the half done cleanup into imglib2, more coming soon.
Despite respecting your efforts, it is easier for Tobias and me to
continue with what we've done in agreement with our discussion than
reviewing what you, Johannes, have done that we didn't know about.

Best regards,
Stephan




On Sat, 2011-02-26 at 01:27 +0100, Tobias Pietzsch wrote: 
> Hi Johannes,
> 
> On 02/25/2011 11:53 PM, Johannes Schindelin wrote:
> > I just pushed a branch 'imglib2-cleanup' which I intend to merge into
> > imglib2 (as discussed IRL, imglib2 should not have non-compiling stuff so
> > that we can go to a stable version Real Soon Now).
> >
> > The classes I removed fall into 5 categories:
> >
> > - CanvasImage (algorithm), dunno what to do with that,
> >
> > - shapelist: probably needs adjustements WRT the OutOfBounds changes,
> 
> We started removing stuff from imglib2 branch as well, but it's not
> pushed yet (Stephan had to leave before we were finished cleaning up). 
> - Stephan, could you just push the changes we made so far? -
> 
> I guess we already made most of the changes that are imglib2-cleanup.
> 
> ShapeList compiles (I think Albert fixed it) but there is still some
> renaming to do to fit the new Interface names. So we thought to put
> it in the imglib2 branch, noting that is still subject to change.
> 
> I'm also fine with removing it for now until it can be considered
> stable.
> 
> > - interpolation: same as shapelist,
> 
> Will not be in the imglib2 branch now.
> I'm working on that currently in the imglib2-dirty branch.
> Should be ready by Monday, then we can put it back into imglib2.
> 
> > - OutOfBoundsStrategyMirrorExpWindowing (outofbounds): dunno,
> 
> me neither...
> 
> > - sampler: you said that this package is no longer needed.
> 
> true. Samplers (Cursor, RandomAccess) are now in the same package as
> their respective containers. I think that was a very good decision.
> Besides having everything in one place now, it has also the advantage
> that Cursors can have access to package private members of their
> containers.
> 
> > I changed three Positionable implementations, as they obviously just
> > needed their moveTo() methods be renamed to move().
> 
> Stephan is working on fixing those, as well.
> 
> > Stephans (including Stephan 3): are you okay with merging this into
> > the imglib2 branch?
> 
> Let's wait until Stephan 1 pushes.
> I think that the imglib2-cleanup changes will be already in imglib2.
> 
> Cheers,
> Tobias





More information about the ImageJ-devel mailing list