http://imagej.273.s1.nabble.com/Why-Are-Single-Plane-Composite-Images-Not-Suppoted-tp3686102p3686105.html
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.
where all this stuff is well under way.
eg. imglib for n dimensional generic type images
some Fiji plugins already use imglib with great success. eg SPIM registration....
>
> 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