Implementation of cubehelix color scheme

Dear Developers,

In the field of Astronomy (and in science in general) we often make
images that represent the intensity of some source.
However the color schemes used to display images are not perceived as
increasing monotonically in brightness.
D.A. Green developed a color scheme that does increase monotonically
in brightness and this scheme is already in use in several data
display packages (e.g. CASA and AIPS, two software packages used to
analyze radio astronomy data).
The paper describing this algorithm can be found here
http://arxiv.org/abs/1108.5083
The main advantage of this color map is that images will look
monotonically increasing in brightness to the eye both on color screen
and when printed in black and white (as is often needed for scientific
papers).
Attached is a patch for _cm.py to add this colormap (named cubehelix
as it is named in CASA) to the list of matplotlib colormaps.

Complicating this a bit is the fact that the algorithm takes several
parameters as specified in the paper referred to (start color, number
of rotations, hugh parameter and gamma factor).
These parameters are now set to the values they have in the default
CASA color map but ideally they could be changed by the user.
I could not find any other colormap that has this option so I don't
know what the preffered way of doing this is, therefore I left the
values hardcoded which should be ok for most applications anyway.
Please let me know what you think.

Kind regards,

Pim Schellart

0001-Added-cubehelix-monotonically-increasing-colorscheme.patch (1.82 KB)

Do we want to add this colormap in the upcoming release, or do we want to wait for the next release?

Ben Root

···

On Fri, Sep 9, 2011 at 9:51 AM, Pim Schellart <P.Schellart@…55…1019…> wrote:

Dear Developers,

In the field of Astronomy (and in science in general) we often make

images that represent the intensity of some source.

However the color schemes used to display images are not perceived as

increasing monotonically in brightness.

D.A. Green developed a color scheme that does increase monotonically

in brightness and this scheme is already in use in several data

display packages (e.g. CASA and AIPS, two software packages used to

analyze radio astronomy data).

The paper describing this algorithm can be found here

http://arxiv.org/abs/1108.5083

The main advantage of this color map is that images will look

monotonically increasing in brightness to the eye both on color screen

and when printed in black and white (as is often needed for scientific

papers).

Attached is a patch for _cm.py to add this colormap (named cubehelix

as it is named in CASA) to the list of matplotlib colormaps.

Complicating this a bit is the fact that the algorithm takes several

parameters as specified in the paper referred to (start color, number

of rotations, hugh parameter and gamma factor).

These parameters are now set to the values they have in the default

CASA color map but ideally they could be changed by the user.

I could not find any other colormap that has this option so I don’t

know what the preffered way of doing this is, therefore I left the

values hardcoded which should be ok for most applications anyway.

Please let me know what you think.

Kind regards,

Pim Schellart

Dear Developers,

In the field of Astronomy (and in science in general) we often make
images that represent the intensity of some source.
However the color schemes used to display images are not perceived as
increasing monotonically in brightness.
D.A. Green developed a color scheme that does increase monotonically
in brightness and this scheme is already in use in several data
display packages (e.g. CASA and AIPS, two software packages used to
analyze radio astronomy data).
The paper describing this algorithm can be found here
http://arxiv.org/abs/1108.5083
The main advantage of this color map is that images will look
monotonically increasing in brightness to the eye both on color screen
and when printed in black and white (as is often needed for scientific
papers).
Attached is a patch for _cm.py to add this colormap (named cubehelix
as it is named in CASA) to the list of matplotlib colormaps.

Complicating this a bit is the fact that the algorithm takes several
parameters as specified in the paper referred to (start color, number
of rotations, hugh parameter and gamma factor).
These parameters are now set to the values they have in the default
CASA color map but ideally they could be changed by the user.
I could not find any other colormap that has this option so I don't
know what the preffered way of doing this is, therefore I left the
values hardcoded which should be ok for most applications anyway.
Please let me know what you think.

Adding this colormap would be good, but I would much prefer to see it done in a more general and readable fashion, with a docstring including some explanation and a citation with link to the reference. (A little editing of your message above would take care of it.)

I would suggest making a "cubehelix" function, taking the colormap parameters as kwargs with the present defaults, and returning the dictionary. The lambda functions can be replaced with named functions nested in the main function. Line lengths should be no greater than 80 characters.

The _cubehelix_data would then be created by a call to the function.

I think that this re-arrangement and documentation could be done very easily and quickly, and would make the contribution much nicer. It would also leave in place the mechanism for a user to create a variation of the cubehelix; the cubehelix function could be imported into the cm namespace, so that one could make a custom data dictionary for use in register_cmap.

Submission via github would be nice, but is not required.

Eric

···

On 09/09/2011 04:51 AM, Pim Schellart wrote:

Kind regards,

Pim Schellart

Please also consider adding the "coolwarm" color map suggested before by Sameer Grover <http://sourceforge.net/mailarchive/message.php?msg_id=27816391>. That message has a patch attached.

The colormap is used by Kitware (ParaView) and was designed around these requirements:

"""
– The map yields images that are aesthetically pleasing.
– The map has a maximal perceptual resolution.
– Interference with the shading of 3D surfaces is minimal.
– The map is not sensitive to vision deficiencies.
– The order of the colors should be intuitively the same for all people.
– The perceptual interpolation matches the underlying scalars of the map.
"""
<http://www.cs.unm.edu/~kmorel/documents/ColorMaps/index.html>

Thank you,

Christoph

···

On 9/12/2011 10:35 AM, Benjamin Root wrote:

On Fri, Sep 9, 2011 at 9:51 AM, Pim Schellart <P.Schellart@…1019… > <mailto:P.Schellart@…1019…>> wrote:

    Dear Developers,

    In the field of Astronomy (and in science in general) we often make
    images that represent the intensity of some source.
    However the color schemes used to display images are not perceived as
    increasing monotonically in brightness.
    D.A. Green developed a color scheme that does increase monotonically
    in brightness and this scheme is already in use in several data
    display packages (e.g. CASA and AIPS, two software packages used to
    analyze radio astronomy data).
    The paper describing this algorithm can be found here
    http://arxiv.org/abs/1108.5083
    The main advantage of this color map is that images will look
    monotonically increasing in brightness to the eye both on color screen
    and when printed in black and white (as is often needed for scientific
    papers).
    Attached is a patch for _cm.py to add this colormap (named cubehelix
    as it is named in CASA) to the list of matplotlib colormaps.

    Complicating this a bit is the fact that the algorithm takes several
    parameters as specified in the paper referred to (start color, number
    of rotations, hugh parameter and gamma factor).
    These parameters are now set to the values they have in the default
    CASA color map but ideally they could be changed by the user.
    I could not find any other colormap that has this option so I don't
    know what the preffered way of doing this is, therefore I left the
    values hardcoded which should be ok for most applications anyway.
    Please let me know what you think.

    Kind regards,

    Pim Schellart

Do we want to add this colormap in the upcoming release, or do we want
to wait for the next release?

Ben Root

Dear Eric (and other developers),

I have implemented the requested changes and the resulting diff can be
seen at https://github.com/pschella/matplotlib/compare/master...cubehelix
I tried to do a better job at documentation and hope this is
sufficient, let me know if something is missing.
I'm not sure exactly what you meant with your suggestion to define
named functions inside the main function body but I hope my new
implementation more closely matches your wishes.
I have opted for a factory function within the main function to avoid
the code duplication associated with creating a named function for
each color component.

Kind regards,

Pim Schellart

P.S. Sorry for submitting the patch directly on the mailing list
before, I simply followed the link on how to contribute from the
matplotlib FAQ and didn't look at what was stated above the section
scrolled to automatically (maybe something to change).

Dear Eric (and other developers),

I have implemented the requested changes and the resulting diff can be
seen at https://github.com/pschella/matplotlib/compare/master...cubehelix
I tried to do a better job at documentation and hope this is
sufficient, let me know if something is missing.

Pim,

I haven't tried it yet, but the code looks nice! Go ahead and click your "pull request" button so that it shows up on the main matplotlib repo list of pull requests.

I'm not sure exactly what you meant with your suggestion to define
named functions inside the main function body but I hope my new
implementation more closely matches your wishes.

It does. I did not recognize that only a single function was needed.

I have opted for a factory function within the main function to avoid
the code duplication associated with creating a named function for
each color component.

Good!

Eric

···

On 09/13/2011 02:19 AM, Pim Schellart wrote:

Kind regards,

Pim Schellart

P.S. Sorry for submitting the patch directly on the mailing list
before, I simply followed the link on how to contribute from the
matplotlib FAQ and didn't look at what was stated above the section
scrolled to automatically (maybe something to change).

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Learn about the latest advances in developing for the
BlackBerry&reg; mobile platform with sessions, labs& more.
See new tools and technologies. Register for BlackBerry&reg; DevCon today!
http://p.sf.net/sfu/rim-devcon-copy1
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

We shouldn’t forget to add mention of this new colormap to the What’s New page.

Ben Root

···

On Tue, Sep 13, 2011 at 1:11 PM, Eric Firing <efiring@…229…> wrote:

On 09/13/2011 02:19 AM, Pim Schellart wrote:

Dear Eric (and other developers),

I have implemented the requested changes and the resulting diff can be

seen at https://github.com/pschella/matplotlib/compare/master…cubehelix

I tried to do a better job at documentation and hope this is

sufficient, let me know if something is missing.

Pim,

I haven’t tried it yet, but the code looks nice! Go ahead and click

your “pull request” button so that it shows up on the main matplotlib

repo list of pull requests.

I’m not sure exactly what you meant with your suggestion to define

named functions inside the main function body but I hope my new

implementation more closely matches your wishes.

It does. I did not recognize that only a single function was needed.

I have opted for a factory function within the main function to avoid

the code duplication associated with creating a named function for

each color component.

Good!

Eric