Why Are Single Plane Composite Images Not Suppoted
Locked
Why Are Single Plane Composite Images Not Suppoted
 
|
Why are single plane CompositeImages are not supported?
Whilst a single plane composite image clearly adds nothing in functionality that you cant get with a single plane non composite image, code that is written to handle composite images would not need to be specialised to handle single plane images. Allowing single plane CompositeImages would appear to take away nothing (or am I missing something?). I have a lot of ImageJ code written for CompositeImages (we deal with multi-plane fluorescence imaging), Often though, we have an experiment that requires only a single plane fluorescence image. It would be nice if the same tools (and the same code) could be used whether the experiment was one or more planes. So I tried removing the >=2 plane restriction to composite images with three tiny changes to the ImageJ source code (see below) and although I've not done extensive testing, things seem to hang together OK! So is there any reason why the >=2 plane restriction cannot be removed from CompositeImages? ------- What follows are just my rambling thoughts that followed on from this and probably of little interest to anyone!!!! For me this opens up a more general discussion regarding the basic Image class in ImageJ. I'm guessing that ImageJ has evolved over time to add support for extra dimension Image types. Perhaps things started with single plane images, then stacks were added, then CompositeImages were added, and perhaps HyperStacks followed. However, this evolution and adherence to backwards compatibility seems to have led to a topsy-turvey object orientated architecture The different ImageJ image types (Image, Stacks and HyperStacks etc.) could all be replaced by a single Image type of arbitrary dimension. A single standard interface could be used to inquire about the dimensions and to access pixels within an image. There would be no need to write special case code for dealing with images of different types. The pluginFilter architecture could also assist by letting plugIn writers advertise that they worked in a restricted set of dimensions. The architecture could then offer functionality to the user to apply such plugIns across multiple and different dimensions. For example a two dimensional convolution plugInFilter being applied to multiple image planes, or perhaps a one dimensional convolution being reapplied across rows and columns. I am aware that there are complications and certainly implementational efficiency considerations. Obviously there is backwards compatibility to be considered too. Perhaps the new multidimsional Image can be made the new base class. Perhaps the legacy classes could be marked as @deprecated? Incidentally, if there are designs afoot for the ImageJ, is CompositeImage really a type of Image at all? Is it not more naturally considered as an auxiliary piece of rendering functionality Changes to ImageJ to implement single plane CompositeImage (no guarantee this does not break something somewhere!): File: ImagePlus.java /** Returns true if this is a CompositeImage. */ public boolean isComposite() { // return compositeImage && getNChannels()>1 && (this instanceof CompositeImage); return compositeImage && getNChannels()>=1 && (this instanceof CompositeImage); // MPE Change } File: CompositeCoverter.java /** This plugin imlements the Image/Color/Make Composite command. */ public void run(String arg) { . . . // } else if (c>=2) { } else if (c>=1) { //MPE Change . . . } File: CompositeImage.java public CompositeImage(ImagePlus imp, int mode) { . . . // if (channels<2 || (stackSize%channels)!=0) // throw new IllegalArgumentException("channels<2 or stacksize not multiple of channels"); if (channels<1 || (stackSize%channels)!=0) // MPE Change throw new IllegalArgumentException("stacksize not multiple of channels"); // MPE Change . . . } Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ source tweakers! Thought: ImageJ is just amazing and I hope that a balance between backwards compatibility and new development innovation can be struck. Michael Ellis Managing Director Digital Scientific UK Ltd. http://www.digitalscientific.co.uk [hidden email] tel: +44(0)1223 329993 fax: +44(0)1223 370040 Sheraton House Castle Park Cambridge CB3 0AX The contents of this e-mail may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. If received in error, please advise the sender and delete it from your system. |
Re: Why Are Single Plane Composite Images Not Suppoted
|
|
Hi Michael,
all the things you muse over here are being dealt with in the imageJ-dev.org project, which is bringing the next generation of imageJ's core next year. if you care about this stuff, you should go to imageJ-dev.org and contact the folks there (its the same people as Fiji and bio-formats) where all this stuff is well under way. it is discussed here, on the fiji-dev list and within imagej-dev.org eg. imglib for n dimensional generic type images some Fiji plugins already use imglib with great success. eg SPIM registration.... cheers Dan On Dec 23, 2010, at 6:01 AM, IMAGEJ automatic digest system wrote: > > Date: Wed, 22 Dec 2010 13:51:59 +0000 > From: "[hidden email]" > <[hidden email]> > Subject: Why Are Single Plane Composite Images Not Suppoted > > Why are single plane CompositeImages are not supported? > > Whilst a single plane composite image clearly adds nothing in functionality that you cant get with a single plane non composite image, code that is written to handle composite images would not need to be specialised to handle single plane images. Allowing single plane CompositeImages would appear to take away nothing (or am I missing something?). > > I have a lot of ImageJ code written for CompositeImages (we deal with multi-plane fluorescence imaging), Often though, we have an experiment that requires only a single plane fluorescence image. It would be nice if the same tools (and the same code) could be used whether the experiment was one or more planes. > > So I tried removing the >=2 plane restriction to composite images with three tiny changes to the ImageJ source code (see below) and although I've not done extensive testing, things seem to hang together OK! > > So is there any reason why the >=2 plane restriction cannot be removed from CompositeImages? > > ------- > > What follows are just my rambling thoughts that followed on from this and probably of little interest to anyone!!!! > > For me this opens up a more general discussion regarding the basic Image class in ImageJ. I'm guessing that ImageJ has evolved over time to add support for extra dimension Image types. Perhaps things started with single plane images, then stacks were added, then CompositeImages were added, and perhaps HyperStacks followed. However, this evolution and adherence to backwards compatibility seems to have led to a topsy-turvey object orientated architecture > > The different ImageJ image types (Image, Stacks and HyperStacks etc.) could all be replaced by a single Image type of arbitrary dimension. A single standard interface could be used to inquire about the dimensions and to access pixels within an image. There would be no need to write special case code for dealing with images of different types. The pluginFilter architecture could also assist by letting plugIn writers advertise that they worked in a restricted set of dimensions. The architecture could then offer functionality to the user to apply such plugIns across multiple and different dimensions. For example a two dimensional convolution plugInFilter being applied to multiple image planes, or perhaps a one dimensional convolution being reapplied across rows and columns. I am aware that there are complications and certainly implementational efficiency considerations. Obviously there is backwards compatibility to be considered too. Perhaps the new multidimsional Image can be made the new base class. Perhaps the legacy classes could be marked as @deprecated? > > Incidentally, if there are designs afoot for the ImageJ, is CompositeImage really a type of Image at all? Is it not more naturally considered as an auxiliary piece of rendering functionality > > Changes to ImageJ to implement single plane CompositeImage (no guarantee this does not break something somewhere!): > > File: ImagePlus.java > /** Returns true if this is a CompositeImage. */ > public boolean isComposite() { > // return compositeImage && getNChannels()>1 && (this instanceof CompositeImage); > return compositeImage && getNChannels()>=1 && (this instanceof CompositeImage); // MPE Change > } > > File: CompositeCoverter.java > /** This plugin imlements the Image/Color/Make Composite command. */ > public void run(String arg) { > . > . > . > // } else if (c>=2) { > } else if (c>=1) { //MPE Change > . > . > . > } > > File: CompositeImage.java > public CompositeImage(ImagePlus imp, int mode) { > . > . > . > // if (channels<2 || (stackSize%channels)!=0) > // throw new IllegalArgumentException("channels<2 or stacksize not multiple of channels"); > if (channels<1 || (stackSize%channels)!=0) // MPE Change > throw new IllegalArgumentException("stacksize not multiple of channels"); // MPE Change > . > . > . > } > > > Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ source tweakers! > Thought: ImageJ is just amazing and I hope that a balance between backwards compatibility and new development innovation can be struck. > > > > > > > > Michael Ellis > Managing Director > Digital Scientific UK Ltd. > http://www.digitalscientific.co.uk > [hidden email] > tel: +44(0)1223 329993 > fax: +44(0)1223 370040 > > Sheraton House > Castle Park > Cambridge > CB3 0AX > > > The contents of this e-mail may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. If received in error, please advise the sender and delete it from your system. > > ------------------------------ > > End of IMAGEJ Digest - 21 Dec 2010 to 22 Dec 2010 (#2010-169) > ************************************************************* Dr. Daniel James White BSc. (Hons.) PhD Senior Microscopist / Image Processing and Analysis Light Microscopy Facility Max Planck Institute of Molecular Cell Biology and Genetics Pfotenhauerstrasse 108 01307 DRESDEN Germany +49 (0)15114966933 (German Mobile) +49 (0)351 210 2627 (Work phone at MPI-CBG) +49 (0)351 210 1078 (Fax MPI-CBG LMF) http://www.bioimagexd.net BioImageXD http://pacific.mpi-cbg.de Fiji (is just ImageJ - batteries included) http://www.chalkie.org.uk [hidden email] ( [hidden email] ) |
Re: Why Are Single Plane Composite Images Not Suppoted
|
|
Dan,
Just received an email from Wayne letting me know about the upcoming ImageJ 2.0. This is all news to me, and news makes for a great early Christmas present!. Why is there no mention of ImageJ 2.0 on the original Image website http://rsbweb.nih.gov/ij/ ? Perhaps a note under the news section? I looked at imageJ-dev.org but: Unfortunately the ij-2.0-SNAPSHOT.jar link on the page http://imagejdev.org/resources seems to be broken. I got the source downloads to work but remain unsure as to whether I should be adopting anything now in readiness for ImageJ 2.0. Any advice on where to start with ImageJ 2.0 gratefully appreciated. Regards and season's greeting -- Michael On 23 Dec 2010, at 09:52, Dan White wrote: > Hi Michael, > > all the things you muse over here are being dealt with in the imageJ-dev.org project, > which is bringing the next generation of imageJ's core next year. > > if you care about this stuff, > you should go to > imageJ-dev.org > and contact the folks there (its the same people as Fiji and bio-formats) > where all this stuff is well under way. > > it is discussed here, on the fiji-dev list and within imagej-dev.org > > eg. imglib for n dimensional generic type images > > some Fiji plugins already use imglib with great success. eg SPIM registration.... > > cheers > > Dan > > > On Dec 23, 2010, at 6:01 AM, IMAGEJ automatic digest system wrote: >> >> Date: Wed, 22 Dec 2010 13:51:59 +0000 >> From: "[hidden email]" >> <[hidden email]> >> Subject: Why Are Single Plane Composite Images Not Suppoted >> >> Why are single plane CompositeImages are not supported? >> >> Whilst a single plane composite image clearly adds nothing in functionality that you cant get with a single plane non composite image, code that is written to handle composite images would not need to be specialised to handle single plane images. Allowing single plane CompositeImages would appear to take away nothing (or am I missing something?). >> >> I have a lot of ImageJ code written for CompositeImages (we deal with multi-plane fluorescence imaging), Often though, we have an experiment that requires only a single plane fluorescence image. It would be nice if the same tools (and the same code) could be used whether the experiment was one or more planes. >> >> So I tried removing the >=2 plane restriction to composite images with three tiny changes to the ImageJ source code (see below) and although I've not done extensive testing, things seem to hang together OK! >> >> So is there any reason why the >=2 plane restriction cannot be removed from CompositeImages? >> >> ------- >> >> What follows are just my rambling thoughts that followed on from this and probably of little interest to anyone!!!! >> >> For me this opens up a more general discussion regarding the basic Image class in ImageJ. I'm guessing that ImageJ has evolved over time to add support for extra dimension Image types. Perhaps things started with single plane images, then stacks were added, then CompositeImages were added, and perhaps HyperStacks followed. However, this evolution and adherence to backwards compatibility seems to have led to a topsy-turvey object orientated architecture >> >> The different ImageJ image types (Image, Stacks and HyperStacks etc.) could all be replaced by a single Image type of arbitrary dimension. A single standard interface could be used to inquire about the dimensions and to access pixels within an image. There would be no need to write special case code for dealing with images of different types. The pluginFilter architecture could also assist by letting plugIn writers advertise that they worked in a restricted set of dimensions. The architecture could then offer functionality to the user to apply such plugIns across multiple and different dimensions. For example a two dimensional convolution plugInFilter being applied to multiple image planes, or perhaps a one dimensional convolution being reapplied across rows and columns. I am aware that there are complications and certainly implementational efficiency considerations. Obviously there is backwards compatibility to be considered too. Perhaps the new multidimsional Image can be made the new base class. Perhaps the legacy classes could be marked as @deprecated? >> >> Incidentally, if there are designs afoot for the ImageJ, is CompositeImage really a type of Image at all? Is it not more naturally considered as an auxiliary piece of rendering functionality >> >> Changes to ImageJ to implement single plane CompositeImage (no guarantee this does not break something somewhere!): >> >> File: ImagePlus.java >> /** Returns true if this is a CompositeImage. */ >> public boolean isComposite() { >> // return compositeImage && getNChannels()>1 && (this instanceof CompositeImage); >> return compositeImage && getNChannels()>=1 && (this instanceof CompositeImage); // MPE Change >> } >> >> File: CompositeCoverter.java >> /** This plugin imlements the Image/Color/Make Composite command. */ >> public void run(String arg) { >> . >> . >> . >> // } else if (c>=2) { >> } else if (c>=1) { //MPE Change >> . >> . >> . >> } >> >> File: CompositeImage.java >> public CompositeImage(ImagePlus imp, int mode) { >> . >> . >> . >> // if (channels<2 || (stackSize%channels)!=0) >> // throw new IllegalArgumentException("channels<2 or stacksize not multiple of channels"); >> if (channels<1 || (stackSize%channels)!=0) // MPE Change >> throw new IllegalArgumentException("stacksize not multiple of channels"); // MPE Change >> . >> . >> . >> } >> >> >> Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ source tweakers! >> Thought: ImageJ is just amazing and I hope that a balance between backwards compatibility and new development innovation can be struck. >> >> >> >> >> >> >> >> Michael Ellis >> Managing Director >> Digital Scientific UK Ltd. >> http://www.digitalscientific.co.uk >> [hidden email] >> tel: +44(0)1223 329993 >> fax: +44(0)1223 370040 >> >> Sheraton House >> Castle Park >> Cambridge >> CB3 0AX >> >> >> The contents of this e-mail may be privileged and are confidential. It may not be disclosed to or used by anyone other than the addressee(s), nor copied in any way. If received in error, please advise the sender and delete it from your system. >> >> ------------------------------ >> >> End of IMAGEJ Digest - 21 Dec 2010 to 22 Dec 2010 (#2010-169) >> ************************************************************* > > Dr. Daniel James White BSc. (Hons.) PhD > Senior Microscopist / Image Processing and Analysis > Light Microscopy Facility > Max Planck Institute of Molecular Cell Biology and Genetics > Pfotenhauerstrasse 108 > 01307 DRESDEN > Germany > > +49 (0)15114966933 (German Mobile) > +49 (0)351 210 2627 (Work phone at MPI-CBG) > +49 (0)351 210 1078 (Fax MPI-CBG LMF) > > http://www.bioimagexd.net BioImageXD > http://pacific.mpi-cbg.de Fiji (is just ImageJ - batteries included) > http://www.chalkie.org.uk > [hidden email] > ( [hidden email] ) |
|
|
Hi,
On Fri, 24 Dec 2010, Michael Ellis wrote: > Just received an email from Wayne letting me know about the upcoming > ImageJ 2.0. This is all news to me, and news makes for a great early > Christmas present!. Why is there no mention of ImageJ 2.0 on the > original Image website http://rsbweb.nih.gov/ij/ ? Perhaps a note under > the news section? My, my. There you get a nice Christmas present, and without a "thank you" a complaint hits the list? > I looked at imageJ-dev.org but: > > Unfortunately the ij-2.0-SNAPSHOT.jar link on the page > http://imagejdev.org/resources seems to be broken. Be patient. The ImageJDev team has enough on their plates already, I am sure the download link will be fixed in due time. For the moment, it is not advisable to use ij-2.0-SNAPSHOT unless you are willing to contribute to that project, as far as I can tell. > I got the source downloads to work but remain unsure as to whether I > should be adopting anything now in readiness for ImageJ 2.0. Any advice > on where to start with ImageJ 2.0 gratefully appreciated. All this was discussed at length at the ImageJ conference. As to developing on top of ImageJ2: it is still in a phase where contributors are most important. Should you decide to become one, you might be interested in subscribing to the imagejx list, and to read up on the mails of the last month or so (it's not really a high volume list, so that's not too much to ask for). If you're not interested in developing ImageJ2, I would recommend to wait a little. Hth, Johannes |
|
In reply to this post by Michael Ellis
Hi Michael,
I replied to your mail on December 22, but it looks like my reply never made it to the ImageJ list. So here is my reply again. Why are single plane CompositeImages are not supported? > I agree that supporting single plane CompositeImages would be a convenience. Right now, with the Bio-Formats Importer, we have a class Colorizer responsible for applying the proper LUTs, etc., depending on the image data: http://dev.loci.wisc.edu/trac/software/browser/trunk/components/loci-plugins/src/loci/plugins/in/Colorizer.java We have to use case logic to decide whether to use CompositeImage, depending on number of color channels. In the case of single channel, we apply the desired LUT manually using: if (cSize == 1) imp.getProcessor().setColorModel(lut); And if more than 7 channels, we print a warning message saying there are too many channels to composite. The different ImageJ image types (Image, Stacks and HyperStacks etc.) could > all be replaced by a single Image type of arbitrary dimension. A single > standard interface could be used to inquire about the dimensions and to > access pixels within an image. > Indeed, this is what we are doing with the ImageJDev effort. Something like this: http://dev.imagejdev.org/trac/imagej/browser/trunk/ij2-common/src/main/java/imagej/dataset/Dataset.java But please be aware that that Dataset interface is NOT finalized, or even ready for public comment, as we are still working through the design. Rather, our primary focus up until this point has been backwards compatibility, so much of the code we have written is to support ImgLib-backed images in the current version of ImageJ, using a new type of ImageProcessor. For those interested, I will be sending another email to the ImageJ lists tomorrow with a more detailed status report on the ImageJDev project. Incidentally, if there are designs afoot for the ImageJ, is CompositeImage > really a type of Image at all? Is it not more naturally considered as an > auxiliary piece of rendering functionality > Agreed—the idea is to make color composite support part of the image viewer plugin responsible for displaying the image. Another goal is to make image display more extensible by third parties, so that there is a standard way to write an image display plugin that will automatically be used in the appropriate circumstances. Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ > source tweakers! > Yes, the ImageJDev project has begun creating unit tests for the current version of ImageJ. They are part of our SVN repository, which you can access using: svn co http://dev.imagejdev.org/svn/imagej/trunk imagej The code is divided into modules but you can find most of the ImageJ unit tests in: _ij1-patches/src/test/java And you can run them with: cd _ij1-patches mvn test Note that we aren't even close to 100% coverage, but we do test 50 of the core classes such as ImagePlus and the ImageProcessor subclasses. Thought: ImageJ is just amazing and I hope that a balance between backwards > compatibility and new development innovation can be struck. > I gave a talk describing the ImageJDev project's approach at the ImageJ conference in Luxembourg, with a focus on how we are maintaining backward compatibility. You can find it online, including speaker notes, on our web site: http://imagejdev.org/files/imagej/2010-10-27-ImageJDev.pdf Of course, in the meantime, adding support for 1-channel CompositeImages using your suggested changes seems reasonable to me. -Curtis On Wed, Dec 22, 2010 at 7:51 AM, [hidden email] < [hidden email]> wrote: > Why are single plane CompositeImages are not supported? > > Whilst a single plane composite image clearly adds nothing in functionality > that you cant get with a single plane non composite image, code that is > written to handle composite images would not need to be specialised to > handle single plane images. Allowing single plane CompositeImages would > appear to take away nothing (or am I missing something?). > > I have a lot of ImageJ code written for CompositeImages (we deal with > multi-plane fluorescence imaging), Often though, we have an experiment that > requires only a single plane fluorescence image. It would be nice if the > same tools (and the same code) could be used whether the experiment was one > or more planes. > > So I tried removing the >=2 plane restriction to composite images with > three tiny changes to the ImageJ source code (see below) and although I've > not done extensive testing, things seem to hang together OK! > > So is there any reason why the >=2 plane restriction cannot be removed from > CompositeImages? > > ------- > > What follows are just my rambling thoughts that followed on from this and > probably of little interest to anyone!!!! > > For me this opens up a more general discussion regarding the basic Image > class in ImageJ. I'm guessing that ImageJ has evolved over time to add > support for extra dimension Image types. Perhaps things started with single > plane images, then stacks were added, then CompositeImages were added, and > perhaps HyperStacks followed. However, this evolution and adherence to > backwards compatibility seems to have led to a topsy-turvey object > orientated architecture > > The different ImageJ image types (Image, Stacks and HyperStacks etc.) could > all be replaced by a single Image type of arbitrary dimension. A single > standard interface could be used to inquire about the dimensions and to > access pixels within an image. There would be no need to write special case > code for dealing with images of different types. The pluginFilter > architecture could also assist by letting plugIn writers advertise that they > worked in a restricted set of dimensions. The architecture could then offer > functionality to the user to apply such plugIns across multiple and > different dimensions. For example a two dimensional convolution plugInFilter > being applied to multiple image planes, or perhaps a one dimensional > convolution being reapplied across rows and columns. I am aware that there > are complications and certainly implementational efficiency considerations. > Obviously there is backwards compatibility to be considered too. Perhaps the > new multidimsional Image can be made the new base class. Perhaps the legacy > classes could be marked as @deprecated? > > Incidentally, if there are designs afoot for the ImageJ, is CompositeImage > really a type of Image at all? Is it not more naturally considered as an > auxiliary piece of rendering functionality > > Changes to ImageJ to implement single plane CompositeImage (no guarantee > this does not break something somewhere!): > > File: ImagePlus.java > /** Returns true if this is a CompositeImage. */ > public boolean isComposite() { > // return compositeImage && getNChannels()>1 && (this > instanceof CompositeImage); > return compositeImage && getNChannels()>=1 && (this > instanceof CompositeImage); // MPE Change > } > > File: CompositeCoverter.java > /** This plugin imlements the Image/Color/Make Composite command. */ > public void run(String arg) { > . > . > . > // } else if (c>=2) { > } else if (c>=1) { //MPE Change > . > . > . > } > > File: CompositeImage.java > public CompositeImage(ImagePlus imp, int mode) { > . > . > . > // if (channels<2 || (stackSize%channels)!=0) > // throw new IllegalArgumentException("channels<2 or > stacksize not multiple of channels"); > if (channels<1 || (stackSize%channels)!=0) // MPE Change > throw new IllegalArgumentException("stacksize not > multiple of channels"); // MPE Change > . > . > . > } > > > Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ > source tweakers! > Thought: ImageJ is just amazing and I hope that a balance between backwards > compatibility and new development innovation can be struck. > > > > > > > > Michael Ellis > Managing Director > Digital Scientific UK Ltd. > http://www.digitalscientific.co.uk > [hidden email] > tel: +44(0)1223 329993 > fax: +44(0)1223 370040 > > Sheraton House > Castle Park > Cambridge > CB3 0AX > > > The contents of this e-mail may be privileged and are confidential. It may > not be disclosed to or used by anyone other than the addressee(s), nor > copied in any way. If received in error, please advise the sender and > delete it from your system. > |
|
|
In reply to this post by Michael Ellis
Hi Michael,
I looked at imageJ-dev.org but: > > Unfortunately the ij-2.0-SNAPSHOT.jar link on the page > http://imagejdev.org/resources seems to be broken. > Apologies for any broken links on the site—we are in the midst of many year-end updates documenting our latest progress. I will send an ImageJDev status report to the lists (including this one) when the updates are done, within the next few days. I have updated the site to be clearer about the fact that there is not yet an end user download. We wanted to have an "alpha" version by now, but we are not quite ready yet. In any case, as Johannes says, we do not advise people to use the ImageJDev code until a beta release is announced (probably next summer), unless they want to join the development. I got the source downloads to work but remain unsure as to whether I should > be adopting anything now in readiness for ImageJ 2.0. Any advice on where to > start with ImageJ 2.0 gratefully appreciated. > There will be more information about the ImageJ 2.0 design on the web site very soon. My advice is to wait for the status report email, read over the site, and reply to the ImageJX mailing list ( http://imagejdev.org/mailing-lists) with any comments and suggestions. Regards, Curtis On Fri, Dec 24, 2010 at 4:01 AM, Michael Ellis < [hidden email]> wrote: > Dan, > > Just received an email from Wayne letting me know about the upcoming ImageJ > 2.0. This is all news to me, and news makes for a great early Christmas > present!. Why is there no mention of ImageJ 2.0 on the original Image > website http://rsbweb.nih.gov/ij/ ? Perhaps a note under the news section? > > I looked at imageJ-dev.org but: > > Unfortunately the ij-2.0-SNAPSHOT.jar link on the page > http://imagejdev.org/resources seems to be broken. > > I got the source downloads to work but remain unsure as to whether I should > be adopting anything now in readiness for ImageJ 2.0. Any advice on where to > start with ImageJ 2.0 gratefully appreciated. > > Regards and season's greeting -- Michael > > On 23 Dec 2010, at 09:52, Dan White wrote: > > > Hi Michael, > > > > all the things you muse over here are being dealt with in the > imageJ-dev.org project, > > which is bringing the next generation of imageJ's core next year. > > > > if you care about this stuff, > > you should go to > > imageJ-dev.org > > and contact the folks there (its the same people as Fiji and bio-formats) > > where all this stuff is well under way. > > > > it is discussed here, on the fiji-dev list and within imagej-dev.org > > > > eg. imglib for n dimensional generic type images > > > > some Fiji plugins already use imglib with great success. eg SPIM > registration.... > > > > cheers > > > > Dan > > > > > > On Dec 23, 2010, at 6:01 AM, IMAGEJ automatic digest system wrote: > >> > >> Date: Wed, 22 Dec 2010 13:51:59 +0000 > >> From: "[hidden email]" > >> <[hidden email]> > >> Subject: Why Are Single Plane Composite Images Not Suppoted > >> > >> Why are single plane CompositeImages are not supported? > >> > >> Whilst a single plane composite image clearly adds nothing in > functionality that you cant get with a single plane non composite image, > code that is written to handle composite images would not need to be > specialised to handle single plane images. Allowing single plane > CompositeImages would appear to take away nothing (or am I missing > something?). > >> > >> I have a lot of ImageJ code written for CompositeImages (we deal with > multi-plane fluorescence imaging), Often though, we have an experiment that > requires only a single plane fluorescence image. It would be nice if the > same tools (and the same code) could be used whether the experiment was one > or more planes. > >> > >> So I tried removing the >=2 plane restriction to composite images with > three tiny changes to the ImageJ source code (see below) and although I've > not done extensive testing, things seem to hang together OK! > >> > >> So is there any reason why the >=2 plane restriction cannot be removed > from CompositeImages? > >> > >> ------- > >> > >> What follows are just my rambling thoughts that followed on from this > and probably of little interest to anyone!!!! > >> > >> For me this opens up a more general discussion regarding the basic Image > class in ImageJ. I'm guessing that ImageJ has evolved over time to add > support for extra dimension Image types. Perhaps things started with single > plane images, then stacks were added, then CompositeImages were added, and > perhaps HyperStacks followed. However, this evolution and adherence to > backwards compatibility seems to have led to a topsy-turvey object > orientated architecture > >> > >> The different ImageJ image types (Image, Stacks and HyperStacks etc.) > could all be replaced by a single Image type of arbitrary dimension. A > single standard interface could be used to inquire about the dimensions and > to access pixels within an image. There would be no need to write special > case code for dealing with images of different types. The pluginFilter > architecture could also assist by letting plugIn writers advertise that they > worked in a restricted set of dimensions. The architecture could then offer > functionality to the user to apply such plugIns across multiple and > different dimensions. For example a two dimensional convolution plugInFilter > being applied to multiple image planes, or perhaps a one dimensional > convolution being reapplied across rows and columns. I am aware that there > are complications and certainly implementational efficiency considerations. > Obviously there is backwards compatibility to be considered too. Perhaps the > new multidimsional Image can be made the new base class. Perhaps the legacy > classes could be marked as @deprecated? > >> > >> Incidentally, if there are designs afoot for the ImageJ, is > CompositeImage really a type of Image at all? Is it not more naturally > considered as an auxiliary piece of rendering functionality > >> > >> Changes to ImageJ to implement single plane CompositeImage (no guarantee > this does not break something somewhere!): > >> > >> File: ImagePlus.java > >> /** Returns true if this is a CompositeImage. */ > >> public boolean isComposite() { > >> // return compositeImage && getNChannels()>1 && (this > instanceof CompositeImage); > >> return compositeImage && getNChannels()>=1 && (this > instanceof CompositeImage); // MPE Change > >> } > >> > >> File: CompositeCoverter.java > >> /** This plugin imlements the Image/Color/Make Composite command. > */ > >> public void run(String arg) { > >> . > >> . > >> . > >> // } else if (c>=2) { > >> } else if (c>=1) { //MPE Change > >> . > >> . > >> . > >> } > >> > >> File: CompositeImage.java > >> public CompositeImage(ImagePlus imp, int mode) { > >> . > >> . > >> . > >> // if (channels<2 || (stackSize%channels)!=0) > >> // throw new IllegalArgumentException("channels<2 or > stacksize not multiple of channels"); > >> if (channels<1 || (stackSize%channels)!=0) // MPE Change > >> throw new IllegalArgumentException("stacksize not > multiple of channels"); // MPE Change > >> . > >> . > >> . > >> } > >> > >> > >> Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ > source tweakers! > >> Thought: ImageJ is just amazing and I hope that a balance between > backwards compatibility and new development innovation can be struck. > >> > >> > >> > >> > >> > >> > >> > >> Michael Ellis > >> Managing Director > >> Digital Scientific UK Ltd. > >> http://www.digitalscientific.co.uk > >> [hidden email] > >> tel: +44(0)1223 329993 > >> fax: +44(0)1223 370040 > >> > >> Sheraton House > >> Castle Park > >> Cambridge > >> CB3 0AX > >> > >> > >> The contents of this e-mail may be privileged and are confidential. It > may not be disclosed to or used by anyone other than the addressee(s), nor > copied in any way. If received in error, please advise the sender and > delete it from your system. > >> > >> ------------------------------ > >> > >> End of IMAGEJ Digest - 21 Dec 2010 to 22 Dec 2010 (#2010-169) > >> ************************************************************* > > > > Dr. Daniel James White BSc. (Hons.) PhD > > Senior Microscopist / Image Processing and Analysis > > Light Microscopy Facility > > Max Planck Institute of Molecular Cell Biology and Genetics > > Pfotenhauerstrasse 108 > > 01307 DRESDEN > > Germany > > > > +49 (0)15114966933 (German Mobile) > > +49 (0)351 210 2627 (Work phone at MPI-CBG) > > +49 (0)351 210 1078 (Fax MPI-CBG LMF) > > > > http://www.bioimagexd.net BioImageXD > > http://pacific.mpi-cbg.de Fiji (is just ImageJ - batteries > included) > > http://www.chalkie.org.uk > > [hidden email] > > ( [hidden email] ) > |
Re: Why Are Single Plane Composite Images Not Suppoted
|
|
In reply to this post by ctrueden
Curtis, hi,
On 24 Dec 2010, at 12:35, Curtis Rueden wrote: > Hi Michael, > > I replied to your mail on December 22, but it looks like my reply never made > it to the ImageJ list. So here is my reply again. Interesting, I made some posts to the list then that seemed to get lost too. > > Why are single plane CompositeImages are not supported? >> > > I agree that supporting single plane CompositeImages would be a convenience. > Right now, with the Bio-Formats Importer, we have a class Colorizer > responsible for applying the proper LUTs, etc., depending on the image data: > > http://dev.loci.wisc.edu/trac/software/browser/trunk/components/loci-plugins/src/loci/plugins/in/Colorizer.java > > We have to use case logic to decide whether to use CompositeImage, depending > on number of color channels. In the case of single channel, we apply the > desired LUT manually using: > > if (cSize == 1) imp.getProcessor().setColorModel(lut); > > And if more than 7 channels, we print a warning message saying there are too > many channels to composite. Exactly! But this looks like you have addressed this with ImageJDev - Amazing! > > > The different ImageJ image types (Image, Stacks and HyperStacks etc.) could >> all be replaced by a single Image type of arbitrary dimension. A single >> standard interface could be used to inquire about the dimensions and to >> access pixels within an image. >> > > Indeed, this is what we are doing with the ImageJDev effort. Something like > this: > > http://dev.imagejdev.org/trac/imagej/browser/trunk/ij2-common/src/main/java/imagej/dataset/Dataset.java > > But please be aware that that Dataset interface is NOT finalized, or even > ready for public comment, as we are still working through the design. > Rather, our primary focus up until this point has been backwards > compatibility, so much of the code we have written is to support > ImgLib-backed images in the current version of ImageJ, using a new type of > ImageProcessor. For those interested, I will be sending another email to the > ImageJ lists tomorrow with a more detailed status report on the ImageJDev > project. > > Incidentally, if there are designs afoot for the ImageJ, is CompositeImage >> really a type of Image at all? Is it not more naturally considered as an >> auxiliary piece of rendering functionality >> > > Agreed—the idea is to make color composite support part of the image viewer > plugin responsible for displaying the image. Another goal is to make image > display more extensible by third parties, so that there is a standard way to > write an image display plugin that will automatically be used in the > appropriate circumstances. Fantastic! For rendering multilane fluorescence images we've been using a simplified colour affine transform and there is no easy way to get this into the existing ImageJ architecture without making destructive changes to the underlying image data. ImageJDev looks like it will enable us to solve the problem. > > Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ >> source tweakers! >> > > Yes, the ImageJDev project has begun creating unit tests for the current > version of ImageJ. They are part of our SVN repository, which you can access > using: > > svn co http://dev.imagejdev.org/svn/imagej/trunk imagej > > The code is divided into modules but you can find most of the ImageJ unit > tests in: > > _ij1-patches/src/test/java > > And you can run them with: > > cd _ij1-patches > mvn test > > Note that we aren't even close to 100% coverage, but we do test 50 of the > core classes such as ImagePlus and the ImageProcessor subclasses. > > > Thought: ImageJ is just amazing and I hope that a balance between backwards >> compatibility and new development innovation can be struck. >> > > I gave a talk describing the ImageJDev project's approach at the ImageJ > conference in Luxembourg, with a focus on how we are maintaining backward > compatibility. You can find it online, including speaker notes, on our web > site: > > http://imagejdev.org/files/imagej/2010-10-27-ImageJDev.pdf I so wish I could have made that conference! Perhaps the next one. > > Of course, in the meantime, adding support for 1-channel CompositeImages > using your suggested changes seems reasonable to me. Wayne has now added this and it solves our immediate problem very well. Regards -- Michael Ellis > > -Curtis > > On Wed, Dec 22, 2010 at 7:51 AM, [hidden email] < > [hidden email]> wrote: > >> Why are single plane CompositeImages are not supported? >> >> Whilst a single plane composite image clearly adds nothing in functionality >> that you cant get with a single plane non composite image, code that is >> written to handle composite images would not need to be specialised to >> handle single plane images. Allowing single plane CompositeImages would >> appear to take away nothing (or am I missing something?). >> >> I have a lot of ImageJ code written for CompositeImages (we deal with >> multi-plane fluorescence imaging), Often though, we have an experiment that >> requires only a single plane fluorescence image. It would be nice if the >> same tools (and the same code) could be used whether the experiment was one >> or more planes. >> >> So I tried removing the >=2 plane restriction to composite images with >> three tiny changes to the ImageJ source code (see below) and although I've >> not done extensive testing, things seem to hang together OK! >> >> So is there any reason why the >=2 plane restriction cannot be removed from >> CompositeImages? >> >> ------- >> >> What follows are just my rambling thoughts that followed on from this and >> probably of little interest to anyone!!!! >> >> For me this opens up a more general discussion regarding the basic Image >> class in ImageJ. I'm guessing that ImageJ has evolved over time to add >> support for extra dimension Image types. Perhaps things started with single >> plane images, then stacks were added, then CompositeImages were added, and >> perhaps HyperStacks followed. However, this evolution and adherence to >> backwards compatibility seems to have led to a topsy-turvey object >> orientated architecture >> >> The different ImageJ image types (Image, Stacks and HyperStacks etc.) could >> all be replaced by a single Image type of arbitrary dimension. A single >> standard interface could be used to inquire about the dimensions and to >> access pixels within an image. There would be no need to write special case >> code for dealing with images of different types. The pluginFilter >> architecture could also assist by letting plugIn writers advertise that they >> worked in a restricted set of dimensions. The architecture could then offer >> functionality to the user to apply such plugIns across multiple and >> different dimensions. For example a two dimensional convolution plugInFilter >> being applied to multiple image planes, or perhaps a one dimensional >> convolution being reapplied across rows and columns. I am aware that there >> are complications and certainly implementational efficiency considerations. >> Obviously there is backwards compatibility to be considered too. Perhaps the >> new multidimsional Image can be made the new base class. Perhaps the legacy >> classes could be marked as @deprecated? >> >> Incidentally, if there are designs afoot for the ImageJ, is CompositeImage >> really a type of Image at all? Is it not more naturally considered as an >> auxiliary piece of rendering functionality >> >> Changes to ImageJ to implement single plane CompositeImage (no guarantee >> this does not break something somewhere!): >> >> File: ImagePlus.java >> /** Returns true if this is a CompositeImage. */ >> public boolean isComposite() { >> // return compositeImage && getNChannels()>1 && (this >> instanceof CompositeImage); >> return compositeImage && getNChannels()>=1 && (this >> instanceof CompositeImage); // MPE Change >> } >> >> File: CompositeCoverter.java >> /** This plugin imlements the Image/Color/Make Composite command. */ >> public void run(String arg) { >> . >> . >> . >> // } else if (c>=2) { >> } else if (c>=1) { //MPE Change >> . >> . >> . >> } >> >> File: CompositeImage.java >> public CompositeImage(ImagePlus imp, int mode) { >> . >> . >> . >> // if (channels<2 || (stackSize%channels)!=0) >> // throw new IllegalArgumentException("channels<2 or >> stacksize not multiple of channels"); >> if (channels<1 || (stackSize%channels)!=0) // MPE Change >> throw new IllegalArgumentException("stacksize not >> multiple of channels"); // MPE Change >> . >> . >> . >> } >> >> >> Thought: Are there any Unit tests for ImageJ. Could be useful for ImageJ >> source tweakers! >> Thought: ImageJ is just amazing and I hope that a balance between backwards >> compatibility and new development innovation can be struck. >> >> >> >> |
«
Return to ImageJ
|
1 view|%1 views
| Free forum by Nabble | Edit this page |