Menu
▾
▴
matplotlib-users — Discussion related to using matplotlib
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
| 2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
| 2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
| 2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
| 2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
| 2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
| 2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
| 2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
| 2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
| 2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
| 2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
| 2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
| 2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
| 2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(12) |
2
(15) |
3
(4) |
|
4
|
5
(1) |
6
(13) |
7
(8) |
8
(16) |
9
(10) |
10
(6) |
|
11
(11) |
12
(20) |
13
(8) |
14
(12) |
15
(10) |
16
(12) |
17
(6) |
|
18
(7) |
19
(18) |
20
(5) |
21
(9) |
22
|
23
(6) |
24
(3) |
|
25
|
26
(2) |
27
(26) |
28
(11) |
29
(9) |
30
(21) |
|
|
From: Darren D. <dd...@co...> - 2006-06-19 11:42:24
|
On Monday 19 June 2006 4:11 am, John Pye wrote: > Hi all, > > Just created a a diagram as the overlay of a pcolor plot with a labelled > contour plot. I had a few issues: > > When exporting the following image, which is a pcolor plot with alpha=0.15 > and contours on top, I get no alpha channel in the resulting output, regard > of whether I export as EPS or SVG. Is exporting with alpha channel not > supported in those formats? Alpha should be supported in svg, but there is no support for alpha in postscript. This is a problem with postscript, not mpl. Darren |
|
From: Paul B. <peb...@gm...> - 2006-06-19 11:35:13
|
On 6/19/06, John Pye <joh...@st...> wrote:
>
>
> Just created a a diagram as the overlay of a pcolor plot with a labelled
> contour plot. I had a few issues:
>
> 1. When exporting the following image, which is a pcolor plot with
> alpha=0.15 and contours on top, I get no alpha channel in the
> resulting output, regard of whether I export as EPS or SVG. Is exporting
> with alpha channel not supported in those formats?
>
>
Alpha blending is not supported in Postscript (i.e. EPS). However, SVG can
support it and it does appear to be implemented for the drawing of lines in
the SVG backend. Why it does not work, I can't say.
> 1. In the titles, which are generated using mathtext strings, I
> can't get spaces in the captions. I checked the manual. Here is an example
> of what I typed: pylab.xlabel(r"$\it{Mass flowrate, }\rm{\dot{m}
> (kg/s)}$")
>
>
You will need to escape the spaces in TeX mode, i.e. '\ '
> 1. A couple of misaligned contour labels (eg '27' in the below)
>
>
>From understanding, this issue has always been problematical. A fair amount
of time was spent on trying to get it right. The developer(s) may be able
to expand on this.
Any suggestions?
>
> This is with the latest Matplotlib 0.87.3, Python 2.4, ubuntu 6.06.
>
Nice plot!
-- Paul
|
|
From: John P. <joh...@st...> - 2006-06-19 08:11:43
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi all,<br>
<br>
Just created a a diagram as the overlay of a pcolor plot with a
labelled contour plot. I had a few issues:<br>
<ol>
<li>When exporting the following image, which is a pcolor plot with
alpha=0.15 and contours on top, I get no alpha channel in the resulting
output, regard of whether I export as EPS or SVG. Is exporting with
alpha channel not supported in those formats?<br>
</li>
<li>In the titles, which are generated using mathtext strings, I
can't get spaces in the captions. I checked the manual. Here is an
example of what I typed: pylab.xlabel(r"$\it{Mass flowrate,
}\rm{\dot{m} (kg/s)}$")<br>
</li>
<li>A couple of misaligned contour labels (eg '27' in the below)<br>
</li>
</ol>
Any suggestions?<br>
<br>
This is with the latest Matplotlib 0.87.3, Python 2.4, ubuntu 6.06.<br>
<br>
Cheers<br>
JP<br>
<img alt="sample" src="cid:par...@st..."
height="465" width="600"><br>
<br>
<pre class="moz-signature" cols="72">--
John Pye
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia
<a class="moz-txt-link-freetext" href="http://pye.dyndns.org/">http://pye.dyndns.org/</a>
</pre>
</body>
</html>
|
|
From: Vineet J. <vin...@ya...> - 2006-06-19 06:57:43
|
I have several programs that run as daemons which run with different
unix ids. each of the unix ids share the same user home dir. They are
now failing with the following error:
Traceback (most recent call last):
File "StartScanDaemon.py", line 69, in ?
main(sys.argv)
File "StartScanDaemon.py", line 61, in main
from scheduler.Scheduler import Scheduler
File "../scheduler/Scheduler.py", line 24, in ?
from peak.util.imports import lazyModule
File
"/usr/lib/python2.4/site-packages/Importing-1.9.1-py2.4.egg/peak/__init__.py",
line 1, in ?
__import__('pkg_resources').declare_namespace(__name__)
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 2212, in ?
add_activation_listener(lambda dist: dist.activate())
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 517, in subscribe
callback(dist)
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 2212, in <lambda>
add_activation_listener(lambda dist: dist.activate())
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 1843, in activate
map(declare_namespace, self._get_metadata('namespace_packages.txt'))
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 1447, in declare_namespace
declare_namespace(parent)
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 1462, in declare_namespace
_handle_ns(packageName, path_item)
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 1433, in _handle_ns
loader.load_module(packageName); module.__path__ = path
File
"/usr/lib/python2.4/site-packages/setuptools-0.6a9-py2.4.egg/pkg_resources.py",
line 1262, in load_module
mod = imp.load_module(fullname, self.file, self.filename, self.etc)
File
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/matplotlib/__init__.py",
line 999, in ?
rcParams = rc_params()
File
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/matplotlib/__init__.py",
line 956, in rc_params
fname = matplotlib_fname()
File
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/matplotlib/__init__.py",
line 902, in matplotlib_fname
fname = os.path.join(get_configdir(), 'matplotlibrc')
File
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/matplotlib/__init__.py",
line 273, in wrapper
ret = func(*args, **kwargs)
File
"/usr/lib/python2.4/site-packages/matplotlib-0.87.2-py2.4-linux-i686.egg/matplotlib/__init__.py",
line 329, in _get_configdir
os.mkdir(p)
OSError: [Errno 17] File exists: '/home/userhomedir/.matplotlib'
I tried to set the env variable:
os.environ["MATPLOTLIBRC"] = ApplicationConfig.server.serviceid
before loading maplotlib
before loading matplotlib but that does not work. Any ideas on what I'm
doing wrong?
Thanks,
Vineet
|
|
From: John H. <jdh...@ac...> - 2006-06-19 02:08:39
|
>>>>> "Ryan" == Ryan Krauss <rya...@gm...> writes:
Ryan> I just did a fresh svn checkout and my legends are no longer
Ryan> in the front. The following lines produce the attached
Ryan> plot:
Hey Ryan,
Not sure how or why this bug crept in, but apparently legend was
missing a zorder. I just added a default zorder value, which fixes
this problem. Thanks for the report.
JDH
|
|
From: Ryan K. <rya...@gm...> - 2006-06-19 01:14:44
|
I just did a fresh svn checkout and my legends are no longer in the front. The following lines produce the attached plot: t=arange(0,10,0.01) y=sin(2*pi*5.0*t) plot(t,y) legend(['data']) Ryan |
|
From: Ryan K. <rya...@gm...> - 2006-06-19 01:02:56
|
Thanks Darren. My plots look gorgeous.
Ryan
On 6/18/06, Darren Dale <dd...@co...> wrote:
> We didnt get any comments against, so I committed the changes this morning. We
> will no longer try to support sans-serif mathmode fonts with the usetex
> option, since there is no native support for them in latex. If you are using
> svn matplotlib, I suggest clearing your tex.cache after updating.
>
> Darren
>
> On Wednesday 14 June 2006 8:19 pm, Darren Dale wrote:
> > I agree that this little experiment of trying to work around latex's
> > limitations has been too much trouble. I suggest we go back to the old
> > behavior, and anyone who wants sans-serif fonts in their exponents can use
> > regular mathtext. I'm hopeful that Edin can make some strides with mpl's
> > mathtext support, and in the meantime, people should get decent results if
> > they set ps.useafm : True in their rc settings.
> >
> > Comments?
> >
> > On Wednesday 14 June 2006 19:53, Ryan Krauss wrote:
> > > (Sorry, I submitted this email with a real figure instead of a toy
> > > example and the file size was too big and it awaits moderator
> > > approval).
> > >
> > > I am afraid I asked you to open a can of worms and now I don't know
> > > what we should do. With my font size settings, \small looks to small
> > > for the exponents. I tried \normalsize and actually got decent
> > > results with \large (replacing all occurances of \small in your
> > > ticker.py). See that attached file. But if \small looked good with
> > > your settings, I am afraid things are now dependent on the font
> > > settings in the rc file as far as what should go in the latex command
> > > for the exponents.
> > >
> > > I remember that this problem came up because I complained about serif
> > > fonts in my exponents and we were having a hard time making tex use
> > > sans serif math fonts.
> > >
> > > Maybe the best solution is for me to go back in time and retract that
> > > complaint.
> > >
> > > I don't know. Sorry about the mess this had made. I have plots I am
> > > fairly happy with (I will poke around in my rc file and see if I can
> > > find out why my x and y axis fonts look different).
> > >
> > > Ryan
> > >
> > > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > > I am afraid I asked you to open a can of worms and now I don't know
> > > > what we should do. With my font size settings, \small looks to small
> > > > for the exponents. I tried \normalsize and actually got decent
> > > > results with \large (replacing all occurances of \small in your
> > > > ticker.py). See that attached file. But if \small looked good with
> > > > your settings, I am afraid things are now dependent on the font
> > > > settings in the rc file as far as what should go in the latex command
> > > > for the exponents.
> > > >
> > > > I remember that this problem came up because I complained about serif
> > > > fonts in my exponents and we were having a hard time making tex use
> > > > sans serif math fonts.
> > > >
> > > > Maybe the best solution is for me to go back in time and retract that
> > > > complaint.
> > > >
> > > > I don't know. Sorry about the mess this had made. I have plots I am
> > > > fairly happy with (I will poke around in my rc file and see if I can
> > > > find out why my x and y axis fonts look different).
> > > >
> > > > Ryan
> > > >
> > > > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > > > I feel bad that I caused this problem and am now asking you to fix
> > > > > it.
> > > > >
> > > > > Ryan
> > > > >
> > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > This is an artifact that was introduced when I tried to give you
> > > > > > support for sans-serif fonts in the exponent. Try the attached
> > > > > > ticker.py, it wraps the exponent in {\small}. Let me know if this
> > > > > > is acceptable, and I'll commit it.
> > > > > >
> > > > > > On Wednesday 14 June 2006 19:14, Ryan Krauss wrote:
> > > > > > > I still have the problem with large exponents with your
> > > > > > > matplotlibrc file (but the y-axis plots are no longer different).
> > > > > > >
> > > > > > > Any thoughts on what I should try next?
> > > > > > >
> > > > > > > Ryan
> > > > > > >
> > > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > > On Wednesday 14 June 2006 18:51, you wrote:
> > > > > > > > > There was a lot of stuff in my tex.cache, but deleting didn't
> > > > > > > > > solve my problem.
> > > > > > > > >
> > > > > > > > > I may have some strange choices for my fonts and font sizes.
> > > > > > > > > Can you send me a copy of your matplotlibrc file.
> > > > > > > > >
> > > > > > > > > Ryan
> > > > > > > > >
> > > > > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > > > > Hi Ryan,
> > > > > > > > > >
> > > > > > > > > > I'm using the latest svn as well (2479), and I cant
> > > > > > > > > > reproduce your problem. Try deleting your tex.cache.
> > > > > > > > > >
> > > > > > > > > > Darren
> > > > > > > > > >
> > > > > > > > > > On Wednesday 14 June 2006 18:14, Ryan Krauss wrote:
> > > > > > > > > > > I am having a problem with the fonts for exponents on
> > > > > > > > > > > semilog plots with usetex.
> > > > > > > > > > >
> > > > > > > > > > > The attached figure can be generated on my machine with
> > > > > > > > > > > figure(1)
> > > > > > > > > > > t=arange(0,10,0.01)
> > > > > > > > > > > y=sin(2*pi*t)
> > > > > > > > > > > semilogx(t,y)
> > > > > > > > > > >
> > > > > > > > > > > I just upgraded to the latest svn and now the y-axis
> > > > > > > > > > > plots look different from the x-axis.
> > > > > > > > > > > matplotlib.__version__
> > > > > > > > > > > Out[6]: '0.87.3'
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Ryan
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Darren S. Dale, Ph.D.
> > > > > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > > > > Cornell University
> > > > > > > > > > 200L Wilson Lab
> > > > > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > > > > Ithaca, NY 14853
> > > > > > > > > >
> > > > > > > > > > dd...@co...
> > > > > > > > > > office: (607) 255-9894
> > > > > > > > > > fax: (607) 255-9001
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > _______________________________________________
> > > > > > > > > > Matplotlib-users mailing list
> > > > > > > > > > Mat...@li...
> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-use
> > > > > > > > > >rs
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Matplotlib-users mailing list
> > > > > > > > > Mat...@li...
> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > > > > > > >
> > > > > > > > --
> > > > > > > > Darren S. Dale, Ph.D.
> > > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > > Cornell University
> > > > > > > > 200L Wilson Lab
> > > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > > Ithaca, NY 14853
> > > > > > > >
> > > > > > > > dd...@co...
> > > > > > > > office: (607) 255-9894
> > > > > > > > fax: (607) 255-9001
> > > > > >
> > > > > > --
> > > > > > Darren S. Dale, Ph.D.
> > > > > > Cornell High Energy Synchrotron Source
> > > > > > Cornell University
> > > > > > 200L Wilson Lab
> > > > > > Rt. 366 & Pine Tree Road
> > > > > > Ithaca, NY 14853
> > > > > >
> > > > > > dd...@co...
> > > > > > office: (607) 255-9894
> > > > > > fax: (607) 255-9001
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > Matplotlib-users mailing list
> > > > > > Mat...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> --
> Darren S. Dale, Ph.D.
> dd...@co...
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
|
|
From: Ryan K. <rya...@gm...> - 2006-06-19 01:02:25
|
Sorry, I didn't scroll down low enough in the message to see the png you already attached. Ryan On 6/18/06, Ryan Krauss <rya...@gm...> wrote: > Can you post a simple script that recreates your problem and a png of > a plot with the problem? (Note that your png files need to be under > 100kb or the mailing list won't allow them). > > Ryan > > On 6/18/06, Steve Schmerler <el...@gm...> wrote: > > With usetex mpl creates different fonts on the axes ticks and the > > $\times 10^<number>$ labels. > > > > > > In [1]: matplotlib.__version__ > > Out[1]: '0.87.3' > > (from svn) > > > > -- > > Random number generation is the art of producing pure gibberish as > > quickly as possible. > > > > > > > > > > _______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > > > > > > |
|
From: Ryan K. <rya...@gm...> - 2006-06-19 01:01:32
|
Can you post a simple script that recreates your problem and a png of a plot with the problem? (Note that your png files need to be under 100kb or the mailing list won't allow them). Ryan On 6/18/06, Steve Schmerler <el...@gm...> wrote: > With usetex mpl creates different fonts on the axes ticks and the > $\times 10^<number>$ labels. > > > In [1]: matplotlib.__version__ > Out[1]: '0.87.3' > (from svn) > > -- > Random number generation is the art of producing pure gibberish as > quickly as possible. > > > > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > |
|
From: Darren D. <dd...@co...> - 2006-06-18 20:27:04
|
We didnt get any comments against, so I committed the changes this morning. We
will no longer try to support sans-serif mathmode fonts with the usetex
option, since there is no native support for them in latex. If you are using
svn matplotlib, I suggest clearing your tex.cache after updating.
Darren
On Wednesday 14 June 2006 8:19 pm, Darren Dale wrote:
> I agree that this little experiment of trying to work around latex's
> limitations has been too much trouble. I suggest we go back to the old
> behavior, and anyone who wants sans-serif fonts in their exponents can use
> regular mathtext. I'm hopeful that Edin can make some strides with mpl's
> mathtext support, and in the meantime, people should get decent results if
> they set ps.useafm : True in their rc settings.
>
> Comments?
>
> On Wednesday 14 June 2006 19:53, Ryan Krauss wrote:
> > (Sorry, I submitted this email with a real figure instead of a toy
> > example and the file size was too big and it awaits moderator
> > approval).
> >
> > I am afraid I asked you to open a can of worms and now I don't know
> > what we should do. With my font size settings, \small looks to small
> > for the exponents. I tried \normalsize and actually got decent
> > results with \large (replacing all occurances of \small in your
> > ticker.py). See that attached file. But if \small looked good with
> > your settings, I am afraid things are now dependent on the font
> > settings in the rc file as far as what should go in the latex command
> > for the exponents.
> >
> > I remember that this problem came up because I complained about serif
> > fonts in my exponents and we were having a hard time making tex use
> > sans serif math fonts.
> >
> > Maybe the best solution is for me to go back in time and retract that
> > complaint.
> >
> > I don't know. Sorry about the mess this had made. I have plots I am
> > fairly happy with (I will poke around in my rc file and see if I can
> > find out why my x and y axis fonts look different).
> >
> > Ryan
> >
> > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > I am afraid I asked you to open a can of worms and now I don't know
> > > what we should do. With my font size settings, \small looks to small
> > > for the exponents. I tried \normalsize and actually got decent
> > > results with \large (replacing all occurances of \small in your
> > > ticker.py). See that attached file. But if \small looked good with
> > > your settings, I am afraid things are now dependent on the font
> > > settings in the rc file as far as what should go in the latex command
> > > for the exponents.
> > >
> > > I remember that this problem came up because I complained about serif
> > > fonts in my exponents and we were having a hard time making tex use
> > > sans serif math fonts.
> > >
> > > Maybe the best solution is for me to go back in time and retract that
> > > complaint.
> > >
> > > I don't know. Sorry about the mess this had made. I have plots I am
> > > fairly happy with (I will poke around in my rc file and see if I can
> > > find out why my x and y axis fonts look different).
> > >
> > > Ryan
> > >
> > > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > > I feel bad that I caused this problem and am now asking you to fix
> > > > it.
> > > >
> > > > Ryan
> > > >
> > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > This is an artifact that was introduced when I tried to give you
> > > > > support for sans-serif fonts in the exponent. Try the attached
> > > > > ticker.py, it wraps the exponent in {\small}. Let me know if this
> > > > > is acceptable, and I'll commit it.
> > > > >
> > > > > On Wednesday 14 June 2006 19:14, Ryan Krauss wrote:
> > > > > > I still have the problem with large exponents with your
> > > > > > matplotlibrc file (but the y-axis plots are no longer different).
> > > > > >
> > > > > > Any thoughts on what I should try next?
> > > > > >
> > > > > > Ryan
> > > > > >
> > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > On Wednesday 14 June 2006 18:51, you wrote:
> > > > > > > > There was a lot of stuff in my tex.cache, but deleting didn't
> > > > > > > > solve my problem.
> > > > > > > >
> > > > > > > > I may have some strange choices for my fonts and font sizes.
> > > > > > > > Can you send me a copy of your matplotlibrc file.
> > > > > > > >
> > > > > > > > Ryan
> > > > > > > >
> > > > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > > > Hi Ryan,
> > > > > > > > >
> > > > > > > > > I'm using the latest svn as well (2479), and I cant
> > > > > > > > > reproduce your problem. Try deleting your tex.cache.
> > > > > > > > >
> > > > > > > > > Darren
> > > > > > > > >
> > > > > > > > > On Wednesday 14 June 2006 18:14, Ryan Krauss wrote:
> > > > > > > > > > I am having a problem with the fonts for exponents on
> > > > > > > > > > semilog plots with usetex.
> > > > > > > > > >
> > > > > > > > > > The attached figure can be generated on my machine with
> > > > > > > > > > figure(1)
> > > > > > > > > > t=arange(0,10,0.01)
> > > > > > > > > > y=sin(2*pi*t)
> > > > > > > > > > semilogx(t,y)
> > > > > > > > > >
> > > > > > > > > > I just upgraded to the latest svn and now the y-axis
> > > > > > > > > > plots look different from the x-axis.
> > > > > > > > > > matplotlib.__version__
> > > > > > > > > > Out[6]: '0.87.3'
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ryan
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Darren S. Dale, Ph.D.
> > > > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > > > Cornell University
> > > > > > > > > 200L Wilson Lab
> > > > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > > > Ithaca, NY 14853
> > > > > > > > >
> > > > > > > > > dd...@co...
> > > > > > > > > office: (607) 255-9894
> > > > > > > > > fax: (607) 255-9001
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Matplotlib-users mailing list
> > > > > > > > > Mat...@li...
> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-use
> > > > > > > > >rs
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Matplotlib-users mailing list
> > > > > > > > Mat...@li...
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > > > > > >
> > > > > > > --
> > > > > > > Darren S. Dale, Ph.D.
> > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > Cornell University
> > > > > > > 200L Wilson Lab
> > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > Ithaca, NY 14853
> > > > > > >
> > > > > > > dd...@co...
> > > > > > > office: (607) 255-9894
> > > > > > > fax: (607) 255-9001
> > > > >
> > > > > --
> > > > > Darren S. Dale, Ph.D.
> > > > > Cornell High Energy Synchrotron Source
> > > > > Cornell University
> > > > > 200L Wilson Lab
> > > > > Rt. 366 & Pine Tree Road
> > > > > Ithaca, NY 14853
> > > > >
> > > > > dd...@co...
> > > > > office: (607) 255-9894
> > > > > fax: (607) 255-9001
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Matplotlib-users mailing list
> > > > > Mat...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
--
Darren S. Dale, Ph.D.
dd...@co...
|
|
From: Steve S. <el...@gm...> - 2006-06-18 17:56:34
|
With usetex mpl creates different fonts on the axes ticks and the $\times 10^<number>$ labels. In [1]: matplotlib.__version__ Out[1]: '0.87.3' (from svn) -- Random number generation is the art of producing pure gibberish as quickly as possible. |
|
From: Eric F. <ef...@ha...> - 2006-06-18 17:41:53
|
John Hunter wrote: >>>>>>"Bryan" == Bryan Cole <br...@co...> writes: > > > Bryan> MPL uses CXX instead of SWIG; I'm no C++ export so I havn't > Bryan> looked at adding __get/setstate__ functions to the objects > Bryan> themselves. copy_reg is nice because you can add > > Actually, most of the mpl extension code is CXX, but just to make > things difficult for you, some of it is SWIG as well. And some is old-fashioned C: cntr.c. And if you use basemap, then you are using a pyrex extension. Eric |
|
From: John H. <jdh...@ac...> - 2006-06-18 15:44:00
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
Eric> John Hunter wrote:
>>>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>>
Eric> they will not be transparent. If you need transparent
Eric> masked regions, then try pcolor instead of imshow. Pcolor
Eric> plots nothing at all in masked cells. Pcolormesh, on the
Eric> other hand, is like imshow in plotting the assigned bad
Eric> color and in using a single alpha for everything.
>> I'm confused about the comments about alpha not working on
>> imshow -- can you elaborate. On the agg backend at least, the
>> alpha channel is respected in imshow, eg
>> examples/layer_images.py. Is there a reason it does not (or
>> should not) work in the masked example?
Eric> John,
Eric> I don't know why it doesn't work; I know only that in my
Eric> example, it doesn't work as I perhaps naively think it
Eric> should. My interpretation of alpha is that if alpha is zero
Eric> in any colored region, and if nothing else is drawn on top,
Eric> then the background should show through; that is, the r,g,b
Eric> values in the r,g,b,a tuple for a region should have no
Eric> effect if a is zero. If you uncomment
Eric> #cmap.set_bad((1,1,1,0) in my example, you will find that
Eric> the masked region is white; and if you change the rgb part
Eric> of that tuple, it takes on that color, regardless of alpha.
I'm not sure what is going on in your example, but this test case
shows that the alpha channel is respected. I made a red RGBA array
and set the alpha channel for the center to be transparent and it
behaves as expected: you can see the line through the transparent
region of the rectangle and the axes bgcolor shows through. I had to
make a small change to svn to make this work because the image wasn't
respecting the zorder (revision 2495). So the bug you are
experiencing is likely to be in the front-end code.
from pylab import figure, show, nx
# a red rectangle with a transparent center
X = nx.ones((20,20,4), nx.Float)
X[:,:,1] = 0
X[:,:,2] = 0
X[5:15,5:15,-1] = 0
fig = figure()
ax = fig.add_subplot(111)
l, = ax.plot(nx.arange(20))
l.set_zorder(2)
im = ax.imshow(X)
im.set_zorder(3) # put the image over the line
show()
|
|
From: John H. <jdh...@ac...> - 2006-06-18 15:30:26
|
>>>>> "Bryan" == Bryan Cole <br...@co...> writes:
Bryan> MPL uses CXX instead of SWIG; I'm no C++ export so I havn't
Bryan> looked at adding __get/setstate__ functions to the objects
Bryan> themselves. copy_reg is nice because you can add
Actually, most of the mpl extension code is CXX, but just to make
things difficult for you, some of it is SWIG as well. Basically, I
decided at some point that SWIG was a better choice, and when I wanted
to expose more of the agg functionality directly through the agg
module (which is different from backend_agg), I decided to do it in
C++. The lines module, for example, uses agg to construct paths which
it then passes off to the various backends. I do not think any of
these SWIG objects are persistent since they are created at draw time
and not cached, but I just wanted to make you aware of them.
JDH
|
|
From: Bryan C. <br...@co...> - 2006-06-18 10:36:36
|
On Sun, 2006-06-18 at 15:38 +1000, John Pye wrote: > FWIW I found that I was able to pickle C++ objects but simply adding > python methods __reduce__ and __setstate__ in my SWIG .i file -- I'm not > sure if Matplotlib uses this approach or not. I didn't need to use > copy_reg (perhaps it's preferable? I don't know) MPL uses CXX instead of SWIG; I'm no C++ export so I havn't looked at adding __get/setstate__ functions to the objects themselves. copy_reg is nice because you can add pickle-ability without modifying any matplotlib code. I've hit another potential problem though: it's not possible to access the full internal state of these objects from their python API, meaning they can't be stored this way. It looks like I need to understand the Figure creation process in a bit more detail. BC > > http://freesteam.cvs.sourceforge.net/freesteam/freesteam/freesteam.i?revision=1.16&view=markup > (this is from the steam properties project that I run, > http://freesteam.sf.net/) > > Cheers > JP > > Bryan Cole wrote: > > >On Sun, 2006-06-18 at 00:05 +1000, John Pye wrote: > > > > > >>Hi all, > >> > >>A thought just occurred to me: I wonder if it would be useful to be able > >>to 'pickle' Matplotlib plots, using the python cPickle library. This > >>way, I could save my plots in a form that would allow me to load them > >>back later (with just the necessary source data) and fiddle with things > >>like titles and legends and so on. Would be useful perhaps in the > >>context of preparing diagrams for an article or report. > >> > >>Has anyone tried this? Would it be recommended/not recommended/not even > >>possible? > >> > >> > > > >I had a look at this a while back. It looks like the well thought out > >structure of MPL should make this easy, although it would require a few > >adjustments. To make a Figure object pickle-able, all the internal > >objects in a Figure must also be pickle-able. Most of the innards of a > >Figure are python objects which should pickle without problem. The only > >parts which aren't are the "BinOps". These are custom C-coded objects > >which implement 'lazy evaluation' of the transformation expressions. > >They're defined in the _transforms.cxx/h files. > > > >In theory, you can easily make these C-objects pickle-able using the > >'copy_reg' module; you just register two functions, one to extracts the > >object's state as a pickle-able object, the other to construct a new > >instance of the object, initialised with the previously stored state. > > > >However, I ran into a problem: there's some bug in either python or CXX > >(the automatic C++ class wrapper which mpl uses for the compiled > >components) which results in a segfault when I tried pickling copy_reg > >enhanced BinOps. The templating techniques used by CXX are completely > >beyond me so this is where things have stuck. > > > >... but ... I just now tested this again with python-2.4.2 and > >mpl-0.87.2 and it works! yeay. Thus, if every object in > >matplotlib._transforms gets given a python reduction/construction > >function pair and registers them with copy_reg, this *should* be enough > >to make a Figure pickle-able. Unless I've missed something else... > > > >I may try this out later this week, unless someone else tries it first. > > > >Bryan > > > >PS. copy_reg example follows >>> > > > >import cPickle as pickle > >import copy_reg > > > >#let's test this on a simple 'Value' BinOp > >from matplotlib._transforms import Value > > > >def fcon(val): > > #constructor > > return Value(val) > > > >def fred(o): > > #reduction functions > > val = o.get() > > return fcon, (val,) > > > >#my starting object > >a=Value(5) > >print a, a.get() > > > >copy_reg.pickle(type(a), fred) > > > >data = pickle.dumps(a) > > > >new = pickle.loads(data) > >print "new", new, new.get() > > > > > > > >>Cheers > >>JP > >> > >> > > > > > > > > > >_______________________________________________ > >Matplotlib-users mailing list > >Mat...@li... > >https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > > > > |
|
From: John P. <joh...@st...> - 2006-06-18 05:38:34
|
FWIW I found that I was able to pickle C++ objects but simply adding python methods __reduce__ and __setstate__ in my SWIG .i file -- I'm not sure if Matplotlib uses this approach or not. I didn't need to use copy_reg (perhaps it's preferable? I don't know) http://freesteam.cvs.sourceforge.net/freesteam/freesteam/freesteam.i?revision=1.16&view=markup (this is from the steam properties project that I run, http://freesteam.sf.net/) Cheers JP Bryan Cole wrote: >On Sun, 2006-06-18 at 00:05 +1000, John Pye wrote: > > >>Hi all, >> >>A thought just occurred to me: I wonder if it would be useful to be able >>to 'pickle' Matplotlib plots, using the python cPickle library. This >>way, I could save my plots in a form that would allow me to load them >>back later (with just the necessary source data) and fiddle with things >>like titles and legends and so on. Would be useful perhaps in the >>context of preparing diagrams for an article or report. >> >>Has anyone tried this? Would it be recommended/not recommended/not even >>possible? >> >> > >I had a look at this a while back. It looks like the well thought out >structure of MPL should make this easy, although it would require a few >adjustments. To make a Figure object pickle-able, all the internal >objects in a Figure must also be pickle-able. Most of the innards of a >Figure are python objects which should pickle without problem. The only >parts which aren't are the "BinOps". These are custom C-coded objects >which implement 'lazy evaluation' of the transformation expressions. >They're defined in the _transforms.cxx/h files. > >In theory, you can easily make these C-objects pickle-able using the >'copy_reg' module; you just register two functions, one to extracts the >object's state as a pickle-able object, the other to construct a new >instance of the object, initialised with the previously stored state. > >However, I ran into a problem: there's some bug in either python or CXX >(the automatic C++ class wrapper which mpl uses for the compiled >components) which results in a segfault when I tried pickling copy_reg >enhanced BinOps. The templating techniques used by CXX are completely >beyond me so this is where things have stuck. > >... but ... I just now tested this again with python-2.4.2 and >mpl-0.87.2 and it works! yeay. Thus, if every object in >matplotlib._transforms gets given a python reduction/construction >function pair and registers them with copy_reg, this *should* be enough >to make a Figure pickle-able. Unless I've missed something else... > >I may try this out later this week, unless someone else tries it first. > >Bryan > >PS. copy_reg example follows >>> > >import cPickle as pickle >import copy_reg > >#let's test this on a simple 'Value' BinOp >from matplotlib._transforms import Value > >def fcon(val): > #constructor > return Value(val) > >def fred(o): > #reduction functions > val = o.get() > return fcon, (val,) > >#my starting object >a=Value(5) >print a, a.get() > >copy_reg.pickle(type(a), fred) > >data = pickle.dumps(a) > >new = pickle.loads(data) >print "new", new, new.get() > > > >>Cheers >>JP >> >> > > > > >_______________________________________________ >Matplotlib-users mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > |
|
From: Bryan C. <br...@co...> - 2006-06-17 19:55:27
|
On Sun, 2006-06-18 at 00:05 +1000, John Pye wrote:
> Hi all,
>
> A thought just occurred to me: I wonder if it would be useful to be able
> to 'pickle' Matplotlib plots, using the python cPickle library. This
> way, I could save my plots in a form that would allow me to load them
> back later (with just the necessary source data) and fiddle with things
> like titles and legends and so on. Would be useful perhaps in the
> context of preparing diagrams for an article or report.
>
> Has anyone tried this? Would it be recommended/not recommended/not even
> possible?
I had a look at this a while back. It looks like the well thought out
structure of MPL should make this easy, although it would require a few
adjustments. To make a Figure object pickle-able, all the internal
objects in a Figure must also be pickle-able. Most of the innards of a
Figure are python objects which should pickle without problem. The only
parts which aren't are the "BinOps". These are custom C-coded objects
which implement 'lazy evaluation' of the transformation expressions.
They're defined in the _transforms.cxx/h files.
In theory, you can easily make these C-objects pickle-able using the
'copy_reg' module; you just register two functions, one to extracts the
object's state as a pickle-able object, the other to construct a new
instance of the object, initialised with the previously stored state.
However, I ran into a problem: there's some bug in either python or CXX
(the automatic C++ class wrapper which mpl uses for the compiled
components) which results in a segfault when I tried pickling copy_reg
enhanced BinOps. The templating techniques used by CXX are completely
beyond me so this is where things have stuck.
... but ... I just now tested this again with python-2.4.2 and
mpl-0.87.2 and it works! yeay. Thus, if every object in
matplotlib._transforms gets given a python reduction/construction
function pair and registers them with copy_reg, this *should* be enough
to make a Figure pickle-able. Unless I've missed something else...
I may try this out later this week, unless someone else tries it first.
Bryan
PS. copy_reg example follows >>>
import cPickle as pickle
import copy_reg
#let's test this on a simple 'Value' BinOp
from matplotlib._transforms import Value
def fcon(val):
#constructor
return Value(val)
def fred(o):
#reduction functions
val = o.get()
return fcon, (val,)
#my starting object
a=Value(5)
print a, a.get()
copy_reg.pickle(type(a), fred)
data = pickle.dumps(a)
new = pickle.loads(data)
print "new", new, new.get()
>
> Cheers
> JP
|
|
From: Eric F. <ef...@ha...> - 2006-06-17 18:57:09
|
John Hunter wrote: >>>>>>"Eric" == Eric Firing <ef...@ha...> writes: > > Eric> they will not be transparent. If you need transparent > Eric> masked regions, then try pcolor instead of imshow. Pcolor > Eric> plots nothing at all in masked cells. Pcolormesh, on the > Eric> other hand, is like imshow in plotting the assigned bad > Eric> color and in using a single alpha for everything. > > I'm confused about the comments about alpha not working on imshow -- > can you elaborate. On the agg backend at least, the alpha channel is > respected in imshow, eg examples/layer_images.py. Is there a reason > it does not (or should not) work in the masked example? John, I don't know why it doesn't work; I know only that in my example, it doesn't work as I perhaps naively think it should. My interpretation of alpha is that if alpha is zero in any colored region, and if nothing else is drawn on top, then the background should show through; that is, the r,g,b values in the r,g,b,a tuple for a region should have no effect if a is zero. If you uncomment #cmap.set_bad((1,1,1,0) in my example, you will find that the masked region is white; and if you change the rgb part of that tuple, it takes on that color, regardless of alpha. The Colormap.__call__() is trying to respect the individual alphas of the special colors (bad, under, over) while setting a uniform alpha for the normal colors, but somewhere along the line this is not working as intended. I ran into this when I wrote the code for the special colors, and I left a comment to that effect, but apart from taking another look just now I have not tried to track it down. The behavior is the same in imshow and in pcolormesh. I tried to work around it by setting the default bad color to white. The difference in pcolor is that it draws nothing at all in the masked region, so one sees the gray background. Eric |
|
From: Eric F. <ef...@ha...> - 2006-06-17 18:32:49
|
John,
It sounds like you are not using the latest *released* version of mpl,
which is 0.87.3; the only thing in my example that requires svn is the
colorbar command. If you did install 0.87.3, then you must have an
earlier installation still in place and being found.
imshow requires a uniform rectangular grid. pcolor is much more general
and colors rectangles specified by their boundaries, not their centers.
pcolormesh is similar (though not identical) but faster.
As you described it, your application seems most natural for imshow,
except for the problem with masked areas not being transparent. I
suggested pcolor only as a workaround for that, if you really need that
transparency.
Eric
John Pye wrote:
> Hi Eric,
>
> Thanks for your suggestion. The colorbar(shrink) command throws me an
> error, as you said it would. But I get another error with the '0.3',
> '0.5', etc. I had to replace those with (0.3,0.3,0.3) etc -- RGB tuples.
>
> Finally, my plot only shows white, grey red. I don't get any other
> colors -- do you? Is that because of the colorbar(shrink) thing, or is
> something else not working? Do I *need* your SVN changes?
>
> Also, when should I be using pcolor versus imshow? If my image is
> constructed of colors at specified sample points, is it better that I
> use pcolor? The pcolor command isn't mentioned at all in the matplotlib
> user's guide...
>
> Cheers
> JP
>
> Eric Firing wrote:
>
>
>>John,
>>
>>Something like this might be what you want:
>>
>>from pylab import *
>>import matplotlib.numerix.ma as ma
>>import matplotlib.colors as colors
>>xx = rand(10,15)
>>xxx = (xx*15 - 5).astype(Int)
>>xxx = ma.masked_where(xxx < 0, xxx)
>>xxx.set_fill_value(-1) #(not necessary)
>>cmap = colors.ListedColormap(('r', 'g', 'b',
>> 'c', 'y', 'm',
>> 'k', '0.3', '0.5',
>> '0.7'))
>>#cmap.set_bad((1,1,1,0)) # setting alpha to zero does not work, at least
>> # for imshow
>>im = imshow(xxx, interpolation='nearest',
>> cmap=cmap, norm=colors.no_norm())
>>cb = colorbar(shrink=0.6)
>>
>>
>>What we are doing here is making a custom colormap from a list of
>>colors (using any valid mpl color specification), and then indexing
>>directly into it with values from a (masked) integer array. Note the
>>use of "norm=colors.no_norm()" so that the array values are passed
>>directly to the colormap as integers.
>>
>>Caution: the colorbar command works correctly in this example only
>>with the modifications that I committed to svn a few minutes ago.
>>
>>As noted, the masked regions will have a specified color; they will
>>not be transparent. If you need transparent masked regions, then try
>>pcolor instead of imshow. Pcolor plots nothing at all in masked
>>cells. Pcolormesh, on the other hand, is like imshow in plotting the
>>assigned bad color and in using a single alpha for everything.
>>
>>Eric
>>
>>
>>John Pye wrote:
>>
>>
>>>Hi all
>>>
>>>I have some data with enumerated values in an array. Values are like
>>>1,2,7,9 spread around in the array. I want to plot those values so that
>>>I can see the 'regions' in my data, then I want to overlay this with
>>>some contour lines drawn from other data.
>>>
>>>I want to be able to specify the colors for each of the enumerated
>>>values, as they need to be consistent throughout my work. My array of
>>>enumerated values is *masked* so that there are areas where I don't want
>>>to show anything (this would plot as transparent pixels).
>>>
>>>Has anyone got suggestions on the best way of doing this? It seems that
>>>the technique in
>>>http://www.scipy.org/Cookbook/Matplotlib/Plotting_Images_with_Special_Values
>>>
>>>might be overkill, right? It also seemed that it had some problems with
>>>masked arrays.
>>>
>>>Cheers
>>>
>>>JP
>>>
>>
>>
|
|
From: John P. <joh...@st...> - 2006-06-17 14:05:50
|
Hi all, A thought just occurred to me: I wonder if it would be useful to be able to 'pickle' Matplotlib plots, using the python cPickle library. This way, I could save my plots in a form that would allow me to load them back later (with just the necessary source data) and fiddle with things like titles and legends and so on. Would be useful perhaps in the context of preparing diagrams for an article or report. Has anyone tried this? Would it be recommended/not recommended/not even possible? Cheers JP |
|
From: John P. <joh...@st...> - 2006-06-17 14:01:35
|
Hi Eric,
Thanks for your suggestion. The colorbar(shrink) command throws me an
error, as you said it would. But I get another error with the '0.3',
'0.5', etc. I had to replace those with (0.3,0.3,0.3) etc -- RGB tuples.
Finally, my plot only shows white, grey red. I don't get any other
colors -- do you? Is that because of the colorbar(shrink) thing, or is
something else not working? Do I *need* your SVN changes?
Also, when should I be using pcolor versus imshow? If my image is
constructed of colors at specified sample points, is it better that I
use pcolor? The pcolor command isn't mentioned at all in the matplotlib
user's guide...
Cheers
JP
Eric Firing wrote:
> John,
>
> Something like this might be what you want:
>
> from pylab import *
> import matplotlib.numerix.ma as ma
> import matplotlib.colors as colors
> xx = rand(10,15)
> xxx = (xx*15 - 5).astype(Int)
> xxx = ma.masked_where(xxx < 0, xxx)
> xxx.set_fill_value(-1) #(not necessary)
> cmap = colors.ListedColormap(('r', 'g', 'b',
> 'c', 'y', 'm',
> 'k', '0.3', '0.5',
> '0.7'))
> #cmap.set_bad((1,1,1,0)) # setting alpha to zero does not work, at least
> # for imshow
> im = imshow(xxx, interpolation='nearest',
> cmap=cmap, norm=colors.no_norm())
> cb = colorbar(shrink=0.6)
>
>
> What we are doing here is making a custom colormap from a list of
> colors (using any valid mpl color specification), and then indexing
> directly into it with values from a (masked) integer array. Note the
> use of "norm=colors.no_norm()" so that the array values are passed
> directly to the colormap as integers.
>
> Caution: the colorbar command works correctly in this example only
> with the modifications that I committed to svn a few minutes ago.
>
> As noted, the masked regions will have a specified color; they will
> not be transparent. If you need transparent masked regions, then try
> pcolor instead of imshow. Pcolor plots nothing at all in masked
> cells. Pcolormesh, on the other hand, is like imshow in plotting the
> assigned bad color and in using a single alpha for everything.
>
> Eric
>
>
> John Pye wrote:
>
>> Hi all
>>
>> I have some data with enumerated values in an array. Values are like
>> 1,2,7,9 spread around in the array. I want to plot those values so that
>> I can see the 'regions' in my data, then I want to overlay this with
>> some contour lines drawn from other data.
>>
>> I want to be able to specify the colors for each of the enumerated
>> values, as they need to be consistent throughout my work. My array of
>> enumerated values is *masked* so that there are areas where I don't want
>> to show anything (this would plot as transparent pixels).
>>
>> Has anyone got suggestions on the best way of doing this? It seems that
>> the technique in
>> http://www.scipy.org/Cookbook/Matplotlib/Plotting_Images_with_Special_Values
>>
>> might be overkill, right? It also seemed that it had some problems with
>> masked arrays.
>>
>> Cheers
>>
>> JP
>>
>
>
|
|
From: John H. <jdh...@ac...> - 2006-06-17 13:31:33
|
>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
Eric> they will not be transparent. If you need transparent
Eric> masked regions, then try pcolor instead of imshow. Pcolor
Eric> plots nothing at all in masked cells. Pcolormesh, on the
Eric> other hand, is like imshow in plotting the assigned bad
Eric> color and in using a single alpha for everything.
I'm confused about the comments about alpha not working on imshow --
can you elaborate. On the agg backend at least, the alpha channel is
respected in imshow, eg examples/layer_images.py. Is there a reason
it does not (or should not) work in the masked example?
JDH
|
|
From: Eric F. <ef...@ha...> - 2006-06-16 22:54:49
|
John,
Something like this might be what you want:
from pylab import *
import matplotlib.numerix.ma as ma
import matplotlib.colors as colors
xx = rand(10,15)
xxx = (xx*15 - 5).astype(Int)
xxx = ma.masked_where(xxx < 0, xxx)
xxx.set_fill_value(-1) #(not necessary)
cmap = colors.ListedColormap(('r', 'g', 'b',
'c', 'y', 'm',
'k', '0.3', '0.5',
'0.7'))
#cmap.set_bad((1,1,1,0)) # setting alpha to zero does not work, at least
# for imshow
im = imshow(xxx, interpolation='nearest',
cmap=cmap, norm=colors.no_norm())
cb = colorbar(shrink=0.6)
What we are doing here is making a custom colormap from a list of colors
(using any valid mpl color specification), and then indexing directly
into it with values from a (masked) integer array. Note the use of
"norm=colors.no_norm()" so that the array values are passed directly to
the colormap as integers.
Caution: the colorbar command works correctly in this example only with
the modifications that I committed to svn a few minutes ago.
As noted, the masked regions will have a specified color; they will not
be transparent. If you need transparent masked regions, then try pcolor
instead of imshow. Pcolor plots nothing at all in masked cells.
Pcolormesh, on the other hand, is like imshow in plotting the assigned
bad color and in using a single alpha for everything.
Eric
John Pye wrote:
> Hi all
>
> I have some data with enumerated values in an array. Values are like
> 1,2,7,9 spread around in the array. I want to plot those values so that
> I can see the 'regions' in my data, then I want to overlay this with
> some contour lines drawn from other data.
>
> I want to be able to specify the colors for each of the enumerated
> values, as they need to be consistent throughout my work. My array of
> enumerated values is *masked* so that there are areas where I don't want
> to show anything (this would plot as transparent pixels).
>
> Has anyone got suggestions on the best way of doing this? It seems that
> the technique in
> http://www.scipy.org/Cookbook/Matplotlib/Plotting_Images_with_Special_Values
> might be overkill, right? It also seemed that it had some problems with
> masked arrays.
>
> Cheers
>
> JP
>
|
|
From: Ryan K. <rya...@gm...> - 2006-06-16 16:18:02
|
It seems like no one has any comments on our plans concerning the
exponent fonts. Can you outline for me what it would take to fix
this? If it is fairly simple I may take a crack at it.
Ryan
On 6/14/06, Darren Dale <dd...@co...> wrote:
> I agree that this little experiment of trying to work around latex's
> limitations has been too much trouble. I suggest we go back to the old
> behavior, and anyone who wants sans-serif fonts in their exponents can use
> regular mathtext. I'm hopeful that Edin can make some strides with mpl's
> mathtext support, and in the meantime, people should get decent results if
> they set ps.useafm : True in their rc settings.
>
> Comments?
>
>
> On Wednesday 14 June 2006 19:53, Ryan Krauss wrote:
> > (Sorry, I submitted this email with a real figure instead of a toy
> > example and the file size was too big and it awaits moderator
> > approval).
> >
> > I am afraid I asked you to open a can of worms and now I don't know
> > what we should do. With my font size settings, \small looks to small
> > for the exponents. I tried \normalsize and actually got decent
> > results with \large (replacing all occurances of \small in your
> > ticker.py). See that attached file. But if \small looked good with
> > your settings, I am afraid things are now dependent on the font
> > settings in the rc file as far as what should go in the latex command
> > for the exponents.
> >
> > I remember that this problem came up because I complained about serif
> > fonts in my exponents and we were having a hard time making tex use
> > sans serif math fonts.
> >
> > Maybe the best solution is for me to go back in time and retract that
> > complaint.
> >
> > I don't know. Sorry about the mess this had made. I have plots I am
> > fairly happy with (I will poke around in my rc file and see if I can
> > find out why my x and y axis fonts look different).
> >
> > Ryan
> >
> > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > I am afraid I asked you to open a can of worms and now I don't know
> > > what we should do. With my font size settings, \small looks to small
> > > for the exponents. I tried \normalsize and actually got decent
> > > results with \large (replacing all occurances of \small in your
> > > ticker.py). See that attached file. But if \small looked good with
> > > your settings, I am afraid things are now dependent on the font
> > > settings in the rc file as far as what should go in the latex command
> > > for the exponents.
> > >
> > > I remember that this problem came up because I complained about serif
> > > fonts in my exponents and we were having a hard time making tex use
> > > sans serif math fonts.
> > >
> > > Maybe the best solution is for me to go back in time and retract that
> > > complaint.
> > >
> > > I don't know. Sorry about the mess this had made. I have plots I am
> > > fairly happy with (I will poke around in my rc file and see if I can
> > > find out why my x and y axis fonts look different).
> > >
> > > Ryan
> > >
> > > On 6/14/06, Ryan Krauss <rya...@gm...> wrote:
> > > > I feel bad that I caused this problem and am now asking you to fix it.
> > > >
> > > > Ryan
> > > >
> > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > This is an artifact that was introduced when I tried to give you
> > > > > support for sans-serif fonts in the exponent. Try the attached
> > > > > ticker.py, it wraps the exponent in {\small}. Let me know if this is
> > > > > acceptable, and I'll commit it.
> > > > >
> > > > > On Wednesday 14 June 2006 19:14, Ryan Krauss wrote:
> > > > > > I still have the problem with large exponents with your
> > > > > > matplotlibrc file (but the y-axis plots are no longer different).
> > > > > >
> > > > > > Any thoughts on what I should try next?
> > > > > >
> > > > > > Ryan
> > > > > >
> > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > On Wednesday 14 June 2006 18:51, you wrote:
> > > > > > > > There was a lot of stuff in my tex.cache, but deleting didn't
> > > > > > > > solve my problem.
> > > > > > > >
> > > > > > > > I may have some strange choices for my fonts and font sizes.
> > > > > > > > Can you send me a copy of your matplotlibrc file.
> > > > > > > >
> > > > > > > > Ryan
> > > > > > > >
> > > > > > > > On 6/14/06, Darren Dale <dd...@co...> wrote:
> > > > > > > > > Hi Ryan,
> > > > > > > > >
> > > > > > > > > I'm using the latest svn as well (2479), and I cant reproduce
> > > > > > > > > your problem. Try deleting your tex.cache.
> > > > > > > > >
> > > > > > > > > Darren
> > > > > > > > >
> > > > > > > > > On Wednesday 14 June 2006 18:14, Ryan Krauss wrote:
> > > > > > > > > > I am having a problem with the fonts for exponents on
> > > > > > > > > > semilog plots with usetex.
> > > > > > > > > >
> > > > > > > > > > The attached figure can be generated on my machine with
> > > > > > > > > > figure(1)
> > > > > > > > > > t=arange(0,10,0.01)
> > > > > > > > > > y=sin(2*pi*t)
> > > > > > > > > > semilogx(t,y)
> > > > > > > > > >
> > > > > > > > > > I just upgraded to the latest svn and now the y-axis plots
> > > > > > > > > > look different from the x-axis.
> > > > > > > > > > matplotlib.__version__
> > > > > > > > > > Out[6]: '0.87.3'
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Ryan
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Darren S. Dale, Ph.D.
> > > > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > > > Cornell University
> > > > > > > > > 200L Wilson Lab
> > > > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > > > Ithaca, NY 14853
> > > > > > > > >
> > > > > > > > > dd...@co...
> > > > > > > > > office: (607) 255-9894
> > > > > > > > > fax: (607) 255-9001
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > Matplotlib-users mailing list
> > > > > > > > > Mat...@li...
> > > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Matplotlib-users mailing list
> > > > > > > > Mat...@li...
> > > > > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> > > > > > >
> > > > > > > --
> > > > > > > Darren S. Dale, Ph.D.
> > > > > > > Cornell High Energy Synchrotron Source
> > > > > > > Cornell University
> > > > > > > 200L Wilson Lab
> > > > > > > Rt. 366 & Pine Tree Road
> > > > > > > Ithaca, NY 14853
> > > > > > >
> > > > > > > dd...@co...
> > > > > > > office: (607) 255-9894
> > > > > > > fax: (607) 255-9001
> > > > >
> > > > > --
> > > > > Darren S. Dale, Ph.D.
> > > > > Cornell High Energy Synchrotron Source
> > > > > Cornell University
> > > > > 200L Wilson Lab
> > > > > Rt. 366 & Pine Tree Road
> > > > > Ithaca, NY 14853
> > > > >
> > > > > dd...@co...
> > > > > office: (607) 255-9894
> > > > > fax: (607) 255-9001
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Matplotlib-users mailing list
> > > > > Mat...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> --
> Darren S. Dale, Ph.D.
> Cornell High Energy Synchrotron Source
> Cornell University
> 200L Wilson Lab
> Rt. 366 & Pine Tree Road
> Ithaca, NY 14853
>
> dd...@co...
> office: (607) 255-9894
> fax: (607) 255-9001
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
|
|
From: John H. <jdh...@ac...> - 2006-06-16 13:28:56
|
>>>>> "John" == John Pye <joh...@st...> writes:
John> I wonder if someone with write access to the scipy wiki
John> could maybe update the above page with some comments about
John> the 'mathtext' support in Matplotlib? It might also be worth
John> noting that the mathtext functionality doesn't support the
John> \frac operator.
As far as I know, anyone can get write access to the scipy wiki simply
by registering.
|
2 messages has been excluded from this view by a project administrator.
