[ImageJ-devel] Results from yesterday's imglib coding session
preibisch at mpi-cbg.de
Fri Jul 23 15:48:04 CDT 2010
sorry, I somehow did not get that there was this session yesterday.
I had a look at the ImgLibProcessor and in general it looks good. I have
some comments what could be done more optimized. Should we go over it maybe
on Monday in a short Skype session?
From: imagej-devel-bounces at imagejdev.org
[mailto:imagej-devel-bounces at imagejdev.org] On Behalf Of Curtis Rueden
Sent: Friday, July 23, 2010 10:26 PM
To: Imagejdev.org Developers
Subject: [ImageJ-devel] Results from yesterday's imglib coding session
Yesterday the ImageJDev.org developers spent a few hours together,
attempting an initial integration of imglib with ImageJ.
We ended up (partially) implementing a new ImageProcessor subclass called
ImgLibProcessor that is backed by an mpicbg.imglib.image.Image<T extends
ComplexType<T>> object. This basic proof of concept is available from our
For those interested, the ij.process.ImgLibProcessor class has a main method
to test the functionality; the image used must be grayscale, and either a
single image or a Z-series, due to current limitations in imglib's LOCI
Bio-Formats image importer.
We also identified several next steps to take to further pursue this work:
1) Resolve the multichannel issue/limitations
2) Implement the many unimplemented imglib processor methods
3) Investigate the ImageStatistics subclasses-maybe create an analogous
4) Identify the places within ImageJ where type-specific case logic is used
* Add a case for the new imglib backed structure at these locations
5) More generally, add getters/setters for all public fields throughout
ImageJ, to assist with delegation logic in the future
Overall, the coding session was a success-people felt like they learned
quite a bit-so we will probably do another one in 2-4 weeks, assuming we
have another appropriate topic.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ImageJ-devel