inheritance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

inheritance

Tony Shepherd
When I create an image I can use one of the existing classes, creating one
of the existing object types, for example

ImagePlus imp = WindowManager.getCurrentImage();
   Followed by
ImageProcessor MyImage = imp.getProcessor();                   (1)

Then MyImage is an object of type ImageProcessor.

Say I want to write my own methods (like calculating stats from an ROI or
what ever). I don’t want to (have to) edit the ImageProcessor class. So I
write methods in a new class, one that EXTENDS ImageProcessor. i.e.

public abstract class MyTypeOfImage extents ImageProcessor{ …

I can only expect to use my new methods if I create the image in the first
place, as a ‘MyTypeOfImage’ object, i.e.:

ImagePlus imp = WindowManager.getCurrentImage();
MyTypeOfImage MyImage = imp.getProcessor();                    (2)


Now, (1) and (2) above only differ in the type of object being declared/created

I expect the class 'MyTypeOfImage' to inherit all the necessary constructors
from 'ImageProcessor', for creating an image object,

The compiler disagrees, complaining about incompatible types.
Reply | Threaded
Open this post in threaded view
|

Re: inheritance

ctrueden
Hi Tony,

Try:
    MyTypeOfImage myIP = (MyTypeOfImage) imp.getProcessor();

But I question why you need to subclass ImageProcessor at all. The
subclasses of ImageProcessor are mainly for different bit depths. Do you
need a new, crazy kind of bit depth?

-Curtis

On 8/8/06, Tony Shepherd <[hidden email]> wrote:

>
> When I create an image I can use one of the existing classes, creating one
> of the existing object types, for example
>
> ImagePlus imp = WindowManager.getCurrentImage();
>    Followed by
> ImageProcessor MyImage = imp.getProcessor();                   (1)
>
> Then MyImage is an object of type ImageProcessor.
>
> Say I want to write my own methods (like calculating stats from an ROI or
> what ever). I don't want to (have to) edit the ImageProcessor class. So I
> write methods in a new class, one that EXTENDS ImageProcessor. i.e.
>
> public abstract class MyTypeOfImage extents ImageProcessor{ …
>
> I can only expect to use my new methods if I create the image in the first
> place, as a 'MyTypeOfImage' object, i.e.:
>
> ImagePlus imp = WindowManager.getCurrentImage();
> MyTypeOfImage MyImage = imp.getProcessor();                    (2)
>
>
> Now, (1) and (2) above only differ in the type of object being
> declared/created
>
> I expect the class 'MyTypeOfImage' to inherit all the necessary
> constructors
> from 'ImageProcessor', for creating an image object,
>
> The compiler disagrees, complaining about incompatible types.
>
Reply | Threaded
Open this post in threaded view
|

Re: inheritance

Tony Shepherd
In reply to this post by Tony Shepherd
Thanks for the advice but I'm missing something crucial here! you wrote:

".. I question why you need to subclass ImageProcessor at all. The
subclasses of ImageProcessor are mainly for different bit depths. Do you
need a new, crazy kind of bit depth?.."

I thought that if I wanted to write a method to do ANYTHING to an
ImageProgessor object (like filter it, classify it or anything, not just
fiddle with bit depths) then these methods had to be added on to the end of
the class that constructs the object. (i.e. by editing ImageProcessor.java
OR creating class MyImageType, which extends ImageProcessor)

It sounds like I was mistaken, but where else can I stick some fresh code,
so that I can execute the method by adding the line:

   myobject.dosomething();

to a plugin?

I tried sticking a fresh method class at the bottom of the plugin itself
(outside the main method) but it's not picked up.


Thanks vey much

Tony
Reply | Threaded
Open this post in threaded view
|

Re: inheritance

dscho
In reply to this post by Tony Shepherd
Hi,

On Tue, 8 Aug 2006, Tony Shepherd wrote:

> ImagePlus imp = WindowManager.getCurrentImage();
> MyTypeOfImage MyImage = imp.getProcessor();

You need to cast it, since MyTypeOfImage is _not_ a base class of
ImageProcessor, but vice versa:

        MyTypeOfImage MyImage = (MyTypeOfImage)imp.getProcessor();

But this _will_ fail if the image processor of the ImagePlus is not of the
correct type, with a ClassCastException.

If you want to access members of ImageProcessor on an instance of, say,
ColorProcessor, you would need to inherit from ColorProcessor, and use
static methods (since it is not possible to "enlarge" a ColorProcessor to
something derived from ColorProcessor, even if it does not contain extra
data members).

For example:

        public class XYT extends ColorProcessor {
                private XZY() { } // we never instantiate this class

                public static int[] getSnapshotPixels(ColorProcessor p) {
                        return p.snapshotPixels;
                }
        }

(I did not actually test that code, but it should compile.)

Hth,
Dscho
Reply | Threaded
Open this post in threaded view
|

Re: inheritance

ctrueden
In reply to this post by Tony Shepherd
Hi Tony,

If want to perform some operation on an ImageProcessor, you can add a method
to your plugin that takes an ImageProcessor object as an argument. Then when
you need that method during your plugin's operations, you can call it. You
said, "I tried sticking a fresh method class at the bottom of the plugin
itself (outside the main method) but it's not picked up," but I am not sure
what that means. If you put a method within your plugin's source code, it
should work fine. And you shouldn't need to define any new classes 99% of
the time.

I would suggest you model your plugins off of existing work available from
the ImageJ website, rather than starting from scratch. There is also a
tutorial on writing plugins online at:
    http://mtd.fh-hagenberg.at/depot/imaging/imagej/

Good luck.

-Curtis

On 8/8/06, Tony Shepherd <[hidden email]> wrote:

>
> Thanks for the advice but I'm missing something crucial here! you wrote:
>
> ".. I question why you need to subclass ImageProcessor at all. The
> subclasses of ImageProcessor are mainly for different bit depths. Do you
> need a new, crazy kind of bit depth?.."
>
> I thought that if I wanted to write a method to do ANYTHING to an
> ImageProgessor object (like filter it, classify it or anything, not just
> fiddle with bit depths) then these methods had to be added on to the end
> of
> the class that constructs the object. (i.e. by editing ImageProcessor.java
> OR creating class MyImageType, which extends ImageProcessor)
>
> It sounds like I was mistaken, but where else can I stick some fresh code,
> so that I can execute the method by adding the line:
>
>    myobject.dosomething();
>
> to a plugin?
>
> I tried sticking a fresh method class at the bottom of the plugin itself
> (outside the main method) but it's not picked up.
>
>
> Thanks vey much
>
> Tony
>