non-static ROIColor?

[William Beaver]

Hello all,
A question about ROIs I hope someone can shed some light on:  I'd  
like to assign colors to ROI objects.  The problem: ROIColor is a  
static attribute of the Roi class.

If you beleive that ROIColor is part of each object's state and that  
color could reasonably be different for each Roi, making ROIColor non-
static seems to be the right solution.  Unfortunately, It does not  
appear that the naive solution of simply making the attribute "non-
static"  works:  many color preferences are assigned via reference to  
the static Roi.ROIColor.

Would it make sense to change this assumption (ROIColor is static) in  
the Roi class?  I guess I'd need to somehow retain a static ROIColor  
reference for those classes that need a default color (put it into  
Prefs? and make appropriate changes elsewhere?)  and mod ROIColor so  
it is an instance variable.  Any larger issues/impacts I am not aware  
of?

Alternatively, if no one sees value in having ROIs with object level  
attributes, I could store each ROI color in some mapped container  
class and mange them separately;  maybe as part of (something like)  
RoiManager?

Thoughts?

Regards,
-William

------------
William Beaver
University of California, San Diego

[Ben Woodcroft]

Hi,

I agree. Indeed, why is RoiManager itself essentially static?

ben

On 5/7/07, William Beaver <[hidden email]> wrote:

>
> Hello all,
> A question about ROIs I hope someone can shed some light on:  I'd
> like to assign colors to ROI objects.  The problem: ROIColor is a
> static attribute of the Roi class.
>
> If you beleive that ROIColor is part of each object's state and that
> color could reasonably be different for each Roi, making ROIColor non-
> static seems to be the right solution.  Unfortunately, It does not
> appear that the naive solution of simply making the attribute "non-
> static"  works:  many color preferences are assigned via reference to
> the static Roi.ROIColor.
>
> Would it make sense to change this assumption (ROIColor is static) in
> the Roi class?  I guess I'd need to somehow retain a static ROIColor
> reference for those classes that need a default color (put it into
> Prefs? and make appropriate changes elsewhere?)  and mod ROIColor so
> it is an instance variable.  Any larger issues/impacts I am not aware
> of?
>
> Alternatively, if no one sees value in having ROIs with object level
> attributes, I could store each ROI color in some mapped container
> class and mange them separately;  maybe as part of (something like)
> RoiManager?
>
> Thoughts?
>
> Regards,
> -William
>
> ------------
> William Beaver
> University of California, San Diego
>

[dscho]

Hi,

On Mon, 7 May 2007, Ben Woodcroft wrote:

> I agree. Indeed, why is RoiManager itself essentially static?

It has to be, since you do not want a million RoiManagers flying around
your desktop. It is meant to transfer (and store/retreive) ROIs between
images.

Ciao,
Dscho

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[dscho]

Hi,

On Sun, 6 May 2007, William Beaver wrote:

> A question about ROIs I hope someone can shed some light on:  I'd like
> to assign colors to ROI objects.  The problem: ROIColor is a static
> attribute of the Roi class.

While this is not possible at the moment, you can (globally) change the
colour of the selection with Edit>Options>Colors... or by executing a
macro like

        run("Colors...", "selection=green");

Hth,
Dscho

[Gabriel Landini]

On Monday 07 May 2007, Johannes Schindelin wrote:
> While this is not possible at the moment, you can (globally) change the
> colour of the selection with Edit>Options>Colors... or by executing a
> macro like
> run("Colors...", "selection=green");

Also, if you just want to "see" ROIs in different colours, you can always
create and label a new empty image where the ROIs are drawn in different
colours (using the macro setColor() and draw functions.
This is quite useful because:
1. the labelling remains in the new image but ROIs (at the moment) do not.
2. one can retrieve back the label by looking at the colour of the (XStart,
YStart) pixel (you only need a results table open, or those coordinates
stored in an array).

Cheers,

G.

[Jim Cant]

If you're willing to resort to writing code, you could override Roi, give each instance a color, override the draw() method:
class ColorRoi extends Roi
{
    Color myColor = <something nice from the rainbow>
         public void draw(Graphics g)
     {
         Color foundColor = getColor();
         setColor( myColor );
         super.draw( g );
         setColor( foundColor );
     }
However, this is hard to use since there's no way (that I can see) to make the toolkit use ColorRoi instead of Roi.  I resorted to having ColorRoi _contain_  a Roi instance and then have methods that would call into that instance rather than 'super'.  You also have to know whenever ImageJ creates an Roi so you can grab it and build your own ColorInstance from it.  It's a bother but it works.  (I had to do this  because I had some extra state I had to keep with each Roi.)
    If anyone an easier way, PLEASE let me know.

jim
p.s.  Would anyone agree that this seems like a good place for a design pattern.  ImageJ could call a factory method in an RoiFactory class that would return an object implementing an Roi interface.  That way, one could pass a factory to ImageJ and it would get your very own incarnation of an Roi whenever it needed one.  ImageJ's Roi class could then be used as a 'default' which would be sublclassed by the factory.
   


<quote author='William Beaver'>
Hello all,
A question about ROIs I hope someone can shed some light on:  I'd  
like to assign colors to ROI objects.  The problem: ROIColor is a  
static attribute of the Roi class.
...snip...

[Wayne Rasband]

ImageJ 1.38r, due by the end of the week, adds a non-static
setLocalColor() method to the Roi class. The local color overrides the
global color set by the static Roi.SetColor() method.

-wayne

> Hello all,
> A question about ROIs I hope someone can shed some light on:  I'd
> like to assign colors to ROI objects.  The problem: ROIColor is a
> static attribute of the Roi class.
>
> If you beleive that ROIColor is part of each object's state and that
> color could reasonably be different for each Roi, making ROIColor non-
> static seems to be the right solution.  Unfortunately, It does not
> appear that the naive solution of simply making the attribute "non-
> static"  works:  many color preferences are assigned via reference to
> the static Roi.ROIColor.
>
> Would it make sense to change this assumption (ROIColor is static) in
> the Roi class?  I guess I'd need to somehow retain a static ROIColor
> reference for those classes that need a default color (put it into
> Prefs? and make appropriate changes elsewhere?)  and mod ROIColor so
> it is an instance variable.  Any larger issues/impacts I am not aware
> of?
>
> Alternatively, if no one sees value in having ROIs with object level
> attributes, I could store each ROI color in some mapped container
> class and mange them separately;  maybe as part of (something like)
> RoiManager?
>
> Thoughts?
>
> Regards,
> -William
>
> ------------
> William Beaver
> University of California, San Diego
>

[William Beaver]

You read my mind (and eliminated the need for the lengthly post I  
just composed).

Thanks Wayne!
-william

On May 8, 2007, at 1:40 PM, Wayne Rasband wrote:

> ImageJ 1.38r, due by the end of the week, adds a non-static  
> setLocalColor() method to the Roi class. The local color overrides  
> the global color set by the static Roi.SetColor() method.
>
> -wayne
>
>> Hello all,
>> A question about ROIs I hope someone can shed some light on:  I'd
>> like to assign colors to ROI objects.  The problem: ROIColor is a
>> static attribute of the Roi class.
>>
>> If you beleive that ROIColor is part of each object's state and that
>> color could reasonably be different for each Roi, making ROIColor  
>> non-
>> static seems to be the right solution.  Unfortunately, It does not
>> appear that the naive solution of simply making the attribute "non-
>> static"  works:  many color preferences are assigned via reference to
>> the static Roi.ROIColor.
>>
>> Would it make sense to change this assumption (ROIColor is static) in
>> the Roi class?  I guess I'd need to somehow retain a static ROIColor
>> reference for those classes that need a default color (put it into
>> Prefs? and make appropriate changes elsewhere?)  and mod ROIColor so
>> it is an instance variable.  Any larger issues/impacts I am not aware
>> of?
>>
>> Alternatively, if no one sees value in having ROIs with object level
>> attributes, I could store each ROI color in some mapped container
>> class and mange them separately;  maybe as part of (something like)
>> RoiManager?
>>
>> Thoughts?
>>
>> Regards,
>> -William
>>
>> ------------
>> William Beaver
>> University of California, San Diego
>>

-wb

------------
William Beaver
[hidden email]