one node displaying multiple colors

[jtlee]

Here's the topic this discussion refers to,
"One node showing multiple colours"
http://groups-beta.google.com/group/cytoscape-discuss/browse_frm/thread/cbc9b5b3f2db4489/a9e2fae75b2a4740?lnk=gst&q=one+node+multiple&rnum=1#a9e2fae75b2a4740

This topic ended a year back, but I'm looking for a way to do exactly
what everyone was talking about, but I lack the programming experience
to fiddle with the source code.

How were you able to get those multiple colors for each node? I'd like
to do the same display based on gene expression data.

Thanks in advanced,

Jason Lee

[WLigt...@gmail.com]

I wasn't able to get multiple colours.
The information posted there is out of date, by the way.
It is possible to do it yourself now. But there is as far as I know no
plugin that you can use, to get it done without programming.
Later if I have some extra time, I might write a plugin to enable
multiple colour visualisation, but I have already heard that the
VizMapper will be upgraded as well, and my guess is that if that is
done, maybe multiple colour support is included as well.
But I have no idea, on how soon to expect this.

Hope this helps,

Willem Ligtenberg

[jtlee]

Does it take extensive programming or a few line manipulations? I have
some C programming background, but not in java though.

Jason

On Nov 16, 2:59 am, "WLigtenb...@gmail.com" <WLigtenb...@gmail.com>
wrote:

[WLigt...@gmail.com]

Well, it probably will require some coding.
But I have just decided to start writing a plugin that does this.
I will describe my idea here, to get some feedback.
I want to write a plugin that allows the user to select one attribute
to use for coloring.
This attribute needs to be a List.
Then I want to generate a new node (first only one view) (a pie chart
like view)
Which uses the NodeColorCalculator to calculate the color of the node.
And then all nodes in the current network are update using this new
coloring.
Any remarks, or tips on how to do this? (Nerius? :) )

Willem

[Lee, Jason Thanh]

I'll definitely be looking forward to this plugin. I notice GenePro has an
option to divide up a node into a pie-chart like object. I haven't explored
it enough yet but, at first glance, it doesn't seem to be just a
visualization tool that one can use to correlate with expression matrix
data.

I have a question but it's more for my sake when I get to use the plugin
than to help you in writing the code. What do you mean by:

>Then I want to generate a new node (first only one view) (a pie chart
>like view)
>Which uses the NodeColorCalculator to calculate the color of the node.

Jason

[WLigt...@gmail.com]

What I mean with this, is that the user can select a way to color the
nodes, using the visualstyle mapper icon.
My idea as it is now, is to misuse the NodeColorCalculator to calculate
a color for a certain temporary attribute, because the
NodeColorCalculator, can only calculate a color for a certain node. So
I will change the attribute for each item in the list, to get the color
that belongs with it.
In this way, I don't need to reinvent the wheel on a gui for specifying
the nodeColors.

[WLigt...@gmail.com]

Actually I had a change of plans today.
I got a new idea, and I am going to extend the
GenericNodeColorCalculator.
This is a far better solution.
But still working on it...

[Mike Smoot]

Hi Willem, et al.,

There are several things to mention here.

• GenericNodeColorCalculator has been split into two specific calculators: GenericNodeFillColorCalculator and GenericNodeBorderColorCalculator.  This facilitates changes to CalculatorCatalog, NodeAppearanceCalculator, and others that vastly simplify their operation.
• The various calculator interfaces (e.g. NodeColorCalculator) have been deprecated.  Only the Calculator interface remains, and the best way to implement that is to extend NodeCalculator or EdgeCalculator.  The type of calculator is now distinguished by a getType() method which returns one of the types defined in VizMapUI.java (e.g. NODE_BORDER_COLOR) rather than by separate interfaces.  Again, this should vastly simplify things.
• The way things currently work, it's not clear to me that what you propose will work.  The problem is that NodeAppearance only supports setting of color using Color objects.  Instead, NodeAppearance should set the color using an implementation of the Paint interface.  This way we could have things like gradients, texture maps, etc..  I've briefly looked at making this change and to properly support Paint will require a lot of change, something that won't happen in the 2.4 timeframe.  I can, however, add setPaint/getPaint methods to NodeAppearance that should provide some basic support.
• Once you can set the Paint, then I think you'd need to create an ObjectMapping class that returns the customized Paint object. 
  
• However, even that may not be enough.  We may need to provide full support for setting custom graphics through the giny interface. Ding supports this, but I don't think support is there for giny yet.
  
• I like the idea of using a list or map attribute to set the various colors.
• Sorry for being discouraging!  In the interim, you might talk to the GenePro folks.  I know that they've got a working implementation of pie nodes that works with the new rendering engine, so perhaps that can provide some more useful help.

thanks,
Mike

tel: 858-822-4756         University of California San Diego

[WLigt...@gmail.com]

Mike Smoot wrote:
> Hi Willem, et al.,
>
> There are several things to mention here.
>

> - GenericNodeColorCalculator has been split into two specific

> calculators: GenericNodeFillColorCalculator and
> GenericNodeBorderColorCalculator. This facilitates changes to
> CalculatorCatalog, NodeAppearanceCalculator, and others that vastly simplify
> their operation.

This is for Cytoscape 2.4 right?
At the moment I'm still working in Cytoscape 2.3 code. But I don't see
a huge change here. Should be easy to use the classes to inherit from.

> - The various calculator interfaces (e.g. NodeColorCalculator) have

> been deprecated. Only the Calculator interface remains, and the best way to
> implement that is to extend NodeCalculator or EdgeCalculator. The type of
> calculator is now distinguished by a getType() method which returns one of
> the types defined in VizMapUI.java (e.g. NODE_BORDER_COLOR) rather
> than by separate interfaces. Again, this should vastly simplify things.

OK, so it should still work, but will be phased out, even better :)

> - The way things currently work, it's not clear to me that what you

> propose will work. The problem is that NodeAppearance only supports setting
> of color using Color objects. Instead, NodeAppearance should set the color
> using an implementation of the Paint interface. This way we could have
> things like gradients, texture maps, etc.. I've briefly looked at making
> this change and to properly support Paint will require a lot of change,
> something that won't happen in the 2.4 timeframe. I can, however, add
> setPaint/getPaint methods to NodeAppearance that should provide some basic
> support.

At this moment I am using the Ding library to create CustomNodes.
So I don't think this really matter, am I right?

> - Once you can set the Paint, then I think you'd need to create an

> ObjectMapping class that returns the customized Paint object.

The only thing I need at this moment is to use a ObjectMapping, stored
in the VisualMappingManager.
Somewhere deep down, Cytoscape needs a calculator that calculates a
Color, by using a ObjectMapping on a certain value. At the moment I can
only locate this:
Color fill =
(Color)super.getMapping(0).calculateRangeValue(attrBundle);
Which uses the attributes. Since this part cannot handle lists, I want
to go around that and specify a calculateRangeValue(List list) in my
own class, which takes a List of values as an argument, but uses the
same ObjectMapping as it would normally do on an Attribute. We could
make that a fixed attribute for now. Say color, which has to be
specified in the visualmapper stuff first. Then my plugin will get that
mapping and use it, not on that attribute but on another (maybe fixed
at first) attribute say multiValue.
In this way, I could generate all the Colors needed. And I could create
the shapes and color them accordingly.

> - However, even that may not be enough. We may need to provide full

> support for setting custom graphics through the giny interface. Ding
> supports this, but I don't think support is there for giny yet.

I am using the Ding library.

> - I like the idea of using a list or map attribute to set the various
> colors.
> - Sorry for being discouraging! In the interim, you might talk to the

> GenePro folks. I know that they've got a working implementation of pie
> nodes that works with the new rendering engine, so perhaps that can provide
> some more useful help.
>

My guess, is that they use their own code to calculate Colors, which is
fine, but I would prefer to use the ObjectMappings from Cytoscape.

>
> thanks,
> Mike

[Mike Smoot]

Here is how I think you can accomplish what you want:

Write a new Calculator, probably one that overrides
GenericNodeFillColorCalculator, and you'll need to write a new apply()
method. This apply() method will be different than existing apply
method in that instead of setting a value in a NodeAppearance (e.g.
fill color), you will have to get the actual DNodeView and manipulate
that directly, either using the custom node graphics, or by creating a
clever Paint object.

How you calculate the node colors will be determined using a new
ObjectMapping object. I'm not precisely sure what needs to happen,
but you will definitely need to write your own
calculateRangeValue(attrBundle) method. You can continue to use the
existing interface, meaning you just need the attrBundle (all of the
attributes set for the given node) and you shouldn't have to get your
own list (any list attribute should already be included in the
bundle). calculateRangeValue(attrBundle) returns an Object, so it can
be whatever kind of object you desire, such as a List<Color> that
could represent the colors in your pie chart or whatever.

To summarize, the new ObjectMapping will take the attrBundle, find the
list attribute you want to use to generate your colors, generate the
colors, and return a list of those colors. The list of colors returned
from calculateRangeValue() is then used by the Calculuator you just
wrote to change the visualization of a DNodeView.

Make sense?

Mike

--
____________________________________________________________
Michael Smoot, Ph.D. Bioengineering Department

[WLigt...@gmail.com]

Yes that makes a lot of sense!
I was working on a different route though. In which I made the
getRangeValue method public.
But your suggestion is better. And I will try to go that way.

Cheers,

Willem

By the way, have a nice Holiday!

[WLigt...@gmail.com]

Good news!
At this moment I have a working plugin. However I still need to allows
the user to select an attribute. (This can be done easily)
Also at this moment only one visualisation is implemented. Horizontal
bars are painted for each value in the list.
Also this plugin is a bit of a hack, because I misuse the normal
NodeColorCalculator.
As the plugin is right now, first the user should specify the NodeColor
using the Vizmapper for a given attribute "multi". This is an attribute
(not a list) which gets the value for each item in the list. Through
the vizmapper the user can then create the NodeColorCalculator. To be
able to do this, the user should define this attribute. (Maybe later I
can do that automatically)
The attribute which contains the list, is at this moment "Rank List",
but as said, this is easy to change so that the user can define it.
Also I already have implemented in such a way, that more visualisation
can be implemented.
But the thing I don't yet have an answer to, is how to get rid of the
dummy attribute I use.
I use that so that I can use Color fill =
(Color)super.getRangeValue(node); to get the color.
So far I have not seen a way around this, because:
private Object getRangeValue(Number domainValue) { is as you can see a
private function.

However in the near future, I think I can have a plugin, which let's
the user specify the attribute which contains the list. Supports
Numbers, Strings and booleans in the list. And maybe automatically
detect the Attribute that is currently being used for colormapping.
In this case, the user still needs to define a dummy attribute, but is
no longer restricted to use the name multi for it.

But maybe I just should do some more coding and create a seperate GUI
to get the multio node colouring done correctly. Then I could use my
own (to be written) Calculator which does know how to handle Lists. But
that will require a lot more work. So I will first try the things
mentioned above and put that out, for people to use.