On 09/09/2011 04:51 AM, Pim Schellart 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
> 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
> 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
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
Submission via github would be nice, but is not required.
> Kind regards,
> Pim Schellart