Posted by
ctrueden on
Dec 24, 2010; 12:35pm
URL: http://imagej.273.s1.nabble.com/Why-Are-Single-Plane-Composite-Images-Not-Suppoted-tp3686102p3686103.html
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.javaWe 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.javaBut 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.pdfOf 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.
>