I just ran across the article cited below describing a plugin for viewing and analyzing scanned whole microscope slides using ImageJ. I would be interested in trying the plugin out or hearing feedback from others who may have used the tool. I understand that support for whole slide image formats is planned for the big ImageJ 2.0 project underway. Perhaps Dr. Zerbe has some useful input for the ImageJdev team.
Distributed computing in image analysis using open source frameworks and application to image sharpness assessment of histological whole slide images Norman Zerbe, Peter Hufnagl, Karsten Schlüns Diagnostic Pathology 2011, 6(Suppl 1):S16 (30 March 2011) http://www.diagnosticpathology.org/content/6/S1/S16 James Deeds Scientifc Technical Leader II Novartis Institutes for BioMedical Research, Inc. 250 Massachusetts Avenue Cambridge, MA 02139 USA |
Hi James,
On Mon, 18 Apr 2011, Deeds, James wrote: > I just ran across the article cited below describing a plugin for > viewing and analyzing scanned whole microscope slides using ImageJ. I > would be interested in trying the plugin out or hearing feedback from > others who may have used the tool. I understand that support for whole > slide image formats is planned for the big ImageJ 2.0 project underway. > Perhaps Dr. Zerbe has some useful input for the ImageJdev team. > > Distributed computing in image analysis using open source frameworks and application to image sharpness assessment of histological whole slide images > Norman Zerbe, Peter Hufnagl, Karsten Schlüns > Diagnostic Pathology 2011, 6(Suppl 1):S16 (30 March 2011) > http://www.diagnosticpathology.org/content/6/S1/S16 methods (including tools) has not made it quite yet into life sciences. That is the only reason I can see why the paper describes a plugin that is not available publicly. Therefore I doubt that you will get much feedback from people who used it. Unfortunately, this is also the reason why nobody involved in the ImageJDev project can form an opinion about, or benefit from, the work described in the paper, except by putting an undue burden on the developers who are already working very hard on a first beta release of ImageJ 2.0. Maybe you want to contact the corresponding author, and maybe the author wants to contribute a bit back to the free software he benefitted from so nicely? Maybe there is a chance to avoid reinventing the wheel here? Maybe this is a perfect opportunity to stand on each others shoulders? Ciao, Johannes |
On Mon, Apr 18, 2011 at 22:57, Johannes Schindelin <
[hidden email]> wrote: > Hi James, > > On Mon, 18 Apr 2011, Deeds, James wrote: > > > I just ran across the article cited below describing a plugin for > > viewing and analyzing scanned whole microscope slides using ImageJ. I > > would be interested in trying the plugin out or hearing feedback from > > others who may have used the tool. I understand that support for whole > > slide image formats is planned for the big ImageJ 2.0 project underway. > > Perhaps Dr. Zerbe has some useful input for the ImageJdev team. > > > > Distributed computing in image analysis using open source frameworks and > application to image sharpness assessment of histological whole slide images > > Norman Zerbe, Peter Hufnagl, Karsten Schlüns > > Diagnostic Pathology 2011, 6(Suppl 1):S16 (30 March 2011) > > http://www.diagnosticpathology.org/content/6/S1/S16 > > Sadly, the requirement of other scientific fields for full disclosure of > methods (including tools) has not made it quite yet into life sciences. > That is the only reason I can see why the paper describes a plugin that is > not available publicly. > > impression that in computer science, conferences proceedings tend to be as important as journal articles, but still, maybe the authors want to get a bone fide publication before releasing the plugin ? That said, this looks like it could be really useful for a lot of people. Let's hope with Johannes that it will benefit to the whole ImageJ community by being made available and open source. Christophe > Therefore I doubt that you will get much feedback from people who used it. > > Unfortunately, this is also the reason why nobody involved in the > ImageJDev project can form an opinion about, or benefit from, the work > described in the paper, except by putting an undue burden on the > developers who are already working very hard on a first beta release of > ImageJ 2.0. > > Maybe you want to contact the corresponding author, and maybe the author > wants to contribute a bit back to the free software he benefitted from so > nicely? Maybe there is a chance to avoid reinventing the wheel here? Maybe > this is a perfect opportunity to stand on each others shoulders? > > Ciao, > Johannes > > |
In reply to this post by dscho
We have done similar implementation of ImageJ on our web-server platform and
I can share some thoughts and issues that are involved in this process (by the way, same issues are involved in utilizing ImageJ on map/reduce computing clouds). - This application cannot be a plug-in to ImageJ - this has to be server application stack that is actually using ImageJ as plugin (we do the same) - Using non-overlapping virtual tiles does not work very well for kernel operations (e.g. Unsharp) because it creates ugly edge effects (we have to use larger virtual tiles and trim them although it adds processing "overhead" ) - Example of analysis: Unfortunately, the biggest problem with high performance image processing using ImageJ is not ImageJ core but plugins that are largely not designed and built for High Performance Computing (they may leak memory, create operations "overhead" etc.). So we had to implement policing process that just kills ImageJ processes every so often but this is expensive resource wise. ImageJ was written to make plugin development as easy as possible, with virtually no controls. So when ImageJ 2 becomes available, plugins have to be reviewed and adapted for high-performance computing. If somebody would like to see and try to use ImageJ plugins on server as tile processors for whole slide images, let me know. We will be happy to provide this resource for ImageJ community. We cannot let people push Java code to our production servers but if somebody has Windows server (physical or on Amazon Compute Cloud) and would be willing to let community members use it, we will be happy to set it up for everybody to use. Vitali Smart Imaging Technologies Co. 713-589-3500 www.live.simagis.com -----Original Message----- From: ImageJ Interest Group [mailto:[hidden email]] On Behalf Of Johannes Schindelin Sent: Monday, April 18, 2011 3:57 PM To: [hidden email] Subject: Re: Whole slide image analysis with ImageJ Hi James, On Mon, 18 Apr 2011, Deeds, James wrote: > I just ran across the article cited below describing a plugin for > viewing and analyzing scanned whole microscope slides using ImageJ. I > would be interested in trying the plugin out or hearing feedback from > others who may have used the tool. I understand that support for whole > slide image formats is planned for the big ImageJ 2.0 project underway. > Perhaps Dr. Zerbe has some useful input for the ImageJdev team. > > Distributed computing in image analysis using open source frameworks > and application to image sharpness assessment of histological whole > slide images Norman Zerbe, Peter Hufnagl, Karsten Schlüns Diagnostic > Pathology 2011, 6(Suppl 1):S16 (30 March 2011) > http://www.diagnosticpathology.org/content/6/S1/S16 Sadly, the requirement of other scientific fields for full disclosure of methods (including tools) has not made it quite yet into life sciences. That is the only reason I can see why the paper describes a plugin that is not available publicly. Therefore I doubt that you will get much feedback from people who used it. Unfortunately, this is also the reason why nobody involved in the ImageJDev project can form an opinion about, or benefit from, the work described in the paper, except by putting an undue burden on the developers who are already working very hard on a first beta release of ImageJ 2.0. Maybe you want to contact the corresponding author, and maybe the author wants to contribute a bit back to the free software he benefitted from so nicely? Maybe there is a chance to avoid reinventing the wheel here? Maybe this is a perfect opportunity to stand on each others shoulders? Ciao, Johannes |
In reply to this post by dscho
Hi Johannes,
I agree that it would be great to see this code in the public domain. We will contact Dr. Zerbe and see if he is able to provide his code back to the IJ community. In our lab we deal exclusively with these 'whole slide' images - we currently have ~60,000 slides scanned. I have been using ImageJ (and NIHImage) for analysis of 'field-of-view' images for the last 15+ years so I am very interested to see development in this area. As I see it, there are perhaps two different tasks when working with this image type: 1) analyzing tiles from the whole slide file with generation of markup tiles (or ideally a reconstructed whole slide markup file) and 2) viewing the multiscale whole slide images and markups. Ideally, both of these functions will find their way into the new versions of ImageJ that the team is hard at work on. I have tried using the LOCI Bioformats Importer plugin to do task #1 but I think that I am running into memory issues even with the 'Virtual Stacks' option checked. We have been using the vendor's (Aperio) 'Extract Region' tool to generate 5000x5000 pixel jpg tiles to folders and then batch processing the files with ImageJ. One challenge is reviewing the markup tiles after analysis and putting the individual tiles in the context of the whole slide image. Another problem is that the extraction process is extremely slow and we don't have an obvious way to batch extract multiple whole slide files. I would like to hear from the user community if anyone has developed a successful strategy for dealing with these images. It sounds like Aivar Grislis did some work on dealing with large sized images (at least for viewing) at the Hackathon: "Initial development toward a multi-resolution tiled viewer for IJ2 (Aivar Grislis)" I would be interested in hearing from Aivar about his experience working on this project. From the roadmap, it sound like this particular feature is slated for rel 2.5. Cheers, Jim -----Original Message----- From: Johannes Schindelin [mailto:[hidden email]] Sent: Monday, April 18, 2011 4:57 PM To: Deeds, James Cc: [hidden email] Subject: Re: Whole slide image analysis with ImageJ Hi James, On Mon, 18 Apr 2011, Deeds, James wrote: > I just ran across the article cited below describing a plugin for > viewing and analyzing scanned whole microscope slides using ImageJ. I > would be interested in trying the plugin out or hearing feedback from > others who may have used the tool. I understand that support for whole > slide image formats is planned for the big ImageJ 2.0 project underway. > Perhaps Dr. Zerbe has some useful input for the ImageJdev team. > > Distributed computing in image analysis using open source frameworks and application to image sharpness assessment of histological whole slide images > Norman Zerbe, Peter Hufnagl, Karsten Schlüns > Diagnostic Pathology 2011, 6(Suppl 1):S16 (30 March 2011) > http://www.diagnosticpathology.org/content/6/S1/S16 Sadly, the requirement of other scientific fields for full disclosure of methods (including tools) has not made it quite yet into life sciences. That is the only reason I can see why the paper describes a plugin that is not available publicly. Therefore I doubt that you will get much feedback from people who used it. Unfortunately, this is also the reason why nobody involved in the ImageJDev project can form an opinion about, or benefit from, the work described in the paper, except by putting an undue burden on the developers who are already working very hard on a first beta release of ImageJ 2.0. Maybe you want to contact the corresponding author, and maybe the author wants to contribute a bit back to the free software he benefitted from so nicely? Maybe there is a chance to avoid reinventing the wheel here? Maybe this is a perfect opportunity to stand on each others shoulders? Ciao, Johannes |
Hi James,
My project for the Hackathon was for the viewing end of things, to reduce the memory requirement for large images and provide a smooth zooming and panning experience. The existing code is more just a tile server that only displays a fake image at present. It builds a mip-map pyramid of non-overlapping tiles (currently 256x256 pixels). Each tile is created on demand from higher resolution tiles and cached. Currently it only creates 100%, 50%, 25%... zoom levels. The tiles are derived from averaging the pixels, so four pixels become one. This looks good but creates a slight artifical sharpness. ImageJ currently scales down by decimation, that is it discards columns and rows. For the ImageJDev project we are using Johannes' Fiji ImgLib as our underlying data model. The usual ArrayContainer is limited to around 2 gigapixel images due to Java's use of integer array indices. There is a CellContainer that can be used to hold huge images that fit in memory or could support image tiles that are swapped out. It's interesting to learn of this work, particularly the WSI file formats and their streaming WSI server. Aivar On 4/19/11 10:14 AM, Deeds, James wrote: > Hi Johannes, > > I agree that it would be great to see this code in the public domain. We will contact Dr. Zerbe and see if he is able to provide his code back to the IJ community. > > In our lab we deal exclusively with these 'whole slide' images - we currently have ~60,000 slides scanned. I have been using ImageJ (and NIHImage) for analysis of 'field-of-view' images for the last 15+ years so I am very interested to see development in this area. As I see it, there are perhaps two different tasks when working with this image type: 1) analyzing tiles from the whole slide file with generation of markup tiles (or ideally a reconstructed whole slide markup file) and 2) viewing the multiscale whole slide images and markups. Ideally, both of these functions will find their way into the new versions of ImageJ that the team is hard at work on. > > I have tried using the LOCI Bioformats Importer plugin to do task #1 but I think that I am running into memory issues even with the 'Virtual Stacks' option checked. We have been using the vendor's (Aperio) 'Extract Region' tool to generate 5000x5000 pixel jpg tiles to folders and then batch processing the files with ImageJ. One challenge is reviewing the markup tiles after analysis and putting the individual tiles in the context of the whole slide image. Another problem is that the extraction process is extremely slow and we don't have an obvious way to batch extract multiple whole slide files. I would like to hear from the user community if anyone has developed a successful strategy for dealing with these images. > > It sounds like Aivar Grislis did some work on dealing with large sized images (at least for viewing) at the Hackathon: "Initial development toward a multi-resolution tiled viewer for IJ2 (Aivar Grislis)" I would be interested in hearing from Aivar about his experience working on this project. From the roadmap, it sound like this particular feature is slated for rel 2.5. > > Cheers, > Jim > > -----Original Message----- > From: Johannes Schindelin [mailto:[hidden email]] > Sent: Monday, April 18, 2011 4:57 PM > To: Deeds, James > Cc: [hidden email] > Subject: Re: Whole slide image analysis with ImageJ > > Hi James, > > On Mon, 18 Apr 2011, Deeds, James wrote: > >> I just ran across the article cited below describing a plugin for >> viewing and analyzing scanned whole microscope slides using ImageJ. I >> would be interested in trying the plugin out or hearing feedback from >> others who may have used the tool. I understand that support for whole >> slide image formats is planned for the big ImageJ 2.0 project underway. >> Perhaps Dr. Zerbe has some useful input for the ImageJdev team. >> >> Distributed computing in image analysis using open source frameworks and application to image sharpness assessment of histological whole slide images >> Norman Zerbe, Peter Hufnagl, Karsten Schlüns >> Diagnostic Pathology 2011, 6(Suppl 1):S16 (30 March 2011) >> http://www.diagnosticpathology.org/content/6/S1/S16 > Sadly, the requirement of other scientific fields for full disclosure of > methods (including tools) has not made it quite yet into life sciences. > That is the only reason I can see why the paper describes a plugin that is > not available publicly. > > Therefore I doubt that you will get much feedback from people who used it. > > Unfortunately, this is also the reason why nobody involved in the > ImageJDev project can form an opinion about, or benefit from, the work > described in the paper, except by putting an undue burden on the > developers who are already working very hard on a first beta release of > ImageJ 2.0. > > Maybe you want to contact the corresponding author, and maybe the author > wants to contribute a bit back to the free software he benefitted from so > nicely? Maybe there is a chance to avoid reinventing the wheel here? Maybe > this is a perfect opportunity to stand on each others shoulders? > > Ciao, > Johannes |
Hi,
On Tue, 19 Apr 2011, Aivar Grislis wrote: > For the ImageJDev project we are using Johannes' Fiji ImgLib as our > underlying data model. To clarify: ImgLib was conceived and developed by Stephan Saalfeld and Stephan Preibisch since spring 2008. Recently, other developers (I only play a minor role, personally) contributed to, and pushed forward, ImgLib, including Curtis Rueden, Tobias Pietzsch, Barry DeZonia, Lee Kamentsky and others. > The usual ArrayContainer is limited to around 2 gigapixel images due to > Java's use of integer array indices. ... but of course the ImgLib provides other means to store images which are not limited to 2^31 pixels... > There is a CellContainer that can be used to hold huge images that fit > in memory or could support image tiles that are swapped out. Do not forget the PlanarContainer, which is currently limited to 2^31 planes that can contain up to 2^31 pixels. The ImgLib is able to accomodate more container types (without requiring any change in the implementation of algorithms!) than Array, Cell and Planar. It is even possible to implement your own, custom, container, again without requiring to change _any_ implemention of an algorithm. In my opinion it would be in the best interest of the authors of the previously mentioned paper to develop their code on top of the ImgLib since it is clearly well-adapted to extreme cases like huge planes. Of course, I also think that it would be the best to publish the plugins, since nothing is more useless than a program (next to) nobody uses. Ciao, Johannes |
Free forum by Nabble | Edit this page |