Posted by
dscho on
Apr 09, 2014; 1:45pm
URL: http://imagej.273.s1.nabble.com/Stitching-in-ImageJ2-tp5007247p5007261.html
Hi Steffi,
On Wed, 9 Apr 2014, Stephan Preibisch wrote:
> if I understood it right, ImageJ2 will support ImageJ1 plugins, right?
To the extent possible, yes.
> So if ImageJ2 can display and work with the CellImg of ImgLib2, it could
> really be not much change to the existing code to support much bigger
> planes.
ImageJ2 can display and work with the CellImg of ImgLib2. When you call
the (ImageJ 1.x) Stitching plugin, it will be wrapped into an ImageJ 1.x
data structure. That is where the limitations come in.
> To make a proper ImageJ2/ImgLib2 plugin out of it of course requires
> more groundwork to be done as you pointed out.
Correct.
The infatigable Mark Hiner is making big strides toward that goal, though.
> But in the meantime, if many people need these bigger planes, it could
> be very easy. We just need to exchange the ImgLib container used for
> fusion and wrap it into ImgLib2/ImageJ2 before displaying it.
As of now, it is not possible to display data via ImageJ2's display
machinery in ImageJ 1.x yet... *unless* you switch to modern mode.
This is the status quo, but as you read in Curtis' announcement a couple
of days ago: we are working very hard toward a very concrete goal: to make
ImageJ2 plugins run inside ImageJ 1.x (insofar possible; As mentioned
above, ImageJ 1.x' limitations in term of data structures -- there are
only unsigned 8-bit and 16-bit, and only 32-bit floating point data types,
planes cannot have more than 2^31 pixels, as well as the limitation to the
five dimensions X, Y, Z, channel & time [*1*] -- will apply in this
context because the data are really held in ImageJ 1.x data structures).
While working on this, we must not get distracted too much with other
projects (such as using ImageJ2's display infrastructure within ImageJ
1.x).
> It can be done right now actually, we can fuse bigger planes without any
> problem. But it simply cannot be displayed due to the limitations of
> ImageJ1/Java (not more than 2GB per array).
To be precise, the limitation is not the amount of memory: you can display
2^31 pixels (which amount to 8GB if you use 32-bit floating point).
> I am in the progress of catching up with email reading, I will check for
> the ImgLib2 splitting.
Thanks,
Dscho
Footnote *1*: Three years ago, Barry DeZonia worked on a way to let ImageJ
1.x use ImageJ2's data structures; That code did not make it into any
official release. Having said that, Curtis' plan will lead to something
even more flexible.
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html