http://imagej.273.s1.nabble.com/Why-Are-Single-Plane-Composite-Images-Not-Suppoted-tp3686102p3686107.html
year-end updates documenting our latest progress. I will send an ImageJDev
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
> be adopting anything now in readiness for ImageJ 2.0. Any advice on where to
very soon. My advice is to wait for the status report email, read over the
> 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] )
>