dev: overriding multiple classes

[Leonard Sitongia]

Developers, a question for you,

What is the best practice for overriding multiple classes in ij that
aren't related in a class hierarchy?  I could write invisible plugins
(no underscore) and call them from the plugin I want visible (with the
underscore)?

In this case, I want to extend ImagePlus and Calibration, and maybe more.

Thanks.

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Volker Baecker]

Hello,
I suppose you want to subclass multiple classes (overriding some of the
methods).
Create subclasses of ImagePlus and Calibration. They must be in the same
package as their superclasses (to have access to the package-private
members). Create a jar-file with your subclasses and put the jar file in
the same directory as your plugin that uses them. You could as well put
them somewhere else in the classpath or add the location to the classpath.
Volker

Leonard Sitongia a écrit :

> Developers, a question for you,
>
> What is the best practice for overriding multiple classes in ij that
> aren't related in a class hierarchy?  I could write invisible plugins
> (no underscore) and call them from the plugin I want visible (with the
> underscore)?
>
> In this case, I want to extend ImagePlus and Calibration, and maybe more.
>
> Thanks.
>

--
passerelle antivirus du campus CNRS de Montpellier
--

[Leonard Sitongia]

Volker Bäcker wrote:

>  Create a jar-file with your subclasses and put the jar file in the
> same directory as your plugin that uses them. You could as well put
> them somewhere else in the classpath or add the location to the
> classpath.
> Volker
>
> Leonard Sitongia a écrit :
>> What is the best practice for overriding multiple classes in ij that
>> aren't related in a class hierarchy?  I could write invisible plugins
>> (no underscore) and call them from the plugin I want visible (with
>> the underscore)?
>>
>> In this case, I want to extend ImagePlus and Calibration, and maybe
>> more.

Thank you for your help.  I'd like to follow up on this with more basic
questions about how to proceed.

My goal is to adapt ImageJ to work on my image data that is in polar
coordinates.  They are images of the Sun.  They're 2D FITS pixel image
files.  But, the natural coordinates to use are polar.  This way moving
the mouse around the image shows coordinate status at the bottom of the
ImageJ window in (r,theta) instead of the (x,y) coordinates.

I started out extending Calibration with PolarCalibration, adding getR
and getTheta.  I also extend ImagePlus with PolarImagePlus to override
getLocationAsString to display (r,theta) by using PolarCalibration.

The fundamental question is, with inheritance, I can't get ImageJ to use
my new classes, right?  I need to then create a plugin that loads a
PolarImagePlus, and displays it.  Then the main ImageJ window will show
status with (r,theta).  But, other stuff in ImageJ, for example
measuring, will not use getR, for example, because they use getX.  That
is, the other operations in ImageJ will use the methods from the
ImagePlus part of my PolarImagePlus.

I can't override getX and getY in Calibration because getR and getTheta
need two arguments, (x,y).

I can't think of a way to accomplish this without modifying Calibration
and ImagePlus, or duplicating the code in parts of ImageJ to create my
own polar coordinate version of it, which I would of course want to
avoid doing.

Thanks!

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Harry Parker]

Converting to polar coordinates is fine for reporting positions in an image, but expecting current software to work with polar coordinates is not seem realistic. Pixel coordinates are integers that map directly to memory locations. These can be mapped to other real dimensions such as mm by application of simple scaling factors.

What is wrong with simply mapping (x,y) to (r,theta) and back, as you need, in your plugin code?
 
--  
Harry Parker  
Senior Systems Engineer  
Digital Imaging Systems, Inc.

----- Original Message ----
From: Leonard Sitongia <[hidden email]>
To: [hidden email]
Sent: Thursday, August 30, 2007 1:02:29 PM
Subject: Re: dev: overriding multiple classes

Volker Bäcker wrote:

>  Create a jar-file with your subclasses and put the jar file in the
> same directory as your plugin that uses them. You could as well put
> them somewhere else in the classpath or add the location to the
> classpath.
> Volker
>
> Leonard Sitongia a écrit :
>> What is the best practice for overriding multiple classes in ij that
>> aren't related in a class hierarchy?  I could write invisible plugins
>> (no underscore) and call them from the plugin I want visible (with
>> the underscore)?
>>
>> In this case, I want to extend ImagePlus and Calibration, and maybe
>> more.

Thank you for your help.  I'd like to follow up on this with more basic
questions about how to proceed.

My goal is to adapt ImageJ to work on my image data that is in polar
coordinates.  They are images of the Sun.  They're 2D FITS pixel image
files.  But, the natural coordinates to use are polar.  This way moving
the mouse around the image shows coordinate status at the bottom of the
ImageJ window in (r,theta) instead of the (x,y) coordinates.

I started out extending Calibration with PolarCalibration, adding getR
and getTheta.  I also extend ImagePlus with PolarImagePlus to override
getLocationAsString to display (r,theta) by using PolarCalibration.

The fundamental question is, with inheritance, I can't get ImageJ to use
my new classes, right?  I need to then create a plugin that loads a
PolarImagePlus, and displays it.  Then the main ImageJ window will show
status with (r,theta).  But, other stuff in ImageJ, for example
measuring, will not use getR, for example, because they use getX.  That
is, the other operations in ImageJ will use the methods from the
ImagePlus part of my PolarImagePlus.

I can't override getX and getY in Calibration because getR and getTheta
need two arguments, (x,y).

I can't think of a way to accomplish this without modifying Calibration
and ImagePlus, or duplicating the code in parts of ImageJ to create my
own polar coordinate version of it, which I would of course want to
avoid doing.

Thanks!

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]





      ____________________________________________________________________________________
Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

[Kenneth Sloan-2]

This is an ancient problem.  I think that I personally first ran up  
against it in 1975 or so.

The root of the problem is the "efficiency" of treating position in  
an image as a pixel address.
This is a natural thing for most programmers to do, and it usually  
doesn't cause trouble for a long, long time.  But, eventually the  
problem surfaces.

For many years, I have been teaching the philosophy that there are  
(at least) two separate coordinate systems for an image: the Real  
valued Cartesian coordinates  <x,y> (I prefer <0.0, 0.0> to be at the  
center of the image - on the optic axis, in the absence of cropping)  
and the Integer valued Cartesian coordinates  <column,row> (the pixel  
addresses). [I'm not always successful...]

The key point is that images are NOT square packed array of pixels,  
any more than a sound wave is a series of digital samples.

This point of view solves a LOT of problems, once you can get people  
to buy into it.

For example, if IJ had that point of view, there would be many places  
where there was an explicit transformation from <x,y> ->  
<column,row>.  IF those transformations were in place, it would be  
moderately easy to change them all to <rho,theta> -> <column,row>.

but, that's not the way it works.  IJ appears to have a frank  
<column,row> view of images and it's probably too late to change that.

Finally...yes, I realize that *some* subroutines *must* take the  
<row,column> point of view - and that these are often the *first*  
programs written and then packaged together.  I'm not a wild-eye  
idealist.
But consider: pixels are *really*, *really* important when there  
aren't very many of them.  We are currently going through the knee in  
the curve, and very soon images will have so many pixels that  
*continuous* thinking (and programming) will be more natural than  
*discrete* thinking (and programming).

We'll just have to wait for ImageK.

In the meantime, I don't think there's any realistic answer other  
than "copy and modify *every* method that uses <column,row> where you  
would like to use <rho,theta>.  You may find that it will be nearly  
impossible to define a boundary around the <rho,theta>-safe methods -  
and you might eventually end up re-writing ALL of ImageJ.

this is probably not a good plan.


On Aug 30, 2007, at 3:17 PM, Harry Parker wrote:

> Converting to polar coordinates is fine for reporting positions in  
> an image, but expecting current software to work with polar  
> coordinates is not seem realistic. Pixel coordinates are integers  
> that map directly to memory locations. These can be mapped to other  
> real dimensions such as mm by application of simple scaling factors.
>
> What is wrong with simply mapping (x,y) to (r,theta) and back, as  
> you need, in your plugin code?
>
> --  
> Harry Parker
> Senior Systems Engineer
> Digital Imaging Systems, Inc.
>
> ----- Original Message ----
> From: Leonard Sitongia <[hidden email]>
> To: [hidden email]
> Sent: Thursday, August 30, 2007 1:02:29 PM
> Subject: Re: dev: overriding multiple classes
>
> Volker Bäcker wrote:
>>  Create a jar-file with your subclasses and put the jar file in the
>> same directory as your plugin that uses them. You could as well put
>> them somewhere else in the classpath or add the location to the
>> classpath.
>> Volker
>>
>> Leonard Sitongia a écrit :
>>> What is the best practice for overriding multiple classes in ij that
>>> aren't related in a class hierarchy?  I could write invisible  
>>> plugins
>>> (no underscore) and call them from the plugin I want visible (with
>>> the underscore)?
>>>
>>> In this case, I want to extend ImagePlus and Calibration, and maybe
>>> more.
> Thank you for your help.  I'd like to follow up on this with more  
> basic
> questions about how to proceed.
>
> My goal is to adapt ImageJ to work on my image data that is in polar
> coordinates.  They are images of the Sun.  They're 2D FITS pixel image
> files.  But, the natural coordinates to use are polar.  This way  
> moving
> the mouse around the image shows coordinate status at the bottom of  
> the
> ImageJ window in (r,theta) instead of the (x,y) coordinates.
>
> I started out extending Calibration with PolarCalibration, adding getR
> and getTheta.  I also extend ImagePlus with PolarImagePlus to override
> getLocationAsString to display (r,theta) by using PolarCalibration.
>
> The fundamental question is, with inheritance, I can't get ImageJ  
> to use
> my new classes, right?  I need to then create a plugin that loads a
> PolarImagePlus, and displays it.  Then the main ImageJ window will  
> show
> status with (r,theta).  But, other stuff in ImageJ, for example
> measuring, will not use getR, for example, because they use getX.  
> That
> is, the other operations in ImageJ will use the methods from the
> ImagePlus part of my PolarImagePlus.
>
> I can't override getX and getY in Calibration because getR and  
> getTheta
> need two arguments, (x,y).
>
> I can't think of a way to accomplish this without modifying  
> Calibration
> and ImagePlus, or duplicating the code in parts of ImageJ to create my
> own polar coordinate version of it, which I would of course want to
> avoid doing.
>
> Thanks!
>
> --
> ==Leonard E. Sitongia
>    High Altitude Observatory
>    National Center for Atmospheric Research
>    P.O. Box 3000 Boulder CO 80307  USA
>    [hidden email]  voice: [phone]  fax: [phone]
>
>
>
>
>
>        
> ______________________________________________________________________
> ______________
> Luggage? GPS? Comic books?
> Check out fitting gifts for grads at Yahoo! Search
> http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz

--
Kenneth Sloan                                          
[hidden email]
Computer and Information Sciences                        [phone]
University of Alabama at Birmingham              FAX [phone]
Birmingham, AL 35294-1170                http://www.cis.uab.edu/sloan/

[dscho]

Hi,

On Thu, 30 Aug 2007, Kenneth Sloan wrote:

> We'll just have to wait for ImageK.

Why wait?  You can just start it!  And if it is interesting enough, and
you make it Open Source, I am sure enough other people will get
interested.

Ciao,
Dscho

[Leonard Sitongia]

Kenneth Sloan wrote:
> For many years, I have been teaching the philosophy that there are (at
> least) two separate coordinate systems for an image: the Real valued
> Cartesian coordinates  <x,y> (I prefer <0.0, 0.0> to be at the center
> of the image - on the optic axis, in the absence of cropping) and the
> Integer valued Cartesian coordinates  <column,row> (the pixel
> addresses). [I'm not always successful...]
>
I agree with your point, and your coordinate origin, too, especially for
astronomical telescope data.
>
> We'll just have to wait for ImageK.
I have found a couple of projects based on ImageJ (EH-HOU and SALSA-J),
but I would hate to go in that direction
>
> In the meantime, I don't think there's any realistic answer other than
> "copy and modify *every* method that uses <column,row> where you would
> like to use <rho,theta>.  You may find that it will be nearly
> impossible to define a boundary around the <rho,theta>-safe methods -
> and you might eventually end up re-writing ALL of ImageJ.
>
> this is probably not a good plan.
There's something like this, in a sense, already in ImageJ.  That is,
the handling of FFTs.  I've discovered that a property is set on the FFT
image (which is in polar coordinates), and in places in the code a test
of that property is used to format output, analyze measurements, and the
other  sorts of stuff that I want to do.

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]