matplotlib-devel Mailing List for matplotlib

Didn't Numpy have a student, too?
On Tue, Oct 28, 2014 at 9:46 PM, Thomas Caswell <tca...@gm...> wrote:
> We should ask the scikit-image devs how they managed it last summer as I
> think they had at least one student.
>
> On Wed Oct 22 2014 at 3:33:11 PM Chris Barker <chr...@no...>
> wrote:
>
>> On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell <tca...@gm...>
>> wrote:
>>
>>> We should be a mentoring organization for next summer.
>>>
>>
>> well, maybe. A few years ago Google shifted to preferring fewer, larger,
>> mentoring organizations. So python projects have tended to be handled under
>> the PSF-sponsored organization.
>>
>> Or we could go half-way, and have a numfocus one..
>>
>>
>>> we need to have a list of viable projects for a
>>>
>> summer student. I suspect that these will have to have a balance
>>> between importance (to justify doing it) and shiny-ness (to get
>>> students to _want_ to do it).
>>>
>>
>> It's a good idea to develop this list regardless of the sponsoring
>> organization structure.
>>
>> -Chris
>> --
>>
>> Christopher Barker, Ph.D.
>> Oceanographer
>>
>> Emergency Response Division
>> NOAA/NOS/OR&R (206) 526-6959 voice
>> 7600 Sand Point Way NE (206) 526-6329 fax
>> Seattle, WA 98115 (206) 526-6317 main reception
>>
>> Chr...@no...
>> ------------------------------------------------------------
>> ------------------
>> _______________________________________________
>> 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
>
>

On 2014年10月28日, 10:30 PM, Pierre Haessig wrote:
> Le 21/10/2014 10:09, Eric Firing a écrit :
>> That's the big question: what is the IP status?
> So Nathaniel and I asked, and the blog post author, Steve Eddins, took
> the time to answer :
>
> Nathaniel and Pierre—Thanks for your interest in the new parula
> colormap. /Parula is the end result of a creative design effort over
> an extended period of time. I am pleased that you find it so
> appealing. The colormap is, however, MathWorks intellectual
> property, and it would not be appropriate or acceptable to copy or
> re-use it in non-MathWorks plotting tools./
>
> You might look at other sources of high-quality colormaps. I have
> listed some in my technical paper on rainbow colormaps, published
> earlier this month on mathworks.com.
>
>
> http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/#comment-27702
>
> So they claim the IP. Next question is: is this claim valid, and I'm not
> a lawyer to answer it. I suspect that the answer could be country specific.
Regardless, we should respect their claim. I agree with the basic idea: 
it was the result of a creative process, and they choose to keep that as 
proprietary IP. Therefore mpl will not include a clone of this color 
map. If a user decides to make and use a clone, that's their business, 
not ours. We shouldn't encourage it.
>
> The only things that bother me in this IP claim, is the status of all
> the plots produced with this colormap. They are in a sense a
> /derivative/ work, am I right ? So the question becomes : does Mathworks
> owns IP right for all these plots ?!
Perhaps they could claim copyright infringement; but from the mpl 
perspective, I don't think it matters. The question will only arise in 
practice if a user makes a plot with a clone of parula, and Mathworks 
chooses to turn it into a legal issue. I think it is unlikely this will 
happen; but if and when it does, I don't think mpl will be involved. We 
will not be supplying the colormap or in any way encouraging or 
condoning its use in mpl, unless and until Mathworks releases it.
Eric
>
> Pierre
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Le 21/10/2014 10:09, Eric Firing a écrit :
> That's the big question: what is the IP status?
So Nathaniel and I asked, and the blog post author, Steve Eddins, took 
the time to answer :
 Nathaniel and Pierre—Thanks for your interest in the new parula
 colormap. /Parula is the end result of a creative design effort over
 an extended period of time. I am pleased that you find it so
 appealing. The colormap is, however, MathWorks intellectual
 property, and it would not be appropriate or acceptable to copy or
 re-use it in non-MathWorks plotting tools./
 You might look at other sources of high-quality colormaps. I have
 listed some in my technical paper on rainbow colormaps, published
 earlier this month on mathworks.com.
http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/#comment-27702
So they claim the IP. Next question is: is this claim valid, and I'm not 
a lawyer to answer it. I suspect that the answer could be country specific.
The only things that bother me in this IP claim, is the status of all 
the plots produced with this colormap. They are in a sense a 
/derivative/ work, am I right ? So the question becomes : does Mathworks 
owns IP right for all these plots ?!
Pierre

We should ask the scikit-image devs how they managed it last summer as I
think they had at least one student.
On Wed Oct 22 2014 at 3:33:11 PM Chris Barker <chr...@no...> wrote:
> On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell <tca...@gm...>
> wrote:
>
>> We should be a mentoring organization for next summer.
>>
>
> well, maybe. A few years ago Google shifted to preferring fewer, larger,
> mentoring organizations. So python projects have tended to be handled under
> the PSF-sponsored organization.
>
> Or we could go half-way, and have a numfocus one..
>
>
>> we need to have a list of viable projects for a
>>
> summer student. I suspect that these will have to have a balance
>> between importance (to justify doing it) and shiny-ness (to get
>> students to _want_ to do it).
>>
>
> It's a good idea to develop this list regardless of the sponsoring
> organization structure.
>
> -Chris
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi folks,
a colleague from NCAR in Boulder just sent me this link about a conference
they are organizing in the spring:
https://sea.ucar.edu/conference/2015
I figured this might be of interest to many on these lists. The actual
call isn't up yet, so if you're interested, watch that site for an upcoming
call when they post it (I'm not directly involved, just passing the message
along).
Cheers
f
-- 
Fernando Perez (@fperez_org; http://fperez.org)
fperez.net-at-gmail: mailing lists only (I ignore this when swamped!)
fernando.perez-at-berkeley: contact me here for any direct mail

Yeah, put together a PR, and we can evaluate it better that way. I think
the current plot directive behavior might need this sort of tightening up
On Sun, Oct 26, 2014 at 1:22 AM, Matthew Brett <mat...@gm...>
wrote:
> Sorry - I accidentally sent this reply just to Nathaniel - returning
> to this as it bit me again:
>
> On 7/14/14, Nathaniel Smith <nj...@po...> wrote:
> > Wouldn't a better default be to just close all figures when they're
> > displayed? It can't be common that someone wants to show the same plot
> > repeatedly (and if they do that could have an option)...?
>
> Yes, I think that would be a better default.
>
> You mean that if :context: is true, then always do something like
> ``plt.close('all')`` before running the relevant code and looking for
> figures.
>
> It would change the current behavior, but I agree that would be better.
>
> Anyone disagree?
>
> If not, I will make a pull request to change the behavior...
>
> Cheers,
>
> Matthew
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Thomas Caswell <tca...@gm...> writes:
> The user mailing list is still a going concern, the SF archives are just
> broken. They know (and the archive pages are _less_ broken than they used
> to be), but have not fixed it yet.
How about linking to the gmane.org archives?
http://news.gmane.org/gmane.comp.python.matplotlib.general
http://news.gmane.org/gmane.comp.python.matplotlib.devel
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Thanks Thomas, that's great to know. I'll try using a newer version from
Github, and nice that the correction will gradually propagate to our users.
I'll ask my other questions on the user list; thanks for explaining!
Andy
On 26/10/14 16:18, Thomas Caswell wrote:
> Andy,
> 
> The issue of the axes frame corners _should_ be fixed in 1.4
> 
> The user mailing list is still a going concern, the SF archives are just
> broken. They know (and the archive pages are _less_ broken than they
> used to be), but have not fixed it yet.
> 
> Tom
> 
> On Sun, Oct 26, 2014 at 11:50 AM, Andy Buckley <an...@in...
> <mailto:an...@in...>> wrote:
> 
> Hi all,
> 
> I have a question/request about improving a minor aspect of plot
> cosmetics, namely that axis spines seem to be rendered as 4 individual
> lines, meaning that the corners of the axes boundary do not match up
> with a neat corner but have a "stair" appearance. I've attached a
> screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
> from Ubuntu 14.04... so apologies if it's already fixed in the latest
> 1.4.x versions. This effect is also visible in PNG output, as just a
> couple of pixels in the corners that look "ragged". Would it be possible
> to tidy this up... or point me to where in the code this rendering is
> done, if it's something easy that I could maybe help with?
> 
> At the same time, I note in this zoom that the axis is showing tick
> marks at the very end(s) of the axis, where they overlap with the other
> axis/plot boundary line: is there an automatic way to elide tick marks
> in that redundant position?
> 
> Apologies if this isn't a good place for these queries/requests -- I had
> a look at the matplotlib-user and -announce list archives linked from
> the web page and they seem to have gone defunct in 2012, hence coming
> here. I am happy to do a bit of development to address little cosmetic
> tweaks like this, but am not yet familiar with MPL internals.
> 
> Thanks!
> Andy
> 
> PS. I also have a question about how to enable old-style figures in a
> font when using the TeX/PGF rendering backed, cf.
> \usepackage[osf]{mathpazo}, but I'll wait to see if this is an
> appropriate place for such questions before troubling you with that!
> 
> --
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
> 
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> 
> 
> -- 
> Thomas Caswell
> tca...@gm... <mailto:tca...@gm...>
-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN

On 2014年10月26日, 4:52 AM, Thomas Caswell wrote:
> https://github.com/HamsterHuey/easyplot?utm_content=buffer48700&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
>
> I have not looked at it carefully, but it is something we might want to
> be aware of when thinking about API re-designs.
Yes, this is well worth keeping in mind. It looks like there are some 
very good ideas here.
Eric
>
> Tom
>
> --
> Thomas Caswell
> tca...@gm... <mailto:tca...@gm...>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Andy,
The issue of the axes frame corners _should_ be fixed in 1.4
The user mailing list is still a going concern, the SF archives are just
broken. They know (and the archive pages are _less_ broken than they used
to be), but have not fixed it yet.
Tom
On Sun, Oct 26, 2014 at 11:50 AM, Andy Buckley <an...@in...>
wrote:
> Hi all,
>
> I have a question/request about improving a minor aspect of plot
> cosmetics, namely that axis spines seem to be rendered as 4 individual
> lines, meaning that the corners of the axes boundary do not match up
> with a neat corner but have a "stair" appearance. I've attached a
> screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
> from Ubuntu 14.04... so apologies if it's already fixed in the latest
> 1.4.x versions. This effect is also visible in PNG output, as just a
> couple of pixels in the corners that look "ragged". Would it be possible
> to tidy this up... or point me to where in the code this rendering is
> done, if it's something easy that I could maybe help with?
>
> At the same time, I note in this zoom that the axis is showing tick
> marks at the very end(s) of the axis, where they overlap with the other
> axis/plot boundary line: is there an automatic way to elide tick marks
> in that redundant position?
>
> Apologies if this isn't a good place for these queries/requests -- I had
> a look at the matplotlib-user and -announce list archives linked from
> the web page and they seem to have gone defunct in 2012, hence coming
> here. I am happy to do a bit of development to address little cosmetic
> tweaks like this, but am not yet familiar with MPL internals.
>
> Thanks!
> Andy
>
> PS. I also have a question about how to enable old-style figures in a
> font when using the TeX/PGF rendering backed, cf.
> \usepackage[osf]{mathpazo}, but I'll wait to see if this is an
> appropriate place for such questions before troubling you with that!
>
> --
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Thomas Caswell
tca...@gm...

Hi all,
I have a question/request about improving a minor aspect of plot
cosmetics, namely that axis spines seem to be rendered as 4 individual
lines, meaning that the corners of the axes boundary do not match up
with a neat corner but have a "stair" appearance. I've attached a
screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
from Ubuntu 14.04... so apologies if it's already fixed in the latest
1.4.x versions. This effect is also visible in PNG output, as just a
couple of pixels in the corners that look "ragged". Would it be possible
to tidy this up... or point me to where in the code this rendering is
done, if it's something easy that I could maybe help with?
At the same time, I note in this zoom that the axis is showing tick
marks at the very end(s) of the axis, where they overlap with the other
axis/plot boundary line: is there an automatic way to elide tick marks
in that redundant position?
Apologies if this isn't a good place for these queries/requests -- I had
a look at the matplotlib-user and -announce list archives linked from
the web page and they seem to have gone defunct in 2012, hence coming
here. I am happy to do a bit of development to address little cosmetic
tweaks like this, but am not yet familiar with MPL internals.
Thanks!
Andy
PS. I also have a question about how to enable old-style figures in a
font when using the TeX/PGF rendering backed, cf.
\usepackage[osf]{mathpazo}, but I'll wait to see if this is an
appropriate place for such questions before troubling you with that!
-- 
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN

https://github.com/HamsterHuey/easyplot?utm_content=buffer48700&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
I have not looked at it carefully, but it is something we might want to be
aware of when thinking about API re-designs.
Tom
-- 
Thomas Caswell
tca...@gm...

Sorry - I accidentally sent this reply just to Nathaniel - returning
to this as it bit me again:
On 7/14/14, Nathaniel Smith <nj...@po...> wrote:
> Wouldn't a better default be to just close all figures when they're
> displayed? It can't be common that someone wants to show the same plot
> repeatedly (and if they do that could have an option)...?
Yes, I think that would be a better default.
You mean that if :context: is true, then always do something like
``plt.close('all')`` before running the relevant code and looking for
figures.
It would change the current behavior, but I agree that would be better.
Anyone disagree?
If not, I will make a pull request to change the behavior...
Cheers,
Matthew

Hot on the tails of v1.4.1, we have a v1.4.2 due to an error in the boxplot
api in pyplot.py
The only changes between 1.4.1 and 1.4.2 are:
 - corrected boxplot in pyplot.py
 - added extra paths to default search paths for freetype
Tom
-- 
Thomas Caswell
tca...@gm...

Yes, pyplot didn't get regenerated after one of the boxplot fixes.
On Thu, Oct 23, 2014 at 9:17 AM, Sandro Tosi <mo...@de...> wrote:
> I see a 1.4.2 already?
>
> On Sun, Oct 19, 2014 at 3:54 AM, Thomas Caswell <tca...@gm...> wrote:
>> Hello,
>>
>> We are pleased to announce the release of matplotlib 1.4.1.
>>
>> This is a bug-fix release for the 1.4 series.
>>
>> - reverts the changes to interactive plotting so ion will work as
>> before in all cases fixed boxplot regressions
>> - fixes for finding freetype and libpng
>> - sundry unicode fixes (looking up user folders, importing
>> seaborn/pandas/networkx with macosx backend)
>> - nbagg works with python 3 + new font awesome
>> - fixed saving dialogue in QT5
>>
>> Source tarballs are available on sourceforge, github, and pypi. In
>> addition wheels for both mac and windows are available on both pypi
>> and source forge and windows executable installers are available on
>> source forge.
>>
>> http://matplotlib.org/downloads.html
>>
>> https://pypi.python.org/pypi/matplotlib/1.4.1
>>
>> The matplotlib dev team
>>
>> ------------------------------------------------------------------------------
>> Comprehensive Server Monitoring with Site24x7.
>> Monitor 10 servers for 9ドル/Month.
>> Get alerted through email, SMS, voice calls or mobile push notifications.
>> Take corrective actions from your mobile device.
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> --
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

I see a 1.4.2 already?
On Sun, Oct 19, 2014 at 3:54 AM, Thomas Caswell <tca...@gm...> wrote:
> Hello,
>
> We are pleased to announce the release of matplotlib 1.4.1.
>
> This is a bug-fix release for the 1.4 series.
>
> - reverts the changes to interactive plotting so ion will work as
> before in all cases fixed boxplot regressions
> - fixes for finding freetype and libpng
> - sundry unicode fixes (looking up user folders, importing
> seaborn/pandas/networkx with macosx backend)
> - nbagg works with python 3 + new font awesome
> - fixed saving dialogue in QT5
>
> Source tarballs are available on sourceforge, github, and pypi. In
> addition wheels for both mac and windows are available on both pypi
> and source forge and windows executable installers are available on
> source forge.
>
> http://matplotlib.org/downloads.html
>
> https://pypi.python.org/pypi/matplotlib/1.4.1
>
> The matplotlib dev team
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for 9ドル/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell <tca...@gm...> wrote:
> We should be a mentoring organization for next summer.
>
well, maybe. A few years ago Google shifted to preferring fewer, larger,
mentoring organizations. So python projects have tended to be handled under
the PSF-sponsored organization.
Or we could go half-way, and have a numfocus one..
> we need to have a list of viable projects for a
>
summer student. I suspect that these will have to have a balance
> between importance (to justify doing it) and shiny-ness (to get
> students to _want_ to do it).
>
It's a good idea to develop this list regardless of the sponsoring
organization structure.
 -Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Tue, Oct 21, 2014 at 8:09 PM, Eric Firing <ef...@ha...> wrote:
> On 2014年10月21日, 6:27 AM, Nathaniel Smith wrote:
>> On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig
>> <pie...@cr...> wrote:
>>> Hi,
>>>
>>> Matlab is now shipping with a new default colormap, named "parula"
>>> [1,2]. It is meant to overcome the many issues of the current default
>>> "jet". It seems that the RGB values of this new colormap are already
>>> onnline [3].
>>>
>>> So my question is:
>>> * is it worth adding this parula in the Matplotlib colormap collection ?
>>> (I think it is)
>>> * is there any copyright issue with that ? (I have no idea how
>>> copyrightable a list of numbers is !)
>>
>> The general rule is that copyright requires "creative expression".
>> This is a pretty marginal case at best, since that the colormap
>> appears to have been derived by solving an optimization problem, but
>> worst case we could always re-solve that optimization problem
>> ourselves. (I've played before with using CAM02-UCS to automatically
>> generate perceptually uniform colormaps - it's not terribly difficult
>> to do.)
>>
> There are additional considerations, such as working well for the most
> common form of color-blindness, providing as much resolution as
> possible, and being aesthetically pleasing to most people.
Sure, but the first two of those are just extra constraints on the optimization.
Apparently they'll be making another blog post soon describing the
actual constraints they used.
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

On 2014年10月21日, 6:27 AM, Nathaniel Smith wrote:
> On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig
> <pie...@cr...> wrote:
>> Hi,
>>
>> Matlab is now shipping with a new default colormap, named "parula"
>> [1,2]. It is meant to overcome the many issues of the current default
>> "jet". It seems that the RGB values of this new colormap are already
>> onnline [3].
>>
>> So my question is:
>> * is it worth adding this parula in the Matplotlib colormap collection ?
>> (I think it is)
>> * is there any copyright issue with that ? (I have no idea how
>> copyrightable a list of numbers is !)
>
> The general rule is that copyright requires "creative expression".
> This is a pretty marginal case at best, since that the colormap
> appears to have been derived by solving an optimization problem, but
> worst case we could always re-solve that optimization problem
> ourselves. (I've played before with using CAM02-UCS to automatically
> generate perceptually uniform colormaps - it's not terribly difficult
> to do.)
>
> -n
>
There are additional considerations, such as working well for the most 
common form of color-blindness, providing as much resolution as 
possible, and being aesthetically pleasing to most people.
Eric

On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig
<pie...@cr...> wrote:
> Hi,
>
> Matlab is now shipping with a new default colormap, named "parula"
> [1,2]. It is meant to overcome the many issues of the current default
> "jet". It seems that the RGB values of this new colormap are already
> onnline [3].
>
> So my question is:
> * is it worth adding this parula in the Matplotlib colormap collection ?
> (I think it is)
> * is there any copyright issue with that ? (I have no idea how
> copyrightable a list of numbers is !)
The general rule is that copyright requires "creative expression".
This is a pretty marginal case at best, since that the colormap
appears to have been derived by solving an optimization problem, but
worst case we could always re-solve that optimization problem
ourselves. (I've played before with using CAM02-UCS to automatically
generate perceptually uniform colormaps - it's not terribly difficult
to do.)
-n
-- 
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org

On 2014年10月20日, 9:50 PM, Pierre Haessig wrote:
> Hi,
>
> Matlab is now shipping with a new default colormap, named "parula"
> [1,2]. It is meant to overcome the many issues of the current default
> "jet". It seems that the RGB values of this new colormap are already
> onnline [3].
>
> So my question is:
> * is it worth adding this parula in the Matplotlib colormap collection ?
> (I think it is)
Yes, *if* the answer to your next question allows it.
> * is there any copyright issue with that ? (I have no idea how
> copyrightable a list of numbers is !)
That's the big question: what is the IP status?
Eric
>
> (I'm not speeking of changing the *default* colormap since this is
> already discussed here https://github.com/matplotlib/matplotlib/issues/875)
>
> best,
> Pierre
>
> 1
> http://blogs.mathworks.com/steve/2014/10/13/a-new-colormap-for-matlab-part-1-introduction/
> 2
> http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/
> 3
> http://www.mathworks.com/matlabcentral/answers/158575-values-fo-colormap-parula
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for 9ドル/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
Matlab is now shipping with a new default colormap, named "parula" 
[1,2]. It is meant to overcome the many issues of the current default 
"jet". It seems that the RGB values of this new colormap are already 
onnline [3].
So my question is:
* is it worth adding this parula in the Matplotlib colormap collection ? 
(I think it is)
* is there any copyright issue with that ? (I have no idea how 
copyrightable a list of numbers is !)
(I'm not speeking of changing the *default* colormap since this is 
already discussed here https://github.com/matplotlib/matplotlib/issues/875)
best,
Pierre
1 
http://blogs.mathworks.com/steve/2014/10/13/a-new-colormap-for-matlab-part-1-introduction/
2 
http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/
3 
http://www.mathworks.com/matlabcentral/answers/158575-values-fo-colormap-parula

Sigh, I think that might have been set up by John.
Ben Root
On Fri, Oct 17, 2014 at 11:36 PM, Thomas Caswell <tca...@gm...> wrote:
> Does anyone on the list know the pass word (or control the recovery
> email address) for the matplotlib gmail account? I would like to set
> up google analytics on our web site to see a) how much traffic we get
> and b) where people are going.
>
> Tom
>
> --
> Thomas Caswell
> tca...@gm...
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for 9ドル/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
I'm working on https://github.com/matplotlib/matplotlib/pull/3393 and 
poking around at _alpha, _forced_alpha, _rgb, and _orig_color members of 
GraphicsContextBase. I see quite a number of issues:
1) "_rgb" is (almost) always a 4 tuple which may be better named "_rgba".
2) "_orig_color" takes on many different value types -- I think it can 
be deleted and the "_rgb" variable used in the one place it is needed.
3) "get_rgb" documents that it returns a 3 or 4 tuple. In fact, I 
think it returns a 4-tuple (see point 1). backend_ps.py is a 
particularly scary example of the 3 tuple interpretation being taken 
with-out further thought.
4) I suppose there is a good reason for the existence of 
"_forced_alpha" and "_alpha", but I don't understand it. Since "_rgb" 
is a 4-tuple in common (all?) usage, why can't "set_alpha" merely set 
"_rgb[3]"?
I'm going to be pushing something more to my branch at 
https://github.com/matplotlib/matplotlib/pull/3393 -- deleting 
"_orig_color" and renaming "_rgb" to "_rgba". But even with these 
changes, the points above give me pause.
(I'm also sitting on irc right now asking these same questions).
Joel

Hello,
We are pleased to announce the release of matplotlib 1.4.1.
This is a bug-fix release for the 1.4 series.
 - reverts the changes to interactive plotting so ion will work as
before in all cases fixed boxplot regressions
 - fixes for finding freetype and libpng
 - sundry unicode fixes (looking up user folders, importing
seaborn/pandas/networkx with macosx backend)
 - nbagg works with python 3 + new font awesome
 - fixed saving dialogue in QT5
Source tarballs are available on sourceforge, github, and pypi. In
addition wheels for both mac and windows are available on both pypi
and source forge and windows executable installers are available on
source forge.
http://matplotlib.org/downloads.html
https://pypi.python.org/pypi/matplotlib/1.4.1
The matplotlib dev team