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 dont 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. |
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. > |
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 |
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 |
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 > |
Free forum by Nabble | Edit this page |