[matplotlib-devel] Produce text runs in the postscript backend
Hi, I posted on the user list a while back about saving editable text using the postscript backend [1]. There I was informed that this was changed a few years ago to individually place glyphs. It looks to me, that this change was about correctly supporting unicode in this backend [2]. Would the project be open to changing this to produce text runs when all of the characters are ascii? This way, the general unicode case should still work but runs of text where the special handling is not necessary should result in editable text. I'm happy to work up a patch, but I don't want to spend the time if there is no hope of it being merged. My use case is to be able to make some tweaks to figures post mpl. In my case this tends to be to either combine figures from several sources into a single coherent figure or to adjust the figure size or spacing slightly so the final figure fits into the space available. All of this can be done in mpl directly, but in terms of effective use of my time, opening the figure in Corel Draw, Inkscape or Illustrator is much faster since I can get the figure 90% of the way there quickly and easily using mpl. Eric 1. http://thread.gmane.org/gmane.comp.python.matplotlib.general/34816 2. https://github.com/matplotlib/matplotlib/commit/80321a3b489994748b79e41bc34a65f836a9a03f -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
The problem I have with hcl is that while it is technically "colorful" (or whatever the term may be), only the reds really come out because the other colors are only used when either really light or really dark. Perhaps squashing the brightness range a bit and let the natural lightness of yellow and the natural darkness of blue come through on their own. (does that even make any sense to anybody else? it makes sense in my head, but I am certainly am not an expert in color perception) Ben Root P.S. - Of course, my own color perception weirdness might be at play here and the colormap looks perfectly fine to everybody else... On Wed, Feb 18, 2015 at 11:17 AM, Maximilian Albert < [email protected]> wrote: > 2015-02-17 1:23 GMT+01:00 Michael Waskom : > >> See [here](http://nbviewer.ipython.org/gist/mwaskom/6a43a3b94eca4a9e2e8b) >> for a quick and dirty implementation that should get a general idea. This >> probably ins't the best way to do it -- anyone should feel free to build on >> this. >> > > This is very neat! Great job. Incidentally, when I stumbled upon the > earthobservatory blog a while ago this particular colormap also caught my > eye as a potential candidate, so I'm glad you suggested it as a starting > point for a new matplotlib default. > > Out of curiosity, I applied Nathaniel's "viscm" function (from the > previous thread) to the colormap from your notebook (screenshot attached). > Interestingly, while it confirms that the lightness and hue angle increase > more or less linearly, the "colourfulness" goes up and down in waves, even > though you designed the chroma to increase linearly, too. I'm not sure > whether this is because "colourfulness" and "chroma" are actually two > different concepts, or whether it has to do with inaccuracies and/or > clamping during the conversion between various colour spaces. It could also > be the case that the colormath and pycam02ucs modules use different > conversion formulas (in which case it would be good to know which is "more > accurate"; not sure there is even an objective measure for "accuracy" in > this case). Also, there seems to be something strange going on at the dark > (blue) end of the colormap, but this could again be due to clamping. > > I'd love to play a bit more with your example notebook but not sure I'll > be able to do so before the weekend (or early next week). > > Cheers, > Max > > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On 2015/02/18 6:31 AM, Benjamin Root wrote: > The problem I have with hcl is that while it is technically "colorful" > (or whatever the term may be), only the reds really come out because the > other colors are only used when either really light or really dark. > Perhaps squashing the brightness range a bit and let the natural > lightness of yellow and the natural darkness of blue come through on > their own. (does that even make any sense to anybody else? it makes > sense in my head, but I am certainly am not an expert in color perception) > > Ben Root > > P.S. - Of course, my own color perception weirdness might be at play > here and the colormap looks perfectly fine to everybody else... My own reaction to it is that it seems like a nicely *functional* colormap, one I would want to have available and probably would sometimes use, but it is not particularly aesthetically *pleasing*. I think this is consistent with Olga's earlier post as well. Eric -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
Cool! I knew there had been some useful tools posted on the earlier thread but didn't have time to dig them out. Interesting observation about the colorfulness. I don't know enough about all the transformations involved to full account for that, but I added some stuff to the notebook to figure out how much of that might be caused by straying out of gamut. It looks like the map I created does a pretty good job and is only getting clamped at the very low end and near the high end, so I don't think it's a complete explanation for the undulating "colorfulness": http://nbviewer.ipython.org/gist/mwaskom/6a43a3b94eca4a9e2e8b By means of disclosure, I did this before having coffee, so it might be wrong... -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
I've made a second notebook that uses the IPython interactive machinery to let anyone play with the parameters and explore different ways of setting them. you can download the notebook with that here: http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it using IPython 3.0rc1; I'm not certain if it will work on the 2.x series; sorry if that is the case). This stays with the general approach in the original notebook of using a linear ramp for chroma, which again maybe is not what we want. But it should let you get a better sense for the parameter space. As I said in the email to Olga, I think (a) I would advocate fairly strongly that matplotlib should design a custom colormap as its default, and (b) I think this approach (a cubehelix-like map in Hcl space) is a principled way of doing so (though maybe not optimal). But both of those points are independent of whether you end up going with the particular parameters that I used to generate the original proposal -- I have my own domain on which to impose my personal aesthetic preferences, and I don't need to take over matplotlib too :) (But I do think it's worth distinguishing the matplotlib default from the matlab default.) Michael -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On Feb 16, 2015 3:39 PM, "Eric Firing" wrote:
>
> On 2015/02/16 1:29 PM, Michael Waskom wrote:
>
> > Nathaniel's January 9 message in that thread (can't figure out how to
> > link to it in the archives) had a suggestion that I thought was very
> > promising, to do something similar to Parula but rotate around the hue
> > circle the other direction so that the hues would go blue - purple - red
> > - yellow. I don't think we've seen an example of exactly what it would
> > look like, but I reckon it would be similar to the middle colormap here
> > http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
> > (from the elegant figures block series linked above), which I've always
> > found quite attractive.
>
> Certainly it can be considered--but we have to have a real implementation.
While I hate to promise vaporware, I actually was planning to have a
go at implementing such a colormap in the next few weeks, based on
optimizing the same set of parameters that viscm visualizes... FWIW.
Are we planning to make other default appearance changes at the same
time? The idea of changing the color cycle and/or dot-dash cycle has
already come up in this thread, and this earlier thread proposed
several more good ideas [1]:
http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166
I agree that now is definitely the time to get serious about making
these changes, but it seems like there's enough to be worked out that
sticking to the original plan and keeping mainline quasi-frozen until
2.0 is ready might create frustration and hasty decisions. Maybe it
would be less stressful all around if we let mainline development
proceed at whatever pace makes sense while these things get sorted
out, and then once the appearance changes are ready make the call
about whether to cut a quick 1.5 first or not? Presumably these
defaults will stick around for many years so it's worth taking a few
months to get a complete proposal together, get feedback, etc., IMO.
In an ideal world version 1.last might even provide a
style.use("matplotlib2") command to preview what 2.0 will do, just
like 2.0 will presumably have a style.use("matplotlib1") command for
those who want to (temporarily) revert.
-n
[1] well I would think that wouldn't I ;-)
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
FYI the notebook isn't working for me in IPython 2.2.0 I agree with Michael's sentiment that from a marketing perspective, a matplotlib-only colormap is advantageous to maintain a consistent brand. Will these colormaps also be used for non-imshow/colormesh/pcolormesh data, as in for line colors as well? I think that's a great idea! It'll make the black and white versions easier to understand since the changing colors will monotonically increase/decrease in darkness rather than randomly changing. RE: Nathaniel - I'm not as much of a fan of changing line styles in addition to colors, but that's my personal preference for plotting lines specifically. When plotting scatters, I think it does make sense, since the room to perceive a change in color is so small, that a change in shape helps too. On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom wrote: > I've made a second notebook that uses the IPython interactive machinery to > let anyone play with the parameters and explore different ways of setting > them. you can download the notebook with that here: > http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it > using IPython 3.0rc1; I'm not certain if it will work on the 2.x series; > sorry if that is the case). > > This stays with the general approach in the original notebook of using a > linear ramp for chroma, which again maybe is not what we want. But it > should let you get a better sense for the parameter space. > > As I said in the email to Olga, I think (a) I would advocate fairly > strongly that matplotlib should design a custom colormap as its default, > and (b) I think this approach (a cubehelix-like map in Hcl space) is a > principled way of doing so (though maybe not optimal). But both of those > points are independent of whether you end up going with the particular > parameters that I used to generate the original proposal -- I have my own > domain on which to impose my personal aesthetic preferences, and I don't > need to take over matplotlib too :) > > (But I do think it's worth distinguishing the matplotlib default from the > matlab default.) > > Michael > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/ > 4140/ostg.clktrk___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On Wed, Feb 18, 2015 at 4:42 PM, Olga Botvinnik wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > Oops, sorry. > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. > Just to be clear, I wasn't suggesting *matplotlib only* in the (legal) sense that parula is matlab only, just that it should be identifiably "the matplotlib colormap". > Will these colormaps also be used for non-imshow/colormesh/pcolormesh > data, as in for line colors as well? I think that's a great idea! It'll > make the black and white versions easier to understand since the changing > colors will monotonically increase/decrease in darkness rather than > randomly changing. > I wasn't really thinking the plt.plot line cycle, more about plt.scatter, plt.contour, etc. and other places that accept a cmap argument but don't draw an "image-like" plot. Though, having a default colormap that can be used when you want to encode a quantitative value in the color of lines, e.g. the figures here: http://www.machenslab.org/publications/machens_etal_2010.pdf, would be good too. That's somewhere you often find people using jet. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
@Nathaniel I think developing the color-overhaul as a maintenance release is a decent compromise. All non-color changes get directed at the master branch and we can cherry-picked back bug-fixes as needed. The next feature release is planned for July/August, I _really_ hope sorting out the colors does not take that much longer. if we start to Paint a Bike Shed that just needs to be shut down. I am not sure how I feel about a _default_ non-trivial style-cycle. +1 on providing the machinery and rcparams to do it and agnostic which branch it goes on. @Olga I think there are two separate issues, the default color map used by ScalarMappable and the default color cycle that `ax.plot` and company use. I think both should be up for discussion and do not _need_ to use the same colors. Tom On Wed Feb 18 2015 at 7:43:31 PM Olga Botvinnik wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. > > Will these colormaps also be used for non-imshow/colormesh/pcolormesh > data, as in for line colors as well? I think that's a great idea! It'll > make the black and white versions easier to understand since the changing > colors will monotonically increase/decrease in darkness rather than > randomly changing. > > RE: Nathaniel - I'm not as much of a fan of changing line styles in > addition to colors, but that's my personal preference for plotting lines > specifically. When plotting scatters, I think it does make sense, since the > room to perceive a change in color is so small, that a change in shape > helps too. > > On Wed Feb 18 2015 at 9:40:00 AM Michael Waskom > wrote: > >> I've made a second notebook that uses the IPython interactive machinery >> to let anyone play with the parameters and explore different ways of >> setting them. you can download the notebook with that here: >> http://nbviewer.ipython.org/gist/mwaskom/842d1497b6892d081bfb (I made it >> using IPython 3.0rc1; I'm not certain if it will work on the 2.x series; >> sorry if that is the case). >> >> This stays with the general approach in the original notebook of using a >> linear ramp for chroma, which again maybe is not what we want. But it >> should let you get a better sense for the parameter space. >> >> As I said in the email to Olga, I think (a) I would advocate fairly >> strongly that matplotlib should design a custom colormap as its default, >> and (b) I think this approach (a cubehelix-like map in Hcl space) is a >> principled way of doing so (though maybe not optimal). But both of those >> points are independent of whether you end up going with the particular >> parameters that I used to generate the original proposal -- I have my own >> domain on which to impose my personal aesthetic preferences, and I don't >> need to take over matplotlib too :) >> >> (But I do think it's worth distinguishing the matplotlib default from the >> matlab default.) >> >> Michael >> > >> -- >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/ >> 4140/ostg.clktrk___ >> Matplotlib-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/ > 4140/ostg.clktrk___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On 2015/02/18 2:42 PM, Olga Botvinnik wrote: > FYI the notebook isn't working for me in IPython 2.2.0 > > I agree with Michael's sentiment that from a marketing perspective, a > matplotlib-only colormap is advantageous to maintain a consistent brand. Provided we can find a good colormap for that purpose; right now the only sequential proposals are gray, YlGnBu, and Michael's new HCL. Aesthetically, I find boring old YlGnBu the most pleasant of this small set. I agree with Michael's point that its yellow end might be lighter than optimum. To me, the HCL map is not downright ugly, but its definitely not appealing, either. My guess is that the prevalence of blues and greens in nature makes it easier for many people, myself included, to react favorably to large expanses of those colors for long periods of time. > > Will these colormaps also be used for non-imshow/colormesh/pcolormesh > data, as in for line colors as well? I think that's a great idea! It'll > make the black and white versions easier to understand since the > changing colors will monotonically increase/decrease in darkness rather > than randomly changing. I think that the line color cycling default should not match the default colormap at all; instead, it is in the "categorical" category, with visual ordering being secondary. All colors should be highly visible and distinguishable whether on a computer screen, paper, or projected by a poor projector in an overly lit room. Eric -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On 2015/02/18 2:39 PM, Nathaniel Smith wrote:
> On Feb 16, 2015 3:39 PM, "Eric Firing" wrote:
>>
>> On 2015/02/16 1:29 PM, Michael Waskom wrote:
>>
>>> Nathaniel's January 9 message in that thread (can't figure out how to
>>> link to it in the archives) had a suggestion that I thought was very
>>> promising, to do something similar to Parula but rotate around the hue
>>> circle the other direction so that the hues would go blue - purple - red
>>> - yellow. I don't think we've seen an example of exactly what it would
>>> look like, but I reckon it would be similar to the middle colormap here
>>> http://earthobservatory.nasa.gov/blogs/elegantfigures/files/2013/08/three_perceptual_palettes_618.png
>>> (from the elegant figures block series linked above), which I've always
>>> found quite attractive.
>>
>> Certainly it can be considered--but we have to have a real implementation.
>
> While I hate to promise vaporware, I actually was planning to have a
> go at implementing such a colormap in the next few weeks, based on
> optimizing the same set of parameters that viscm visualizes... FWIW.
Do you think there is a way to make a sequential map that is more
pleasing to those of us who are more comfortable with blues and greens
than with the slightly muddy purples and browns in the initial attempt
at HCL?
>
> Are we planning to make other default appearance changes at the same
> time? The idea of changing the color cycle and/or dot-dash cycle has
> already come up in this thread, and this earlier thread proposed
> several more good ideas [1]:
>
> http://thread.gmane.org/gmane.comp.python.matplotlib.devel/13128/focus=13166
My thought was to just change the color cycle, but other style aspects
are by no means out of the question. Thank you for pointing out that
thread.
>
> I agree that now is definitely the time to get serious about making
> these changes, but it seems like there's enough to be worked out that
> sticking to the original plan and keeping mainline quasi-frozen until
> 2.0 is ready might create frustration and hasty decisions. Maybe it
> would be less stressful all around if we let mainline development
> proceed at whatever pace makes sense while these things get sorted
> out, and then once the appearance changes are ready make the call
> about whether to cut a quick 1.5 first or not? Presumably these
> defaults will stick around for many years so it's worth taking a few
> months to get a complete proposal together, get feedback, etc., IMO.
The problem is that we have years of experience of no change, no
decisions, no convergence of opinion. More recently we have had general
agreement that a change is in order, but we are sadly lacking in
concrete proposals. I certainly don't want to see a bad decision made,
but without considerable prodding, it seems most likely that this will
drag on for years. We need to make a change that is good; "perfect" is
unattainable.
>
> In an ideal world version 1.last might even provide a
> style.use("matplotlib2") command to preview what 2.0 will do, just
> like 2.0 will presumably have a style.use("matplotlib1") command for
> those who want to (temporarily) revert.
This is a good idea--but even for this, we need actual style files.
Eric
>
> -n
>
> [1] well I would think that wouldn't I ;-)
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] release strategy and the color revolution
On Wed, Feb 18, 2015 at 5:23 PM, Eric Firing wrote: > > Do you think there is a way to make a sequential map that is more pleasing > to those of us who are more comfortable with blues and greens than with the > slightly muddy purples and browns in the initial attempt at HCL? Just to be clear, Hcl is just a color space; you could in principle make any number of colormaps using it. My particular proposal is to do something cubehelix-like in Hcl space while aiming for around .5-.75 of a rotation around the color wheel. What motivated the particular parameters in the original proposal was two things: a) Starting with blue and ending with yellow makes sense, because you can get good saturation out of dark blues and light yellows b) Once you have those endpoints, you can either go through green (this is what matlab does with parula) or through purple and red. the latter has the functional advantage of getting a bit more hue variation, and it also distinguishes the colormap from parula. I think this was the argument Nathaniel originally made. Tastes differ, but I find the blue-purple-red-yellow colormap quite attractive, (perhaps because it reminds me of the sunset. Actually, as an aside, your speculation that your aesthetic preferences are driven by positive associations by things that have those colors has some support in the psych literature: http://www.pnas.org/content/107/19/8877.full) Anyway, within the constraints of the "increase lightness and chroma linearly while circling around the hue wheel", it's easy to create a blue-green-yellow colormap: And also more generally, once you have a way of making a colormap from a few parameters, and some objective function for what makes a colormap "good", you can optimize in more principled ways than just playing around with the knobs of a widget. I believe this is what Nathaniel was proposing, and it sounds like a good idea. I would suggest that you folks (i.e. the matplotlib core developers) figure out earlier, rather than later, how the actual decision is going to be made. I think you can get pretty far with principled arguments, but ultimately there's going to be an aesthetic aspect and the decision will easily devolve some people thinking option A is "ugly" and other people thinking option B is "ugly". And that will be annoying for everyone involved, but particularly for the people who put time into developing candidates. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
