Anne Archibald | 1 Dec 05:46 2008
Picon

Specifying colors for a mesh

This seems like a terribly obvious question, but I have had no luck
finding instructions on how to do it in the documentation:

Can I specify my own colors for a mesh? That is, I have an RGB value
for each point. The color= keyword argument appears to require
specifically a single tuple.

If this is for some reason impossible, can I supply my own colormap?
In fact the colors are obtained from temperatures using a blackbody
curve, so I could easily produce a look-up table to use. But it
appears that I can only pass in the name of an existing look-up table.

I've been using the mlab interface, because that's what's documented
on the web. I'm also using version 2.2.0 because that's what's in
Ubuntu Intrepid.

Thanks,
Anne
Gael Varoquaux | 1 Dec 07:38 2008

Re: Specifying colors for a mesh


Hi Anne,

I guess you are talking about Mayavi ("2.2.0" makes me think that). You
should mention it, as there are other soft that people take care of on
this mailing list. Mentioning it in the title is a good way to capture
Prabhu or my attention.

On Sun, Nov 30, 2008 at 11:46:16PM -0500, Anne Archibald wrote:
> Can I specify my own colors for a mesh? That is, I have an RGB value
> for each point. The color= keyword argument appears to require
> specifically a single tuple.

The color argument wont do. It is a global color. You need to specify a
colormap.

> If this is for some reason impossible, can I supply my own colormap?
> In fact the colors are obtained from temperatures using a blackbody
> curve, so I could easily produce a look-up table to use. But it
> appears that I can only pass in the name of an existing look-up table.

Yes. This is an often-requested missing feature, in the easily accessible
API. Here is some code that should do what you want:

    from enthought.mayavi import mlab
    import numpy as np

    s = np.arange(20)
    x = s
    y = z = np.zeros_like(x)
(Continue reading)

Anne Archibald | 1 Dec 08:23 2008
Picon

Re: Specifying colors for a mesh

2008/12/1 Gael Varoquaux <gael.varoquaux@...>:

> I guess you are talking about Mayavi ("2.2.0" makes me think that). You
> should mention it, as there are other soft that people take care of on
> this mailing list. Mentioning it in the title is a good way to capture
> Prabhu or my attention.

Oops! Yes, you're right, I am asking about Mayavi, and I should have
put it in the subject line.

> On Sun, Nov 30, 2008 at 11:46:16PM -0500, Anne Archibald wrote:
>> Can I specify my own colors for a mesh? That is, I have an RGB value
>> for each point. The color= keyword argument appears to require
>> specifically a single tuple.
>
> The color argument wont do. It is a global color. You need to specify a
> colormap.

Ah. That does work for this particular case, but is it really not
possible to simply specify the colors at each vertex? I can certainly
imagine datasets where one would want to do that. I suppose it might
be possible to do something with texture mapping in some cases, but
it's not clear how to do that either.

>> If this is for some reason impossible, can I supply my own colormap?
>> In fact the colors are obtained from temperatures using a blackbody
>> curve, so I could easily produce a look-up table to use. But it
>> appears that I can only pass in the name of an existing look-up table.
>
> Yes. This is an often-requested missing feature, in the easily accessible
(Continue reading)

Gael Varoquaux | 1 Dec 09:06 2008

Re: Specifying colors for a mesh

On Mon, Dec 01, 2008 at 02:23:57AM -0500, Anne Archibald wrote:
> > The color argument wont do. It is a global color. You need to specify a
> > colormap.

> Ah. That does work for this particular case, but is it really not
> possible to simply specify the colors at each vertex?

That would be a whole different underlying VTK mechanism, and I must
confess I really don't know well how VTK does color mapping without a
LUT. I might learn, but it is going to take a while.

> I can certainly imagine datasets where one would want to do that. 

So can I.

> I suppose it might be possible to do something with texture mapping in
> some cases, but it's not clear how to do that either.

That would actually be a good idea. Texture mapping has yet been
integrated into mlab. This doesn't mean you can't use it, but it means
you have to manipulate the objects themselves.

> > That's kinda old, and you could get newer and way better packages on
> > https://launchpad.net/~gael-varoquaux/+archive, but for what you are
> > doing, it should hinder you.

> I have run into a few problems, chiefly that the web documentation
> describes the newer version (for example I can't supply "bgcolor" to
> mlab.figure()). But it appears you only provide those packages for
> gutsy and hardy, not for intrepid. Are newer intrepid packages
(Continue reading)

Anne Archibald | 1 Dec 09:44 2008
Picon

Re: Specifying colors for a mesh

2008/12/1 Gael Varoquaux <gael.varoquaux@...>:

>> I have run into a few problems, chiefly that the web documentation
>> describes the newer version (for example I can't supply "bgcolor" to
>> mlab.figure()). But it appears you only provide those packages for
>> gutsy and hardy, not for intrepid. Are newer intrepid packages
>> available? (the Hardy packages do not work on Intrepid)
>
> Hum, the packages do not work under intrepid? Can you tell me more about
> that? I thought they did, and I don't really understand why this is not
> the case. I need to upgrade one of my boxes to build intrepid packages.
> Maybe this week end.

There was a version conflict in one of the dependencies. It seems to
run aground on a problem with "landscape", some Ubuntu configuration
tool. I'm just guessing; the error shows up on import, and the mayavi2
import process is, ah, involved.

Anne

Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49)
Type "copyright", "credits" or "license" for more information.

IPython 0.8.4 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

In [1]: from enthought.mayavi.plugins.app import Mayavi, setup_logger
(Continue reading)

Gael Varoquaux | 1 Dec 09:48 2008

Re: Specifying colors for a mesh

On Mon, Dec 01, 2008 at 03:44:46AM -0500, Anne Archibald wrote:
> There was a version conflict in one of the dependencies. It seems to
> run aground on a problem with "landscape", some Ubuntu configuration
> tool. I'm just guessing; the error shows up on import, and the mayavi2
> import process is, ah, involved.

Ah, it seems you have found a missing requirement in our packages. Try
installing python-configobj and tell us if it fixes the problem. If so,
we need to correct the packages.

Thanks for your report.

Gaël
Prabhu Ramachandran | 1 Dec 10:33 2008
Picon

Re: Specifying colors for a mesh

Hi Anne,

Anne Archibald wrote:
> This seems like a terribly obvious question, but I have had no luck
> finding instructions on how to do it in the documentation:
> 
> Can I specify my own colors for a mesh? That is, I have an RGB value
> for each point. The color= keyword argument appears to require
> specifically a single tuple.

Thats the way it currently works unfortunately.  It is possible to 
specify scalars as RGB colors by specifying a 3 component unsigned char 
array with the rgb values (each in the range [0, 255]).  But this 
feature of VTK hasn't been exploited by us in mlab/mayavi.  We tend to 
treat scalars as a single dimensional array and use a suitable LUT to do 
the coloring.

> If this is for some reason impossible, can I supply my own colormap?

Yes indeed.  If none of the standard luts are good enough, there is a 
color editor that lets you generate your own lut files.  To run it try this:

#!/usr/bin/env python
from enthought.tvtk.util.wx_gradient_editor import main
main()

Then use the resulting .lut file for your colormap.

> In fact the colors are obtained from temperatures using a blackbody
> curve, so I could easily produce a look-up table to use. But it
(Continue reading)

Prabhu Ramachandran | 1 Dec 10:34 2008
Picon

Re: [M2] New source names?

Gael Varoquaux wrote:
> You were asking for some feedback on the names. First of all, I am not
> sure these sources need to be prefixed with 'VTK': 'ImageDataSource', or,
> if you are worried the name is too generic, maybe 'ImageExamples', or
> 'StandardImage', or 'ImageFactory'. As for the polydata source, I am
> quite afraid that it may be hard for the non-specialist to figure out
> what 'PolyData' is about. I would almost like to call 'StandardWidget',
> or better, 'WidgetFactory', to reflect the 'StandardImage'. So we would
> now have 'ParametricSurface', 'WidgetFactory' and 'ImageFactory'.

Thanks for the feedbakc. How about ImageFactory and SurfaceFactory?  I 
don't quite like widget factory since widgets mean something specific in 
VTK.

cheers,
prabhu
Gael Varoquaux | 1 Dec 10:35 2008

Re: [M2] New source names?

On Mon, Dec 01, 2008 at 03:04:25PM +0530, Prabhu Ramachandran wrote:
> Gael Varoquaux wrote:
> > You were asking for some feedback on the names. First of all, I am not
> > sure these sources need to be prefixed with 'VTK': 'ImageDataSource', or,
> > if you are worried the name is too generic, maybe 'ImageExamples', or
> > 'StandardImage', or 'ImageFactory'. As for the polydata source, I am
> > quite afraid that it may be hard for the non-specialist to figure out
> > what 'PolyData' is about. I would almost like to call 'StandardWidget',
> > or better, 'WidgetFactory', to reflect the 'StandardImage'. So we would
> > now have 'ParametricSurface', 'WidgetFactory' and 'ImageFactory'.

> Thanks for the feedbakc. How about ImageFactory and SurfaceFactory?  I 
> don't quite like widget factory since widgets mean something specific in 
> VTK.

How about 'ObjectFactory', then? Or 'GlyphFactory'. I actually like
'GlyphFactory' best. 'SurfaceFactory' is quite OK, thought,
IMHO.

Gaël
Anne Archibald | 1 Dec 11:18 2008
Picon

Re: Specifying colors for a mesh

2008/12/1 Gael Varoquaux <gael.varoquaux@...>:
> On Mon, Dec 01, 2008 at 03:44:46AM -0500, Anne Archibald wrote:
>> There was a version conflict in one of the dependencies. It seems to
>> run aground on a problem with "landscape", some Ubuntu configuration
>> tool. I'm just guessing; the error shows up on import, and the mayavi2
>> import process is, ah, involved.
>
> Ah, it seems you have found a missing requirement in our packages. Try
> installing python-configobj and tell us if it fixes the problem. If so,
> we need to correct the packages.
>
> Thanks for your report.

Yes, it seems to work fine now.

Thanks!

Anne

Gmane