Hi All -
I just saw the stitching post on the ImageJ blog (http://developer.imagej.net/2014/04/07/stitching-fijiij2) and I'm very excited to see that improvements to Stitching and integration with ImageJ2 are coming. One question I have is: will this allow stitching of arbitrarily large images? When last I checked, ImageJ was limited to images smaller than 2 gigapixels. We have been doing a lot of image stitching and would like to be able to use the ImageJ stitcher for scanning whole slides, which requires support for much larger images. Is this coming and if so is there an estimate of when it might be available? On a related note, is there likely to be support for image pyramid schemes for display and visualization of large images? This would be nice, although it seems like there are other libraries that support this, so it's not essential. I have been very impressed with the performance of the stitcher in ImageJ; we've been using it a lot and I hope to roll out some Micro-manager plugins to make acquisition of tiled images for stitching easier, as well as possibly integrating stitching directly (the 10x speedup just announced makes this a lot more practical). Also, would this question be more appropriate on the developer list? Thanks, Kurt -- Kurt Thorn Director, Nikon Imaging Center http://nic.ucsf.edu/blog/ -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Dear Kurt,
aside the optimizations that Mark Hiner is currently working on, thanks a lot by the way(!!), I implemented the Stitching code already in ImgLib a long time ago. So if ImageJ2 is able to display and work with the ImgLib2 CellImg (which is not limited by 2GB per plane) it will be just a few modifications to allow this. I am not sure though if ImageJ2 can do this, Curtis, Johannes? Cheers, Stephan --- Dr. Stephan Preibisch HFSP Fellow Robert H. Singer / Eugene Myers lab Albert Einstein College of Medicine / HHMI Janelia Farm / MPI-CBG email: [hidden email] / [hidden email] / [hidden email] web: http://www.preibisch.net/ > Hi All - > > I just saw the stitching post on the ImageJ blog > (http://developer.imagej.net/2014/04/07/stitching-fijiij2) and I'm very > excited to see that improvements to Stitching and integration with > ImageJ2 are coming. One question I have is: will this allow stitching > of arbitrarily large images? When last I checked, ImageJ was limited to > images smaller than 2 gigapixels. We have been doing a lot of image > stitching and would like to be able to use the ImageJ stitcher for > scanning whole slides, which requires support for much larger images. > Is this coming and if so is there an estimate of when it might be > available? > > On a related note, is there likely to be support for image pyramid > schemes for display and visualization of large images? This would be > nice, although it seems like there are other libraries that support > this, so it's not essential. > > I have been very impressed with the performance of the stitcher in > ImageJ; we've been using it a lot and I hope to roll out some > Micro-manager plugins to make acquisition of tiled images for stitching > easier, as well as possibly integrating stitching directly (the 10x > speedup just announced makes this a lot more practical). > > Also, would this question be more appropriate on the developer list? > > Thanks, > Kurt > > -- > Kurt Thorn > Director, Nikon Imaging Center > http://nic.ucsf.edu/blog/ > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Steffi,
On Tue, 8 Apr 2014, Stephan Preibisch wrote: > aside the optimizations that Mark Hiner is currently working on, thanks > a lot by the way(!!), I implemented the Stitching code already in ImgLib > a long time ago. So if ImageJ2 is able to display and work with the > ImgLib2 CellImg (which is not limited by 2GB per plane) it will be just > a few modifications to allow this. > > I am not sure though if ImageJ2 can do this, Curtis, Johannes? Please remember that Stitching is still an ImageJ 1.x plugin and therefore inherits all of those limitations. We are quite busy trying to lay the groundwork for converting Stitching into an ImageJ2 plugin that can be used even in the ImageJ 1.x context. But part of that involves that split of ImgLib2, together with bringing the part out of beta that ImageJ2's core requiress, and as you know, that is still a matter of discussion (you yourself have not commented on it, for example). So that's one of the blocking issues. Ciao, Johannes -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi Johannes,
if I understood it right, ImageJ2 will support ImageJ1 plugins, right? 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. To make a proper ImageJ2/ImgLib2 plugin out of it of course requires more groundwork to be done as you pointed out. 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. 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). I am in the progress of catching up with email reading, I will check for the ImgLib2 splitting. Cheers, Stephan --- Dr. Stephan Preibisch HFSP Fellow Robert H. Singer / Eugene Myers lab Albert Einstein College of Medicine / HHMI Janelia Farm / MPI-CBG email: [hidden email] / [hidden email] / [hidden email] web: http://www.preibisch.net/ > Hi Steffi, > > On Tue, 8 Apr 2014, Stephan Preibisch wrote: > >> aside the optimizations that Mark Hiner is currently working on, thanks >> a lot by the way(!!), I implemented the Stitching code already in ImgLib >> a long time ago. So if ImageJ2 is able to display and work with the >> ImgLib2 CellImg (which is not limited by 2GB per plane) it will be just >> a few modifications to allow this. >> >> I am not sure though if ImageJ2 can do this, Curtis, Johannes? > > Please remember that Stitching is still an ImageJ 1.x plugin and therefore > inherits all of those limitations. > > We are quite busy trying to lay the groundwork for converting Stitching > into an ImageJ2 plugin that can be used even in the ImageJ 1.x context. > > But part of that involves that split of ImgLib2, together with bringing > the part out of beta that ImageJ2's core requiress, and as you know, that > is still a matter of discussion (you yourself have not commented on it, > for example). So that's one of the blocking issues. > > Ciao, > Johannes > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
Hi all,
But it simply cannot be displayed due to the limitations of ImageJ1/Java > (not more than 2GB per array). > I believe IJ2, at the moment, is bound by the same limitations mentioned by Stephan, in that a displayed image ultimately has to fit in an array. But the plan is certainly for this to change. When the Stitching plugin is updated to use SCIFIO, it will use an ImgOpener<https://github.com/scifio/scifio/blob/master/scifio/src/main/java/io/scif/img/ImgOpener.java>to open datasets, which will automatically create SCIFIOCellImgs<https://github.com/scifio/scifio/blob/master/scifio/src/main/java/io/scif/img/cell/SCIFIOCellImg.java>(an extension of the ImgLib2 CellImg, which uses a disk cache to temporarily persist changes to individual cells - which is important if you want to perform operations on your stitched image). So at that point I think it's just a matter of deciding how, in IJ2, we are going to request & display the sub-regions of large planes. I can't give you an exact estimate of when this would happen, but I do think this is an incredibly significant feature, and it's something I personally am excited to work on. I believe if you go to the sub-region caching issue<https://github.com/scifio/scifio/issues/125>, you can subscribe to get future notifications from the SCIFIO side (which will coincide with the IJ2 development). On a related note, is there likely to be support for image pyramid schemes > for display and visualization of large images? > Yes I would say this is very likely! Curtis just brought this up to me recently, actually. When we talk about it again I'll get an issue up, so people can follow it. Regards, Mark P.S. Thank you for the questions, and for reading my blog post! ;) On Tue, Apr 8, 2014 at 6:43 PM, Stephan Preibisch <[hidden email]>wrote: > Hi Johannes, > > if I understood it right, ImageJ2 will support ImageJ1 plugins, right? 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. > > To make a proper ImageJ2/ImgLib2 plugin out of it of course requires more > groundwork to be done as you pointed out. 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. > > 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). > > I am in the progress of catching up with email reading, I will check for > the ImgLib2 splitting. > > Cheers, > Stephan > --- > > Dr. Stephan Preibisch > HFSP Fellow > Robert H. Singer / Eugene Myers lab > > Albert Einstein College of Medicine / HHMI Janelia Farm / MPI-CBG > > email: [hidden email] / [hidden email] / > [hidden email] > web: http://www.preibisch.net/ > > > Hi Steffi, > > > > On Tue, 8 Apr 2014, Stephan Preibisch wrote: > > > >> aside the optimizations that Mark Hiner is currently working on, thanks > >> a lot by the way(!!), I implemented the Stitching code already in ImgLib > >> a long time ago. So if ImageJ2 is able to display and work with the > >> ImgLib2 CellImg (which is not limited by 2GB per plane) it will be just > >> a few modifications to allow this. > >> > >> I am not sure though if ImageJ2 can do this, Curtis, Johannes? > > > > Please remember that Stitching is still an ImageJ 1.x plugin and > therefore > > inherits all of those limitations. > > > > We are quite busy trying to lay the groundwork for converting Stitching > > into an ImageJ2 plugin that can be used even in the ImageJ 1.x context. > > > > But part of that involves that split of ImgLib2, together with bringing > > the part out of beta that ImageJ2's core requiress, and as you know, that > > is still a matter of discussion (you yourself have not commented on it, > > for example). So that's one of the blocking issues. > > > > Ciao, > > Johannes > > > > -- > > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > > > > -- > ImageJ mailing list: http://imagej.nih.gov/ij/list.html > -- ImageJ mailing list: http://imagej.nih.gov/ij/list.html |
In reply to this post by Stephan Preibisch
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 |
Free forum by Nabble | Edit this page |