Posted by
Michael Ellis on
Dec 28, 2010; 9:31am
URL: http://imagej.273.s1.nabble.com/Why-Are-Single-Plane-Composite-Images-Not-Suppoted-tp3686102p3686104.html
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.pdfI 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.
>>
>>
>>
>>