You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
1
|
2
|
3
(27) |
4
(16) |
5
(1) |
6
(1) |
7
(4) |
8
|
9
(1) |
10
(1) |
11
(1) |
12
|
13
|
14
|
15
(6) |
16
(2) |
17
(8) |
18
|
19
|
20
|
21
|
22
(8) |
23
|
24
(2) |
25
(2) |
26
(1) |
27
(1) |
28
|
29
(1) |
30
|
|
|
|
|
From: Benjamin R. <ben...@ou...> - 2015-06-15 19:04:34
|
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 >> > > |
From: Benjamin R. <ben...@ou...> - 2015-06-15 13:51:13
|
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 > |
From: Joe K. <jof...@gm...> - 2015-06-15 13:23:51
|
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 |
From: Jack U. <jui...@ya...> - 2015-06-15 11:46:56
|
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 |
From: Benjamin R. <ben...@ou...> - 2015-06-15 11:23:46
|
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 > |
From: Daniele N. <da...@gr...> - 2015-06-15 08:49:26
|
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 |
From: Brian G. <ell...@gm...> - 2015-06-11 18:59:12
|
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... |
From: gary r. <gar...@gm...> - 2015-06-10 08:17:46
|
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 > > |
From: Thomas C. <tca...@gm...> - 2015-06-09 23:17:59
|
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 |
From: Eric F. <ef...@ha...> - 2015-06-07 22:18:05
|
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 > |
From: Nathaniel S. <nj...@po...> - 2015-06-07 22:05:41
|
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 |
From: Eric F. <ef...@ha...> - 2015-06-07 21:37:51
|
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 |
From: oren <or...@gm...> - 2015-06-07 08:39:00
|
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. |
From: Kyle M. <kyl...@co...> - 2015-06-06 15:12:42
|
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 |
From: Nathaniel S. <nj...@po...> - 2015-06-05 05:12:35
|
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 |
From: Nathaniel S. <nj...@po...> - 2015-06-04 23:30:05
|
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 |
From: Benjamin R. <ben...@ou...> - 2015-06-04 22:33:21
|
... 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 > |
From: Eric F. <ef...@ha...> - 2015-06-04 20:14:07
|
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? |
From: Alexander H. <mat...@2s...> - 2015-06-04 19:52:21
|
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 |
From: Joe K. <jof...@gm...> - 2015-06-04 18:21:41
|
> > 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. |
From: Nathaniel S. <nj...@po...> - 2015-06-04 17:32:52
|
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 |
From: Wolfram Jr., P. <pwo...@la...> - 2015-06-04 16:39:50
|
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 |
From: Brian G. <ell...@gm...> - 2015-06-04 16:37:18
|
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... |
From: Joe K. <jof...@gm...> - 2015-06-04 16:34:15
|
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 > > |
From: Joe K. <jof...@gm...> - 2015-06-04 16:28:02
|
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 |