matplotlib-devel Mailing List for matplotlib (Page 2)

I think that worked! I made a PR:
https://github.com/matplotlib/matplotlib/pull/4530
On Mon, Jun 15, 2015 at 9:50 AM, Benjamin Root <ben...@ou...> wrote:
> No, I did not try that one. I'll give it a shot. I don't do any Tkinter
> programming, so I wasn't familiar with that one.
>
> On Mon, Jun 15, 2015 at 9:23 AM, Joe Kington <jof...@gm...>
> wrote:
>
>>
>>
>> On Mon, Jun 15, 2015 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
>>
>>> That's the weird thing... I couldn't! I tried a few different things and
>>> I couldn't make it go away. I'll probably give it another shot during
>>> scipy2015.
>>>
>> I'm guessing, but did you try changing the (Tk) ``highlightthickness``?
>> E.g., something like:
>>
>> widget.config(borderwidth=0, highlightthickness=0)
>>
>> It's a moderately classic Tkinter gotcha. You remove all the borders and
>> there's still one (hightlightthickness) still there, but it only shows up
>> when you interact with the Frame.
>>
>> Hope that helps,
>> -Joe
>>
>
>

No, I did not try that one. I'll give it a shot. I don't do any Tkinter
programming, so I wasn't familiar with that one.
On Mon, Jun 15, 2015 at 9:23 AM, Joe Kington <jof...@gm...> wrote:
>
>
> On Mon, Jun 15, 2015 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
>
>> That's the weird thing... I couldn't! I tried a few different things and
>> I couldn't make it go away. I'll probably give it another shot during
>> scipy2015.
>>
> I'm guessing, but did you try changing the (Tk) ``highlightthickness``?
> E.g., something like:
>
> widget.config(borderwidth=0, highlightthickness=0)
>
> It's a moderately classic Tkinter gotcha. You remove all the borders and
> there's still one (hightlightthickness) still there, but it only shows up
> when you interact with the Frame.
>
> Hope that helps,
> -Joe
>

On Mon, Jun 15, 2015 at 6:23 AM, Benjamin Root <ben...@ou...> wrote:
> That's the weird thing... I couldn't! I tried a few different things and I
> couldn't make it go away. I'll probably give it another shot during
> scipy2015.
>
I'm guessing, but did you try changing the (Tk) ``highlightthickness``?
E.g., something like:
widget.config(borderwidth=0, highlightthickness=0)
It's a moderately classic Tkinter gotcha. You remove all the borders and
there's still one (hightlightthickness) still there, but it only shows up
when you interact with the Frame.
Hope that helps,
-Joe

Perhaps MEP27 will make that job easier, we shall see...
 From: Benjamin Root <ben...@ou...>
 To: Daniele Nicolodi <da...@gr...> 
Cc: matplotlib development list <mat...@li...> 
 Sent: Monday, 15 June 2015, 13:23
 Subject: Re: [matplotlib-devel] Tk backend different from others
 
That's the weird thing... I couldn't! I tried a few different things and I couldn't make it go away. I'll probably give it another shot during scipy2015.Ben Root
On Jun 15, 2015 4:50 AM, "Daniele Nicolodi" <da...@gr...> wrote:
Hello Ben,
On 15/11/14 17:14, Benjamin Root wrote:
> Second, while I haven't tried out all the backends yet, I noticed that
> the Figure window for tkagg has an annoying border that the other
> backends don't have. It is fairly wide, 4 pixels. I would like to get
> rid of that. Does anybody object to that? I can make a PR for that and
> any other border widths I find.
I'm trying to switch from the MacOSX backend to the the WXAgg backend
because the font handling in the first is quite a bit broken. However
the black border is very annoying. Did you manage to get rid of it?
Cheers,
Daniele
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

That's the weird thing... I couldn't! I tried a few different things and I
couldn't make it go away. I'll probably give it another shot during
scipy2015.
Ben Root
On Jun 15, 2015 4:50 AM, "Daniele Nicolodi" <da...@gr...> wrote:
> Hello Ben,
>
> On 15/11/14 17:14, Benjamin Root wrote:
> > Second, while I haven't tried out all the backends yet, I noticed that
> > the Figure window for tkagg has an annoying border that the other
> > backends don't have. It is fairly wide, 4 pixels. I would like to get
> > rid of that. Does anybody object to that? I can make a PR for that and
> > any other border widths I find.
>
> I'm trying to switch from the MacOSX backend to the the WXAgg backend
> because the font handling in the first is quite a bit broken. However
> the black border is very annoying. Did you manage to get rid of it?
>
> Cheers,
> Daniele
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello Ben,
On 15/11/14 17:14, Benjamin Root wrote:
> Second, while I haven't tried out all the backends yet, I noticed that
> the Figure window for tkagg has an annoying border that the other
> backends don't have. It is fairly wide, 4 pixels. I would like to get
> rid of that. Does anybody object to that? I can make a PR for that and
> any other border widths I find.
I'm trying to switch from the MacOSX backend to the the WXAgg backend
because the font handling in the first is quite a bit broken. However
the black border is very annoying. Did you manage to get rid of it?
Cheers,
Daniele

Great to hear this!
> - re-order feature release/style change if needed
> - can focus sprint effort at scipy on new features
> - release order may be 2.0 -> 2.1 or 1.5 -> 2.0
> - keep style change-only release plan
> - start adding color maps as named maps on master
> - color map
> - D seems to be leader, maybe variation on theme
> - stefan is working on circular color maps
> - other style changes
> - adopt most of seaborn as defaults ?
I think it would be good to have a set of core stylesheets in mpl that include
* Slight modifications of the existing mpl theme (outward ticks?,
different default cmap and color cycle)
* The default seaborn style that closely follows that of ggplot2
* Stylesheets that mimic the "contexts" of seaborn
I would also like to see a few more style helper methods such as
despine, ticks_out/in, etc.
> - start putting in style sheets as soon as possible
> - may not be worth big drawn out decision, just change them
> - line color cycle
> - need to do something, maybe related to circular color maps
> - use something from seaborn
> - get time for style BoF at scipy
I would love to participate in any mpl BoFs at SciPy. Also, I have a
student working for me this summer and one of his focus areas will be
visualization. I can likely have him work on some of the
stylesheet+traitlets+nbagg stuff as part of this work. He will also be
at SciPy.
Cheers,
Brian
>
> Any feed back is welcome.
>
> Tom
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgr...@ca... and ell...@gm...

It's good to hear Stefan is working on circular colormaps as the hsv
colormap is way too saturated, ignoring any perceptual aspects. For this,
it might be possible to provide some sort of saturation parameter in a
function along the lines of the parameters in the cubehelix function? Also,
sympy/mpmath's cplot function allows you to modulate the
nominally-perceptually-flat hsv map with a value-related function, which
they take as the absolute value of the function, but ideally it would be
any function or array that could ideally be passed in as a parameter. I
have plotted images like this in the past, where I was plotting the phase
of a complex number field but only wanted to use the envelope of the
overall function to control the saturation so you could see the structure
near the singularities but the brightness would fall off in the outer parts
of the image.
Gary R
On 10 June 2015 at 09:17, Thomas Caswell <tca...@gm...> wrote:
> Hey all,
>
> Today we had a phone call with myself, Eric Firing, Micheal
> Droettboom, Stéfan van der Walt, and Nathaniel Smith to discuss the path
> forward for the changes to the default color map / style. The notes are
> below:
>
> - re-order feature release/style change if needed
> - can focus sprint effort at scipy on new features
> - release order may be 2.0 -> 2.1 or 1.5 -> 2.0
> - keep style change-only release plan
> - start adding color maps as named maps on master
> - color map
> - D seems to be leader, maybe variation on theme
> - stefan is working on circular color maps
> - other style changes
> - adopt most of seaborn as defaults ?
> - start putting in style sheets as soon as possible
> - may not be worth big drawn out decision, just change them
> - line color cycle
> - need to do something, maybe related to circular color maps
> - use something from seaborn
> - get time for style BoF at scipy
>
> Any feed back is welcome.
>
> Tom
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Hey all,
Today we had a phone call with myself, Eric Firing, Micheal
Droettboom, Stéfan van der Walt, and Nathaniel Smith to discuss the path
forward for the changes to the default color map / style. The notes are
below:
 - re-order feature release/style change if needed
 - can focus sprint effort at scipy on new features
 - release order may be 2.0 -> 2.1 or 1.5 -> 2.0
 - keep style change-only release plan
 - start adding color maps as named maps on master
 - color map
 - D seems to be leader, maybe variation on theme
 - stefan is working on circular color maps
 - other style changes
 - adopt most of seaborn as defaults ?
 - start putting in style sheets as soon as possible
 - may not be worth big drawn out decision, just change them
 - line color cycle
 - need to do something, maybe related to circular color maps
 - use something from seaborn
 - get time for style BoF at scipy
Any feed back is welcome.
Tom

On 2015年06月07日 12:05 PM, Nathaniel Smith wrote:
> On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing <ef...@ha...> wrote:
>> Matplotlib's pyplot retains quite a few vestiges from its original
>> Matlab-workalike heritage; we would like to gradually eliminate those
>> that no longer make sense. One such candidate is the "hold" kwarg that
>> every pyplot function has, with a "True" default. I don't think it
>> serves any useful purpose now, and getting rid of it would allow
>> considerable simplification to the code and, to a lesser extent, the
>> documentation. The default behavior would not change, only the ability
>> to change that behavior via either the rcParams['axes.hold'] parameter
>> or the "hold" kwarg in a pyplot function call.
>>
>> If you routinely use 'hold=False' and believe that removing it would be
>> a mistake, please let us know.
>
> I do actually use it with some regularity interactively, though I'm
> not particularly attached to it. Is there some equivalent though, like
> plt.whatever(..., hold=False)
> can become
> plt.clear(); plt.whatever(...)
It's exactly equivalent to:
	plt.cla(); plt.whatever(...)
> ? The semantics would be that the current figure remains the current
> figure, but is reset so that the next operation starts from scratch. I
> notice that plt.clear() does not exist, but maybe it has another
> spelling :-).
There are two types of "clear":
	plt.clf() # clear the current Figure
	plt.cla() # clear the current Axes
Eric
>
> (Basically the use case here is getting something like the
> edit-and-rerun-a-cell workflow, but when using a classic interactive
> REPL rather than the ipython notebook -- so I have a specific plot
> window up on my screen at a size and place where I can see it, and
> maybe some other plots in other windows in the background somewhere,
> and I want to quickly display different things into that window.)
>
> -n
>

On Sun, Jun 7, 2015 at 2:37 PM, Eric Firing <ef...@ha...> wrote:
> Matplotlib's pyplot retains quite a few vestiges from its original
> Matlab-workalike heritage; we would like to gradually eliminate those
> that no longer make sense. One such candidate is the "hold" kwarg that
> every pyplot function has, with a "True" default. I don't think it
> serves any useful purpose now, and getting rid of it would allow
> considerable simplification to the code and, to a lesser extent, the
> documentation. The default behavior would not change, only the ability
> to change that behavior via either the rcParams['axes.hold'] parameter
> or the "hold" kwarg in a pyplot function call.
>
> If you routinely use 'hold=False' and believe that removing it would be
> a mistake, please let us know.
I do actually use it with some regularity interactively, though I'm
not particularly attached to it. Is there some equivalent though, like
 plt.whatever(..., hold=False)
can become
 plt.clear(); plt.whatever(...)
? The semantics would be that the current figure remains the current
figure, but is reset so that the next operation starts from scratch. I
notice that plt.clear() does not exist, but maybe it has another
spelling :-).
(Basically the use case here is getting something like the
edit-and-rerun-a-cell workflow, but when using a classic interactive
REPL rather than the ipython notebook -- so I have a specific plot
window up on my screen at a size and place where I can see it, and
maybe some other plots in other windows in the background somewhere,
and I want to quickly display different things into that window.)
-n
-- 
Nathaniel J. Smith -- http://vorpus.org

Matplotlib's pyplot retains quite a few vestiges from its original 
Matlab-workalike heritage; we would like to gradually eliminate those 
that no longer make sense. One such candidate is the "hold" kwarg that 
every pyplot function has, with a "True" default. I don't think it 
serves any useful purpose now, and getting rid of it would allow 
considerable simplification to the code and, to a lesser extent, the 
documentation. The default behavior would not change, only the ability 
to change that behavior via either the rcParams['axes.hold'] parameter 
or the "hold" kwarg in a pyplot function call.
If you routinely use 'hold=False' and believe that removing it would be 
a mistake, please let us know.
Thanks.
Eric

Is there any news about this thing?
anyone know of a working matplotlib on arm chips?
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/Matplotlib-on-Android-tp44304p45739.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Members of the matplotlib community,
As one of the co-chairs in charge of organizing the birds-of-a-feather sessions at SciPy this year I wanted to reach out to your community to encourage you to submit a BoF proposal to open up a discussion on topics related to matplotlib development, future or just general questions. Please let us know if there is anything we can help with in terms of organization.
Kyle Mandli and Matt McCormick

On Thu, Jun 4, 2015 at 12:42 AM, Nathan Goldbaum <nat...@gm...> wrote:
>
> On Wed, Jun 3, 2015 at 5:17 PM, Stéfan van der Walt <st...@su...>
> wrote:
>>
>> On Wed, Jun 3, 2015 at 5:08 PM, Nathan Goldbaum <nat...@gm...>
>> wrote:
>> > I'm a big fan of option D. So much so that when I needed to make a
>> > movie of
>> > ony my galaxy simulations today I went ahead and used it:
>> >
>> > https://youtu.be/bnm554et0T8
>>
>> Beautiful! How hard would it be to also do this for the other
>> proposed colormaps?
>
>
> Thankfully you made it pretty easy to script this.
>
> jet: https://www.youtube.com/watch?v=dsvT5hImPmo
>
> parula: https://www.youtube.com/watch?v=8146CMi-OaQ
>
> option a: https://www.youtube.com/watch?v=IqvxuQSzWO4
>
> option b: https://www.youtube.com/watch?v=wa7bpV3XPV0
>
> option c: https://www.youtube.com/watch?v=3rHbq4jw1ew
>
> option d: https://www.youtube.com/watch?v=2_HiUXVNm2k
Awesome! Added these to the webpage.
For extra fun (90 mb download, but worth it):
http://vorpus.org/~njs/goldbaum-galaxies-all-colormaps.mkv
-- 
Nathaniel J. Smith -- http://vorpus.org

On Thu, Jun 4, 2015 at 3:32 PM, Benjamin Root <ben...@ou...> wrote:
> As for option D, my only apprehension for it is on the blue (purple?) end of
> the scale. I can't really perceive any changes on that end and it just seems
> like a solid color to me. Does it seem that way to anybody else? Maybe shift
> the curve a bit to start a little more into the greens and have more
> yellow/orange?
This is useful feedback, but FWIW it looks fine here... so my first
guess is that this is due to variation between individual monitors.
While the Fancy Color Math we're using is definitely not perfect, it
does represent basically everything anyone knows about how color
works. The biggest limitation is that at the end of the day we have to
write down the colormap using RGB values, and you can send the exact
same RGB values to two different monitors and get different colors. So
the only thing we can do is to target sRGB, which has two virtues:
it's designed to be an inexact but reasonable approximation to what
most hardware does if you use it in a naive way; and, it's also what's
expected by more sophisticated setups -- like OSes and applications
that are color-management-aware, and ideally have access to calibrated
models of specific monitors / printers / whatever.
Over time this will hopefully improve as software and hardware are
upgraded, and more workflows will become "sophisticated". But until
then there's not much to do besides target sRGB and cross our fingers.
Unless anyone has access to some data on how popular consumer hardware
systematically deviates from sRGB... designing the perfect colormap
for "the monitor sitting on Benjamin Root's desk with its current
software drivers" may or may not help for anyone else :-).
Lacking real data like this, the best we can hope for is to try and
avoid any colormap that lots of people report causing specific
problems on the hardware they have access to (which is why I was
asking about projectors in particular upthread).
TL;DR: please do report such issues, but IMO these reports are only
really useful if lots of people report the same thing, or if it causes
many people to prefer one colormap to another; unfortunately it's not
very useful for tweaking small details.
-n
-- 
Nathaniel J. Smith -- http://vorpus.org

... unless you have red-green colorblindness. I abhor using laser pointers
during talks and instead use descriptive text such as "upper-left" or "in
the middle". Also helps when only the slides and the audio is being
recorded.
As for option D, my only apprehension for it is on the blue (purple?) end
of the scale. I can't really perceive any changes on that end and it just
seems like a solid color to me. Does it seem that way to anybody else?
Maybe shift the curve a bit to start a little more into the greens and have
more yellow/orange?
As for branding, while it isn't the same as Matlab's Parula, it does look
similar. That may or may not be a concern.
Ben Root
On Thu, Jun 4, 2015 at 4:13 PM, Eric Firing <ef...@ha...> wrote:
> On 2015年06月04日 9:52 AM, Alexander Heger wrote:
> > When used in talks, you can see the green laser pointer
> > better on top of C.
>
> And perhaps a red laser pointer better on top of D?
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On 2015年06月04日 9:52 AM, Alexander Heger wrote:
> When used in talks, you can see the green laser pointer
> better on top of C.
And perhaps a red laser pointer better on top of D?

I think the very dark tones in Options A and B would make it harder to
add annotations on top, so C and D are better for that. Between C and
D I find that C looks slightly more "energetic", D is too rather calm
though nice. When used in talks, you can see the green laser pointer
better on top of C.
-Alexander
On 3 June 2015 at 11:46, Nathaniel Smith <nj...@po...> wrote:
> Hi all,
>
> As was hinted at in a previous thread, Stéfan van der Walt and I have
> been using some Fancy Color Technology to attempt to design a new
> colormap intended to become matplotlib's new default. (Down with jet!)
>
> Unfortunately, while our Fancy Color Technology includes a
> computational model of perceptual distance, it does not include a
> computational model of aesthetics. So this is where you come in.
>
> We've put up three reasonable candidates at:
> https://bids.github.io/colormap/
> (along with some well-known colormaps for comparison), and we'd like
> your feedback.
>
> They are all optimal on all of the objective criteria we know how to
> measure. What we need judgements on is which one you like best, both
> aesthetically and as a way of visualizing data. (There are some sample
> plots to look at there, plus you can download them and play with them
> on your own data if you want.)
>
> We especially value input from anyone with anomalous color vision.
> There are some simulations there, but computational models are
> inherently limited here. (It's difficult to ask someone with
> colorblindness "does this look to you, the same way this other picture
> looks to me?")
>
> -n
>
> --
> Nathaniel J. Smith -- http://vorpus.org
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

>
> I'm not sure what I'm looking at in that picture exactly, or how to
> distinguish a good result from a poor one -- could you elaborate?
>
It an nutshell, it's whether shading can be distinguished from value
changes.
> FYI I should also note that we're planning on additionally providing
> isoluminant (or approximately isoluminant) variants for whatever colormaps
> we end up contributing, exactly for cases where you want to preserve the
> lightness channel for shading effects. So in any case you'll have a choice
> between "mapA" and "mapA-isoluminant", etc.
>
> -n
>
It's essentially isoluminance, but also the absolute value of the
luninance. (Ideally, you'd want a more-or-less isoluminant colormap with an
average luminance near 0.5.)
A colormap with all dark colors or all light colors can be isoluminant, but
is largely useless for this application, as it will be difficult to
distinguish shaded slopes from low areas or highlighted slopes from high
areas.
Also, from a purely subjective level for this example, it's how effectively
the shading tricks your brain into seeing a topographic surface. The
colormap has a good bit of influence on this, but I have no idea how to
quantify it.
At any rate, including an isoluminant version solves a large amount of the
problem. Thanks!
Also, to illustrate the exact issue I was referring to a touch more
clearly, here's a zoomed-in version of the previous example:
P.S. Sorry, Nathaniel, you're going to get this twice. I didn't look
closely enough when I hit reply. I seem to be rather bad at the whole
"e-mail" thing today.

On Jun 4, 2015 9:28 AM, "Joe Kington" <jof...@gm...> wrote:
>
> One other (admittedly very minor) consideration is how the colormaps look
with shading applied. To borrow from the hillshading example:
>
> (The image appears to be too large to attatch. Try here:
http://www.geology.beer/images/hillshaded.png)
>
> I personally really like option D for a lot of reasons, but this is
another reason to prefer it. Providing additional information through
"shading" etc, still works quite well. Option C also does well in this
particular test, though it appears too "washed out" for my tastes.
I'm not sure what I'm looking at in that picture exactly, or how to
distinguish a good result from a poor one -- could you elaborate?
FYI I should also note that we're planning on additionally providing
isoluminant (or approximately isoluminant) variants for whatever colormaps
we end up contributing, exactly for cases where you want to preserve the
lightness channel for shading effects. So in any case you'll have a choice
between "mapA" and "mapA-isoluminant", etc.
-n

Same here. I prefer D over the rest because of both its aesthetic and technical merits.
Phil
--------------------------------------------------
Phillip J. Wolfram, Ph.D.
Postdoctoral Research Associate
Climate, Ocean and Sea Ice Modeling
T-3 Fluid Dynamics and Structural Mechanics
Los Alamos National Laboratory
Phone: (505) 667-3518
Email: pwo...@la...
On Jun 4, 2015, at 10:37 AM, <mat...@li...> <mat...@li...> wrote:
> Message: 1
> Date: Thu, 4 Jun 2015 09:37:12 -0700
> From: Brian Granger <ell...@gm...>
> Subject: Re: [matplotlib-devel] RFC: candidates for a new default
> 	colormap
> To: Joe Kington <jof...@gm...>
> Cc: matplotlib-devel <mat...@li...>
> Message-ID:
> 	<CAH4pYpRms3xbu=m==Jdi7=XJA...@ma...>
> Content-Type: text/plain; charset="utf-8"
> 
> I very much like D.
> 
> On Thu, Jun 4, 2015 at 9:34 AM, Joe Kington <jof...@gm...> wrote:
> 
>> Well that got horribly garbled somehow (and I hit send too early). Let me
>> try that again:
>> 
>> 
>> ?
>> 
>> 
>> On Thu, Jun 4, 2015 at 11:27 AM, Joe Kington <jof...@gm...>
>> wrote:
>> 
>>> One other (admittedly very minor) consideration is how the colormaps look
>>> with shading applied. To borrow from the hillshading example
>>> <http://matplotlib.org/devdocs/examples/specialty_plots/topographic_hillshading.html>
>>> :
>>> 
>>> (The image appears to be too large to attatch. Try here: http://
>>> <http://www.geology.beer/images/hillshaded.png>www.geology.beer
>>> <http://www.geology.beer/images/hillshaded.png>/images/
>>> <http://www.geology.beer/images/hillshaded.png>hillshaded.png
>>> <http://www.geology.beer/images/hillshaded.png>)
>>> <http://www.geology.beer/images/hillshaded.png>
>>> 
>>> I personally really like option D for a lot of reasons, but this is
>>> another reason to prefer it. Providing additional information through
>>> "shading" etc, still works quite well. Option C also does well in this
>>> particular test, though it appears too "washed out" for my tastes.
>>> 
>>> At least to my eyes, options B fairs particularly poorly. In B's case,
>>> the fact that the colormap runs towards black means that hillshading is
>>> difficult to distinguish from elevation changes. A suffers from similar
>>> problems in this case, though they're much less severe.
>>> 
>>> In my personal opinion: D >> A > C > B
>>> 
>>> Cheers,
>>> -Joe
>>> Fun activity: watch all 6 videos in a row then watch the text on this
>>> email spin and spin. =P
>>> 
>>> Gorgeous! Thanks Nathan!
>>> 
>>> I hope this kills C dead. It clearly makes certain features of the
>>> simulation harder to spot.
>>> 
>>> A great demo of the terribleness of jet, too: it looks like a huge mess.
>>> 
>>> On Thu, Jun 4, 2015 at 5:42 PM, Nathan Goldbaum <nat...@gm...>
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> On Wed, Jun 3, 2015 at 5:17 PM, St?fan van der Walt <st...@su...>
>>>> wrote:
>>>> 
>>>>> On Wed, Jun 3, 2015 at 5:08 PM, Nathan Goldbaum <nat...@gm...>
>>>>> wrote:
>>>>>> I'm a big fan of option D. So much so that when I needed to make a
>>>>> movie of
>>>>>> ony my galaxy simulations today I went ahead and used it:
>>>>>> 
>>>>>> https://youtu.be/bnm554et0T8
>>>>> 
>>>>> Beautiful! How hard would it be to also do this for the other
>>>>> proposed colormaps?
>>>>> 
>>>> 
>>>> Thankfully you made it pretty easy to script this.
>>>> 
>>>> jet: https://www.youtube.com/watch?v=dsvT5hImPmo
>>>> 
>>>> parula: https://www.youtube.com/watch?v=8146CMi-OaQ
>>>> 
>>>> option a: https://www.youtube.com/watch?v=IqvxuQSzWO4
>>>> 
>>>> option b: https://www.youtube.com/watch?v=wa7bpV3XPV0
>>>> 
>>>> option c: https://www.youtube.com/watch?v=3rHbq4jw1ew
>>>> 
>>>> option d: https://www.youtube.com/watch?v=2_HiUXVNm2k
>>>> 
>>>> 
>>>>> 
>>>>> St?fan
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> 
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>> 
>>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> 
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> 
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> 
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> 
> 
> 
> -- 
> Brian E. Granger
> Cal Poly State University, San Luis Obispo
> @ellisonbg on Twitter and GitHub
> bgr...@ca... and ell...@gm...
> -------------- next part --------------
> An HTML attachment was scrubbed...
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: hillshaded.png
> Type: image/png
> Size: 1056284 bytes
> Desc: not available

I very much like D.
On Thu, Jun 4, 2015 at 9:34 AM, Joe Kington <jof...@gm...> wrote:
> Well that got horribly garbled somehow (and I hit send too early). Let me
> try that again:
>
>
> ​
>
>
> On Thu, Jun 4, 2015 at 11:27 AM, Joe Kington <jof...@gm...>
> wrote:
>
>> One other (admittedly very minor) consideration is how the colormaps look
>> with shading applied. To borrow from the hillshading example
>> <http://matplotlib.org/devdocs/examples/specialty_plots/topographic_hillshading.html>
>> :
>>
>> (The image appears to be too large to attatch. Try here: http://
>> <http://www.geology.beer/images/hillshaded.png>www.geology.beer
>> <http://www.geology.beer/images/hillshaded.png>/images/
>> <http://www.geology.beer/images/hillshaded.png>hillshaded.png
>> <http://www.geology.beer/images/hillshaded.png>)
>> <http://www.geology.beer/images/hillshaded.png>
>>
>> I personally really like option D for a lot of reasons, but this is
>> another reason to prefer it. Providing additional information through
>> "shading" etc, still works quite well. Option C also does well in this
>> particular test, though it appears too "washed out" for my tastes.
>>
>> At least to my eyes, options B fairs particularly poorly. In B's case,
>> the fact that the colormap runs towards black means that hillshading is
>> difficult to distinguish from elevation changes. A suffers from similar
>> problems in this case, though they're much less severe.
>>
>> In my personal opinion: D >> A > C > B
>>
>> Cheers,
>> -Joe
>> Fun activity: watch all 6 videos in a row then watch the text on this
>> email spin and spin. =P
>>
>> Gorgeous! Thanks Nathan!
>>
>> I hope this kills C dead. It clearly makes certain features of the
>> simulation harder to spot.
>>
>> A great demo of the terribleness of jet, too: it looks like a huge mess.
>>
>> On Thu, Jun 4, 2015 at 5:42 PM, Nathan Goldbaum <nat...@gm...>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 3, 2015 at 5:17 PM, Stéfan van der Walt <st...@su...>
>>> wrote:
>>>
>>>> On Wed, Jun 3, 2015 at 5:08 PM, Nathan Goldbaum <nat...@gm...>
>>>> wrote:
>>>> > I'm a big fan of option D. So much so that when I needed to make a
>>>> movie of
>>>> > ony my galaxy simulations today I went ahead and used it:
>>>> >
>>>> > https://youtu.be/bnm554et0T8
>>>>
>>>> Beautiful! How hard would it be to also do this for the other
>>>> proposed colormaps?
>>>>
>>>
>>> Thankfully you made it pretty easy to script this.
>>>
>>> jet: https://www.youtube.com/watch?v=dsvT5hImPmo
>>>
>>> parula: https://www.youtube.com/watch?v=8146CMi-OaQ
>>>
>>> option a: https://www.youtube.com/watch?v=IqvxuQSzWO4
>>>
>>> option b: https://www.youtube.com/watch?v=wa7bpV3XPV0
>>>
>>> option c: https://www.youtube.com/watch?v=3rHbq4jw1ew
>>>
>>> option d: https://www.youtube.com/watch?v=2_HiUXVNm2k
>>>
>>>
>>>>
>>>> Stéfan
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgr...@ca... and ell...@gm...

Well that got horribly garbled somehow (and I hit send too early). Let me
try that again:
​
On Thu, Jun 4, 2015 at 11:27 AM, Joe Kington <jof...@gm...> wrote:
> One other (admittedly very minor) consideration is how the colormaps look
> with shading applied. To borrow from the hillshading example
> <http://matplotlib.org/devdocs/examples/specialty_plots/topographic_hillshading.html>
> :
>
> (The image appears to be too large to attatch. Try here: http://
> <http://www.geology.beer/images/hillshaded.png>www.geology.beer
> <http://www.geology.beer/images/hillshaded.png>/images/
> <http://www.geology.beer/images/hillshaded.png>hillshaded.png
> <http://www.geology.beer/images/hillshaded.png>)
> <http://www.geology.beer/images/hillshaded.png>
>
> I personally really like option D for a lot of reasons, but this is
> another reason to prefer it. Providing additional information through
> "shading" etc, still works quite well. Option C also does well in this
> particular test, though it appears too "washed out" for my tastes.
>
> At least to my eyes, options B fairs particularly poorly. In B's case,
> the fact that the colormap runs towards black means that hillshading is
> difficult to distinguish from elevation changes. A suffers from similar
> problems in this case, though they're much less severe.
>
> In my personal opinion: D >> A > C > B
>
> Cheers,
> -Joe
> Fun activity: watch all 6 videos in a row then watch the text on this
> email spin and spin. =P
>
> Gorgeous! Thanks Nathan!
>
> I hope this kills C dead. It clearly makes certain features of the
> simulation harder to spot.
>
> A great demo of the terribleness of jet, too: it looks like a huge mess.
>
> On Thu, Jun 4, 2015 at 5:42 PM, Nathan Goldbaum <nat...@gm...>
> wrote:
>
>>
>>
>> On Wed, Jun 3, 2015 at 5:17 PM, Stéfan van der Walt <st...@su...>
>> wrote:
>>
>>> On Wed, Jun 3, 2015 at 5:08 PM, Nathan Goldbaum <nat...@gm...>
>>> wrote:
>>> > I'm a big fan of option D. So much so that when I needed to make a
>>> movie of
>>> > ony my galaxy simulations today I went ahead and used it:
>>> >
>>> > https://youtu.be/bnm554et0T8
>>>
>>> Beautiful! How hard would it be to also do this for the other
>>> proposed colormaps?
>>>
>>
>> Thankfully you made it pretty easy to script this.
>>
>> jet: https://www.youtube.com/watch?v=dsvT5hImPmo
>>
>> parula: https://www.youtube.com/watch?v=8146CMi-OaQ
>>
>> option a: https://www.youtube.com/watch?v=IqvxuQSzWO4
>>
>> option b: https://www.youtube.com/watch?v=wa7bpV3XPV0
>>
>> option c: https://www.youtube.com/watch?v=3rHbq4jw1ew
>>
>> option d: https://www.youtube.com/watch?v=2_HiUXVNm2k
>>
>>
>>>
>>> Stéfan
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

One other (admittedly very minor) consideration is how the colormaps look
with shading applied. To borrow from the hillshading example
<http://matplotlib.org/devdocs/examples/specialty_plots/topographic_hillshading.html>
:
(The image appears to be too large to attatch. Try here: http://
<http://www.geology.beer/images/hillshaded.png>www.geology.beer
<http://www.geology.beer/images/hillshaded.png>/images/
<http://www.geology.beer/images/hillshaded.png>hillshaded.png
<http://www.geology.beer/images/hillshaded.png>)
<http://www.geology.beer/images/hillshaded.png>
I personally really like option D for a lot of reasons, but this is another
reason to prefer it. Providing additional information through "shading"
etc, still works quite well. Option C also does well in this particular
test, though it appears too "washed out" for my tastes.
At least to my eyes, options B fairs particularly poorly. In B's case, the
fact that the colormap runs towards black means that hillshading is
difficult to distinguish from elevation changes. A suffers from similar
problems in this case, though they're much less severe.
In my personal opinion: D >> A > C > B
Cheers,
-Joe
Fun activity: watch all 6 videos in a row then watch the text on this email
spin and spin. =P
Gorgeous! Thanks Nathan!
I hope this kills C dead. It clearly makes certain features of the
simulation harder to spot.
A great demo of the terribleness of jet, too: it looks like a huge mess.
On Thu, Jun 4, 2015 at 5:42 PM, Nathan Goldbaum <nat...@gm...>
wrote:
>
>
> On Wed, Jun 3, 2015 at 5:17 PM, Stéfan van der Walt <st...@su...>
> wrote:
>
>> On Wed, Jun 3, 2015 at 5:08 PM, Nathan Goldbaum <nat...@gm...>
>> wrote:
>> > I'm a big fan of option D. So much so that when I needed to make a
>> movie of
>> > ony my galaxy simulations today I went ahead and used it:
>> >
>> > https://youtu.be/bnm554et0T8
>>
>> Beautiful! How hard would it be to also do this for the other
>> proposed colormaps?
>>
>
> Thankfully you made it pretty easy to script this.
>
> jet: https://www.youtube.com/watch?v=dsvT5hImPmo
>
> parula: https://www.youtube.com/watch?v=8146CMi-OaQ
>
> option a: https://www.youtube.com/watch?v=IqvxuQSzWO4
>
> option b: https://www.youtube.com/watch?v=wa7bpV3XPV0
>
> option c: https://www.youtube.com/watch?v=3rHbq4jw1ew
>
> option d: https://www.youtube.com/watch?v=2_HiUXVNm2k
>
>
>>
>> Stéfan
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
------------------------------------------------------------------------------
_______________________________________________
Matplotlib-devel mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel