Menu
▾
▴
matplotlib-devel
|
From: Pim S. <P.S...@as...> - 2011-09-09 14:51:17
|
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 |
|
From: Benjamin R. <ben...@ou...> - 2011-09-12 17:35:44
|
On Fri, Sep 9, 2011 at 9:51 AM, Pim Schellart <P.S...@as...>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 |
|
From: Christoph G. <cg...@uc...> - 2011-09-12 18:35:04
|
On 9/12/2011 10:35 AM, Benjamin Root wrote: > On Fri, Sep 9, 2011 at 9:51 AM, Pim Schellart <P.S...@as... > <mailto:P.S...@as...>> 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 > 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 |
|
From: Pim S. <P.S...@as...> - 2011-09-13 12:19:58
|
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). |
|
From: Eric F. <ef...@ha...> - 2011-09-12 18:10:41
|
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 > 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 > > Kind regards, > > Pim Schellart > |
|
From: Eric F. <ef...@ha...> - 2011-09-13 18:11:21
|
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 > > 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® DevCon Americas, Oct. 18-20, San Francisco, CA > Learn about the latest advances in developing for the > BlackBerry® mobile platform with sessions, labs& more. > See new tools and technologies. Register for BlackBerry® DevCon today! > http://p.sf.net/sfu/rim-devcon-copy1 > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Benjamin R. <ben...@ou...> - 2011-09-13 18:27:57
|
On Tue, Sep 13, 2011 at 1:11 PM, Eric Firing <ef...@ha...> 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 > > We shouldn't forget to add mention of this new colormap to the What's New page. Ben Root |
