matplotlib-devel Mailing List for matplotlib (Page 4)

(sorry for botched subject line in the first message)
Basemap 0.9.7 is available for download.
http://www.python.org/pypi/basemap/0.9.7
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=142792&release_id=555980 <http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=142792&release_id=555980>
Windows installers for python 2.4 and python 2.5 are available.
There are many under-the-hood changes in the this release, but the API and
functionality are nearly identical to 0.9.6.
There is an extra dependency on the GEOS (Geometry Engine) library
(http://geos.refractions.net). The source code is included with basemap,
but requires a separate ./configure; make ;make install step before running
setup.py. Using the GEOS library speeds up the creation of Basemap class
instances dramatically, especially for small map regions using high resolution
boundaries. 
The high-resolution boundaries from Generic Mapping Tools are now included, 
and the full-resolution boundaries are available as a separate 67mb download.
Full Changelog:
version 0.9.7 (svn revision 4422)
 * fixed bug in drawlsmask for 'moll','robin' and 'sinu'
 projections.
 * added lake_color keyword to fillcontinents.
 * fixed a bug in the 'tmerc' projection.
 * added pure python NetCDFFile reader from Roberto De Almeida 
 to basemap namespace
 (from matplotlib.toolkits.basemap import NetCDFFile).
 * added support for full-resolution boundaries (will be
 a separate download). Full-res files (totaling around
 100 mb) available in SVN.
 * high-resolution boundaries now included.
 * postpone processing of countries, states and river
 boundaries until a draw is requested. Only the
 coastlines are processed in __init__.
 * use a Pyrex/Cython interface to the GEOS library
 (http://geos.refractions.net - LGPL license)
 to find geometries that are within map projection region.
 This speeds up instance creation for small map regions and
 high resolution coastlines. Boundary datasets now in binary
 format (I/O is faster). Requires GEOS version 2.2.3, source
 code included.
 * remove all numerix imports.
 * fix rotate_vector so it works in S. Hem and for non-orthogonal
 grids. Support for masked velocity vectors also added. (EF)
 * numpification. (EF)
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Basemap 0.9.7 is available for download.
http://www.python.org/pypi/basemap/0.9.7
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=142792&release_id=555980 <http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=142792&release_id=555980>
Windows installers for python 2.4 and python 2.5 are available.
There are many under-the-hood changes in the this release, but the API and
functionality are nearly identical to 0.9.6.
There is an extra dependency on the GEOS (Geometry Engine) library
(http://geos.refractions.net). The source code is included with basemap,
but requires a separate ./configure; make ;make install step before running
setup.py. Using the GEOS library speeds up the creation of Basemap class
instances dramatically, especially for small map regions using high resolution
boundaries. 
The high-resolution boundaries from Generic Mapping Tools are now included, 
and the full-resolution boundaries are available as a separate 67mb download.
Full Changelog:
version 0.9.7 (svn revision 4422)
 * fixed bug in drawlsmask for 'moll','robin' and 'sinu'
 projections.
 * added lake_color keyword to fillcontinents.
 * fixed a bug in the 'tmerc' projection.
 * added pure python NetCDFFile reader from Roberto De Almeida 
 to basemap namespace
 (from matplotlib.toolkits.basemap import NetCDFFile).
 * added support for full-resolution boundaries (will be
 a separate download). Full-res files (totaling around
 100 mb) available in SVN.
 * high-resolution boundaries now included.
 * postpone processing of countries, states and river
 boundaries until a draw is requested. Only the
 coastlines are processed in __init__.
 * use a Pyrex/Cython interface to the GEOS library
 (http://geos.refractions.net - LGPL license)
 to find geometries that are within map projection region.
 This speeds up instance creation for small map regions and
 high resolution coastlines. Boundary datasets now in binary
 format (I/O is faster). Requires GEOS version 2.2.3, source
 code included.
 * remove all numerix imports.
 * fix rotate_vector so it works in S. Hem and for non-orthogonal
 grids. Support for masked velocity vectors also added. (EF)
 * numpification. (EF)
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I just want to a dynamic plot with a line show in a plot.
The line changes every second when it gets the different
data(xdata(),ydata()) from list[i].
list[1]=([1,2],[3,5]) list[2]=([1,2],[3,5],[5,4])
list[3]=([1,2],[3,5],[5,4],[7,6])
list[4]=([1,2],[3,5],[5,4],[7,6],[9,7])......
for example, when list[1] in set for the data of the line, I will get a line
with two point (1,2)(3,5). After a second,list[2] is auto setted for the
data of the line, and I will get a line with three point. With the different
list[i] setted for the line, the line changed.
I just tried it again and again, but failed.
Can somebody help me? And just give a short code to do it.
Thank you.
-- 
View this message in context: http://www.nabble.com/pylib-dynamic-plot.-tf4859796.html#a13907020
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Andrew Straw wrote:
> Eric Firing wrote:
>> Yes, I understand, and I am sorry--but I hope it is one-time pain to 
>> avoid continuing pin-pricks. If svn ignored trailing whitespace, then 
>> there would be no problem; I could continue to use an editor that 
>> removes it, and you could continue to use editors that gratuitously add 
>> it, and usually it would make no difference. This is not the case, 
>> however. As it is now, if a file comes into svn without any trailing 
>> whitespace, and one of you loads it up, maybe makes a trivial change 
>> after running your cursor through it, and saves it--it will end up with 
>> a big changeset--lots of trailing whitespace. This is just plain bad. 
>> All downside, no upside.
>> 
> FWIW, you can get svn diff to ignore (trailing whitespace) -- by not
> using svn diff.
> 
> svn diff --diff-cmd diff -x -uw path/to/file.py
Almost. Quotes are needed for the diff options:
svn diff -x '-uw' path/to/file.py
This is useful, but doesn't help with the problem of noise in changesets.
> 
> With apologies for previously hijacking your thread into an emacs
> configure-a-thon, :)
No problem--everyone but me uses emacs or vi, it seems, so figuring out 
how to configure emacs is what it takes to address the problem.
Eric

Ludwig Schwardt wrote:
> Possible solutions:
> 
> - Use colors that are safe for printing and displaying (less saturated colors?).
Avoid the extreme (255,0,0), (0,255,0), (0,0,255) colors, yes. For reasons which
are fairly obvious given the physics, RGB devices do better displaying those
than CMYK devices. Blues are especially poorly represented in CMYK media.
OS X users can play around with these things using the ColorSync Utility.app
program. Click on the "Profiles" button. On the left, there is a tree of
profiles. Select "Generic RGB Profile". On the 3D plot, click the triangle in
the upper left-hand corner and select "Hold for comparison". Now click the
"Generic CMYK Profile". This shows a CMYK color gamut and an RGB color gamut in
Lab space. The intersection of these two is the "safe region" where the colors
on your screen can be represented in print. Of course, that is only if the
printer driver knows about both profiles.
> - Use Lab color, which is absolute. This is cumbersome, and RGB is
> much more commonplace and well-understood in plotting packages,
> including Matlab.
Yeah, that's probably not too practical.
> - Associate a generic ICC profile with the mpl plot, to attach
> absolute color values to the RGB values in the plot in a consistent
> way. Maybe this is the default in many graphics file formats and
> therefore redundant, or maybe it does make a difference specifying it
> explicitly, I'm not sure.
It might be reasonable to specify that matplotlib uses the W3C standard sRGB
colorspace. It was meant to be good for representability on a wide variety of
computer monitors. Some monitors may even be manufactured to match that
standard. It is the default colorspace for SVG and PNG. It misses a fair chunk
of most the usual CMYK space in the greens and cyans, though. Adobe RGB (1998)
would be better for print, but that "wastes" a lot of space on greens that most
monitors can't represent. Some journals require figures in Adobe RGB (1998).
Really implementing this still requires one to apply calibrated ICC profiles of
your viewing device and potential output devices, but it does standardize the
files matplotlib outputs.
I have some code that wraps the lcms library for applying ICC profiles to numpy
arrays. Those who saw my lightning talk at SciPy '07 saw an app I had for
showing colormaps in perceptual colorspaces like Lab and with transformations to
simulate colorblindness. I'm snowed under work next week, but after that I'll
try to clean it up for doing soft-proofs of images. Maybe I'll even get to
integrating that soft-proofing with matplotlib such that every interactive plot
can be displayed as if it were printed (or seen through my colorblind eyes).
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Eric Firing wrote:
> Yes, I understand, and I am sorry--but I hope it is one-time pain to 
> avoid continuing pin-pricks. If svn ignored trailing whitespace, then 
> there would be no problem; I could continue to use an editor that 
> removes it, and you could continue to use editors that gratuitously add 
> it, and usually it would make no difference. This is not the case, 
> however. As it is now, if a file comes into svn without any trailing 
> whitespace, and one of you loads it up, maybe makes a trivial change 
> after running your cursor through it, and saves it--it will end up with 
> a big changeset--lots of trailing whitespace. This is just plain bad. 
> All downside, no upside.
> 
FWIW, you can get svn diff to ignore (trailing whitespace) -- by not
using svn diff.
svn diff --diff-cmd diff -x -uw path/to/file.py
With apologies for previously hijacking your thread into an emacs
configure-a-thon, :)
Andrew

[oops, meant on-list ]
On Nov 21, 2007 12:52 PM, Andrew Straw <str...@as...> wrote:
> Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
> Looks like I'll now have to find a way to do the one thing in emacs that
> keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
I recently switched to the 'pretty emacs' from
http://peadrop.com/blog/2007/09/17/pretty-emacs-reloaded/
so I could get decent fonts in emacs. I had to tweak my config a bit,
and for M-g I put this by hand in my config file:
(global-set-key "\M-g" 'goto-line) ; standard XEmacs
I can send you my configs which allow me to start this emacs (with
"emacs-snapshot-gtk --enable-font-backend") or plain xemacs in a
reasonably functional state for both.
Cheers,
f

Thanks, that works, but unforunately only on emacs21 but not xemacs 21.
Looks like I'll now have to find a way to do the one thing in emacs that
keeps me using xemacs: goto-line bound to M-g. (Any quick tips appreciated.)
-Andrew
John Hunter wrote:
> On Nov 21, 2007 1:37 PM, Andrew Straw <str...@as...> wrote:
> 
>> Can you give me a pointer about what exactly you did? Just now, I just
>> discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
>> nice if there was something that automatically showed just tabs and
>> end-of-line whitespace. As it is, I found
>> whitespace-visual-set-whitespace-chars doesn't seem to have quite that
>> level of granularity. Have you configured anything beyond this?
> 
> I ended up adding both of these to .emacs and restarting. Probably
> one or the other would work. For some reason I had to restart, and
> not just eval them in .emacs (??)
> 
> (add-hook 'python-mode-hook
> (lambda ()
> 	 (setq show-trailing-whitespace t)
> 	 ))
> 
> (mapc (lambda (hook)
> (add-hook hook (lambda ()
> (setq show-trailing-whitespace t))))
> '(python-mode-hook))

On Nov 21, 2007 1:37 PM, Andrew Straw <str...@as...> wrote:
> Can you give me a pointer about what exactly you did? Just now, I just
> discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
> nice if there was something that automatically showed just tabs and
> end-of-line whitespace. As it is, I found
> whitespace-visual-set-whitespace-chars doesn't seem to have quite that
> level of granularity. Have you configured anything beyond this?
I ended up adding both of these to .emacs and restarting. Probably
one or the other would work. For some reason I had to restart, and
not just eval them in .emacs (??)
(add-hook 'python-mode-hook
 (lambda ()
	 (setq show-trailing-whitespace t)
	 ))
(mapc (lambda (hook)
 (add-hook hook (lambda ()
 (setq show-trailing-whitespace t))))
 '(python-mode-hook))

John Hunter wrote:
> ( I configured my emacs to detect
> whitespace) and suspect I may have been a trailing whitespace
> contributer,
Can you give me a pointer about what exactly you did? Just now, I just
discovered a whitespace-cleanup and a whitespace-visual-mode. It'd be
nice if there was something that automatically showed just tabs and
end-of-line whitespace. As it is, I found
whitespace-visual-set-whitespace-chars doesn't seem to have quite that
level of granularity. Have you configured anything beyond this?
Thanks,
Andrew

Thank you for tracking this down, Mike.
Darren 
On Wednesday 21 November 2007 11:17:04 am Michael Droettboom wrote:
> It seems that the set of callbacks held by the Axis objects was not
> being cleared by cla().
>
> This has been fixed in SVN r4404, and does seem to correct your example
> script. I'd appreciate a sanity check by the other developers to make
> sure that change makes sense -- i.e. that the Axis callbacks don't
> really need to stick around beyond the call to cla() for any reason I'm
> not aware of.
>
> An alternative and more general solution would be to change the
> implementation of CallbackRegistry so it uses a WeakValueDictionary, so
> that it won't keep callback targets alive that have otherwise been
> orphaned. But I can't decide whether that is a good thing or would just
> hide easily fixed errors.
>
> Cheers,
> Mike
>
> Michael Droettboom wrote:
> > I should have some time today to look at this, unless any other
> > developers already know an obvious solution.
> >
> > Cheers,
> > Mike
> >
> > Darren Dale wrote:
> >> I have been working on an application which is basically a dressed up
> >> version of embedding_in_qt4.py. I have two canvases, one is just a plot,
> >> the other an image with a colorbar, both of which should get updated
> >> about once a second as data is acquired. I noticed that for larger
> >> images, it was taking longer to update the canvases as time went on.
> >>
> >> Attached is a script that demonstrates the problem (png's are also
> >> attached for those who dont have PyQt4). At each timeout, I check the
> >> time, generate a new random array, update the image's data, draw it,
> >> collect garbage, and check the time again. The plot in the upper window
> >> shows how long it took to update the image canvas as a function of
> >> iteration number.
> >>
> >> When the image has a colorbar, the time to update the image canvas
> >> increases linearly, about 0.3 ms/iteration. This can really add up:
> >> after 20,000 iterations it takes about 5-6 seconds to update the image
> >> canvas. If I comment out the line that creates the colorbar (line 64),
> >> the time to update the image canvas does not increase.
> >>
> >> A couple other observations and benchmarks from this test:
> >>
> >> * The intercept for the update time with a color bar was 0.17 seconds
> >> * With the colorbar enabled but garbage collection turned off, the
> >> application slowly consumed memory, roughly 12KB/iteration
> >> * Updating an image without a colorbar took 0.1 seconds per iteration,
> >> and did not increase
> >> * Turning off both garbage collection and the colorbar decreased the
> >> update time to 0.043 seconds, with maybe 1.7 KB/iteration increase in
> >> memory usage.
> >>
> >> I don't know if I'll get a chance to dig any further into this in the
> >> next two weeks. For now, I'll just disable the colorbar in my
> >> application.
> >>
> >> Darren
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> ------------------------------------------------------------------------
> >>- This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2005.
> >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Matplotlib-devel mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
dd...@co...

It seems that the set of callbacks held by the Axis objects was not 
being cleared by cla().
This has been fixed in SVN r4404, and does seem to correct your example 
script. I'd appreciate a sanity check by the other developers to make 
sure that change makes sense -- i.e. that the Axis callbacks don't 
really need to stick around beyond the call to cla() for any reason I'm 
not aware of.
An alternative and more general solution would be to change the 
implementation of CallbackRegistry so it uses a WeakValueDictionary, so 
that it won't keep callback targets alive that have otherwise been 
orphaned. But I can't decide whether that is a good thing or would just 
hide easily fixed errors.
Cheers,
Mike
Michael Droettboom wrote:
> I should have some time today to look at this, unless any other 
> developers already know an obvious solution.
> 
> Cheers,
> Mike
> 
> Darren Dale wrote:
>> I have been working on an application which is basically a dressed up version 
>> of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an 
>> image with a colorbar, both of which should get updated about once a second 
>> as data is acquired. I noticed that for larger images, it was taking longer 
>> to update the canvases as time went on.
>>
>> Attached is a script that demonstrates the problem (png's are also attached 
>> for those who dont have PyQt4). At each timeout, I check the time, generate a 
>> new random array, update the image's data, draw it, collect garbage, and 
>> check the time again. The plot in the upper window shows how long it took to 
>> update the image canvas as a function of iteration number.
>>
>> When the image has a colorbar, the time to update the image canvas increases 
>> linearly, about 0.3 ms/iteration. This can really add up: after 20,000 
>> iterations it takes about 5-6 seconds to update the image canvas. If I 
>> comment out the line that creates the colorbar (line 64), the time to update 
>> the image canvas does not increase.
>>
>> A couple other observations and benchmarks from this test:
>>
>> * The intercept for the update time with a color bar was 0.17 seconds
>> * With the colorbar enabled but garbage collection turned off, the application 
>> slowly consumed memory, roughly 12KB/iteration
>> * Updating an image without a colorbar took 0.1 seconds per iteration, and did 
>> not increase
>> * Turning off both garbage collection and the colorbar decreased the update 
>> time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage.
>>
>> I don't know if I'll get a chance to dig any further into this in the next two 
>> weeks. For now, I'll just disable the colorbar in my application.
>>
>> Darren
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Sorry -- I accidentally used a feature only available in Python 2.4 and 
above.
I have added a fix in SVN r4402. Since I don't have a Python2.3 to test 
with, can you please let me know if that fixes your problem?
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
> 
> I have installed matplotlib via svn on Centos (x86-64 
> python2.3). If I try to import pylab I get
> 
> Python 2.3.4 (#1, May 2 2007, 19:18:17)
> [GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
> Type "help", "copyright", "credits" or "license" for more 
> information.
>>>> from pylab import plot, show
> Traceback (most recent call last):
> File "<stdin>", line 1, in ?
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/pylab.py", 
> line 1, in ?
> from matplotlib.pylab import *
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/__init__.py", 
> line 94, in ?
> from rcsetup import defaultParams, validate_backend, 
> validate_toolbar
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/rcsetup.py", 
> line 12, in ?
> from matplotlib.fontconfig_pattern import 
> parse_fontconfig_pattern
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/fontconfig_pattern.py", 
> line 21, in ?
> from matplotlib.pyparsing import Literal, OneOrMore, 
> ZeroOrMore, Optional, Regex, \
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
> line 3151, in ?
> commonHTMLEntity = Combine("&" + oneOf("gt lt amp 
> nbsp quot").setResultsName("entity") +";")
> File 
> "/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
> line 2849, in oneOf
> symbols.sort(reverse=True)
> TypeError: sort() takes no keyword arguments
> 
> Any pointer would be appreciated.
> 
> Nils
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I have installed matplotlib via svn on Centos (x86-64 
python2.3). If I try to import pylab I get
Python 2.3.4 (#1, May 2 2007, 19:18:17)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from pylab import plot, show
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/pylab.py", 
line 1, in ?
 from matplotlib.pylab import *
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/__init__.py", 
line 94, in ?
 from rcsetup import defaultParams, validate_backend, 
validate_toolbar
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/rcsetup.py", 
line 12, in ?
 from matplotlib.fontconfig_pattern import 
parse_fontconfig_pattern
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/fontconfig_pattern.py", 
line 21, in ?
 from matplotlib.pyparsing import Literal, OneOrMore, 
ZeroOrMore, Optional, Regex, \
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
line 3151, in ?
 commonHTMLEntity = Combine("&" + oneOf("gt lt amp 
nbsp quot").setResultsName("entity") +";")
 File 
"/data/home/nwagner/local/lib64/python2.3/site-packages/matplotlib-0.90.1-py2.3-linux-x86_64.egg/matplotlib/pyparsing.py", 
line 2849, in oneOf
 symbols.sort(reverse=True)
TypeError: sort() takes no keyword arguments
Any pointer would be appreciated.
Nils

I should have some time today to look at this, unless any other 
developers already know an obvious solution.
Cheers,
Mike
Darren Dale wrote:
> I have been working on an application which is basically a dressed up version 
> of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an 
> image with a colorbar, both of which should get updated about once a second 
> as data is acquired. I noticed that for larger images, it was taking longer 
> to update the canvases as time went on.
> 
> Attached is a script that demonstrates the problem (png's are also attached 
> for those who dont have PyQt4). At each timeout, I check the time, generate a 
> new random array, update the image's data, draw it, collect garbage, and 
> check the time again. The plot in the upper window shows how long it took to 
> update the image canvas as a function of iteration number.
> 
> When the image has a colorbar, the time to update the image canvas increases 
> linearly, about 0.3 ms/iteration. This can really add up: after 20,000 
> iterations it takes about 5-6 seconds to update the image canvas. If I 
> comment out the line that creates the colorbar (line 64), the time to update 
> the image canvas does not increase.
> 
> A couple other observations and benchmarks from this test:
> 
> * The intercept for the update time with a color bar was 0.17 seconds
> * With the colorbar enabled but garbage collection turned off, the application 
> slowly consumed memory, roughly 12KB/iteration
> * Updating an image without a colorbar took 0.1 seconds per iteration, and did 
> not increase
> * Turning off both garbage collection and the colorbar decreased the update 
> time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage.
> 
> I don't know if I'll get a chance to dig any further into this in the next two 
> weeks. For now, I'll just disable the colorbar in my application.
> 
> Darren
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
On Nov 21, 2007 3:39 PM, Gael Varoquaux <gae...@no...> wrote:
> I have had some problems printing posters on a plot where indeed the
> colors came out a bit wrong. I was told by the staff that it was because
> the conversion RGB->CMYK was handled differently by different printers
> and screens. I don't know if providing and ICC profile would solve the
> problem, but it can't harm.
The ICC profile maps the device-dependent RGB (or CMYK) values stored
in the plot to a device-independent color space (either CIE Lab or the
equivalent XYZ). This independent color space describes *absolute*
color - a point in Lab space is therefore intended to look the same on
any screen or printer. When this profile is combined with a second ICC
profile for the target screen or printer on which the plot is to be
viewed/printed, it allows the color management software to convert the
RGB values in the PDF to the appropriate RGB or CMYK values that will
produce the intended absolute color on the target device.
It is therefore important to realise that both RGB and CMYK are
*relative* color spaces, relative to some device. The R, G and B
values are merely weights mixing together the device's interpretation
of true R, G and B (the same goes for CMYK).
Some problems:
- Devices produce different subsets of the set of all visible colors
(the issue of color gamut). For example, CMYK printers struggle with
highly saturated green. If you make an RGB plot on your LCD screen, a
pure green line with color 'g' or 0x00FF00 may not ever come out the
same way on your printer.
- Matplotlib plots typically use an abstract concept of color. Lines
are usually colored to distinguish them from each other, and
frequently the absolute color is not that important. More importantly,
there is typically no device associated with the input color (as is
the case with images derived from scanners or digital cameras), and
therefore no way to map the RGB relative values to absolute color.
Possible solutions:
- Use colors that are safe for printing and displaying (less saturated colors?).
- Use Lab color, which is absolute. This is cumbersome, and RGB is
much more commonplace and well-understood in plotting packages,
including Matlab.
- Associate a generic ICC profile with the mpl plot, to attach
absolute color values to the RGB values in the plot in a consistent
way. Maybe this is the default in many graphics file formats and
therefore redundant, or maybe it does make a difference specifying it
explicitly, I'm not sure.
> Is this also possible for EPS, or are we stuck with the problem without a
> good solution?
As far as I can tell, you can embed ICC profiles in most graphic file
formats, including PDF, EPS, JPG, PNG, SVG, TIFF, etc.
Regards,
Ludwig

I have had some problems printing posters on a plot where indeed the
colors came out a bit wrong. I was told by the staff that it was because
the conversion RGB->CMYK was handled differently by different printers
and screens. I don't know if providing and ICC profile would solve the
problem, but it can't harm.
Is this also possible for EPS, or are we stuck with the problem without a
good solution? By the way, what is the status of TeX support in PDF. On
the version I have on my box it is not running, but I don't run svn.
Cheers,
Gaël

Ludwig Schwardt wrote:
>> Publishers sometimes require electronic figures as tif or eps, and using
>> the cymk color system. We do everything in rgb. I don't understand
>> color systems well. What would be needed to give mpl the ability to
>> produce files using the cymk system?
 >
> PDF/X-3 might be a worthwhile standard to follow for mpl figure output
> (even only as an option). At least embedding ICC profiles is probably
> a good idea.
That seems like a great suggestion (without knowing the details of what 
is really involved). I wonder if that would appease some of the 
publisher's requirements that Eric mentioned. I vaguely recall seeing 
CMYK requirements myself in the past, but I can't dig up any of them. I 
just wonder what *specifically* publishers may require, and whether 
providing an ICC profile in the PDF or converting rgb colors to cmyk on 
output (within matplotlib) is the better way to go.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
> Publishers sometimes require electronic figures as tif or eps, and using
> the cymk color system. We do everything in rgb. I don't understand
> color systems well. What would be needed to give mpl the ability to
> produce files using the cymk system?
I don't understand color systems very well, either, but I ran into
this problem when I printed out some color figures recently.
I saved a mpl line plot containing 'r', 'g' and 'b' lines to a PDF
file. The file displayed on-screen as expected, using both Linux
acroread and Mac OS X Preview as viewer. It also printed out as
expected on an HP Color Laserjet via Linux acroread. On the Mac,
however, a straightforward printout resulted in purple instead of blue
lines. The problem disappeared when I selected ColorSync -> Color
Conversion -> In Printer in the print dialog.
When I printed out an OmniGraffle PDF diagram, however, the colors
were messed up using "In Printer" and correct when using "Standard"
color conversion. This forced me to print the color pages in my thesis
containing OmniGraffle diagrams and mpl figures using different
printer settings, which is quite annoying.
There is another option, which makes Linux and Mac PDFs much more
compatible (especially for color), and that is PDF/X-3
(http://en.wikipedia.org/wiki/PDF/X). This subset of PDF forces the
document to include all fonts and color profiles, leaving nothing to
chance. While the file is possibly bigger, it is more likely to
display correctly on all manner of printers and screens. I eventually
converted my Omnigraffle diagrams to PDF/X-3, and now their colors and
shadows appear correct on Linux, while they were psychedelic before.
PDF/X-3 might be a worthwhile standard to follow for mpl figure output
(even only as an option). At least embedding ICC profiles is probably
a good idea.
Regards,
Ludwig

I have been working on an application which is basically a dressed up version 
of embedding_in_qt4.py. I have two canvases, one is just a plot, the other an 
image with a colorbar, both of which should get updated about once a second 
as data is acquired. I noticed that for larger images, it was taking longer 
to update the canvases as time went on.
Attached is a script that demonstrates the problem (png's are also attached 
for those who dont have PyQt4). At each timeout, I check the time, generate a 
new random array, update the image's data, draw it, collect garbage, and 
check the time again. The plot in the upper window shows how long it took to 
update the image canvas as a function of iteration number.
When the image has a colorbar, the time to update the image canvas increases 
linearly, about 0.3 ms/iteration. This can really add up: after 20,000 
iterations it takes about 5-6 seconds to update the image canvas. If I 
comment out the line that creates the colorbar (line 64), the time to update 
the image canvas does not increase.
A couple other observations and benchmarks from this test:
* The intercept for the update time with a color bar was 0.17 seconds
* With the colorbar enabled but garbage collection turned off, the application 
slowly consumed memory, roughly 12KB/iteration
* Updating an image without a colorbar took 0.1 seconds per iteration, and did 
not increase
* Turning off both garbage collection and the colorbar decreased the update 
time to 0.043 seconds, with maybe 1.7 KB/iteration increase in memory usage.
I don't know if I'll get a chance to dig any further into this in the next two 
weeks. For now, I'll just disable the colorbar in my application.
Darren

Jeff Whitaker wrote:
> Chris: I don't consider the pyrex GEOS interface I created for basemap 
> a general-purpose binding - it's limited to the only the functionality 
> that basemap needs.
sure, but if there was an existing general purpose binding that met your 
needs, you wouldn't need this.
 > The ability of pyrex to do loops in C makes it a
> lot faster than the Shapely ctypes interface though.
True -- that is key. If the C lib doesn't provide a "vectorized" API, 
then you do need to find a way to loop in C yourself.
 > I have
> corresponded with Sean Gillies about this (and the LGPL licensing 
> issue), and as a result I think Shapley 2.0 will be based on Pyrex and 
> will have a BSD license. Perhaps then I can switch basemap back to 
> using it.
Cool -- that is open-source collaboration as it should be!
> Eric mentioned the fact that ctypes often has a hard time finding the 
> shared library to load.
> You can't even tell ctypes where to look - 
> it's hard-coded into the Shapely __init__ and there's no way I can see 
> to override the search path that ctypes uses.
Wow! that does seem an oversight. I haven't used ctypes myself -- 
frankly, I think people are trying to push it a bit too far, it's an 
excellent solution for calling the occasional system lib, but maybe not 
so much for writing full-featured wrappers.
Pyrex is very cool though. For the moment, I'm struggling with SWIG, and 
sadly it is a bit of a struggle. However I'm doing 'cause it's used by 
wxPython, GDAL, and VTK, all of which I want to be able to hack on a 
bit, so I might as well learn it.
Anyway -- basemap is looking better and better!
-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...

Christopher Barker wrote:
> Jeff,
>
> as you mentioned license as one issue in not using shapely, I thought 
> you might be interested in this:
>
> -------- Original Message --------
> Subject: [Community] Proposal to change Shapely license from LGPL to BSD
> From: Sean Gillies <sgi...@fr...>
>
> I propose that the Shapely license be changed to the 3 clause modified
> BSD used by OWSLib, GeoJSON, Rtree, and WorldMill. I choose LGPL
> orginally to match the GEOS license, but I think consistency across the
> new GIS-Python projects is more important.
> --------
>
>
> As for ctypes vs. pyrex -- I find it ironic that you've chosen pyrex 
> for dependency reasons -- there are lot of folks that using ctypes to 
> asve the hassles of compiliation, particularly on Windows (see 
> geoGjango, for instance). But I guess MPL required compilation anyway.
>
> I'm just poking at this 'cause I'd really like to see as little 
> redundancy of python bindings for stuff as possible. WE alrady have 
> geos bound by ogr, shapely (I think geoDjango), and who knows who else.
>
> Oh well, we all need to do what works best for our needs. I guess it's 
> real credit to tools like swig, ctypes and pyrex (and python itself) 
> that anyone would even consider writing their own bindings to something!
>
> -Chris
>
>
>
Chris: I don't consider the pyrex GEOS interface I created for basemap 
a general-purpose binding - it's limited to the only the functionality 
that basemap needs. The ability of pyrex to do loops in C makes it a 
lot faster than the Shapely ctypes interface though. I have 
corresponded with Sean Gillies about this (and the LGPL licensing 
issue), and as a result I think Shapley 2.0 will be based on Pyrex and 
will have a BSD license. Perhaps then I can switch basemap back to 
using it.
Eric mentioned the fact that ctypes often has a hard time finding the 
shared library to load. I view this as a potential support nightmare 
for matplotlib if we use ctypes to interface with external libs, which 
might be installed anywhere. You can't even tell ctypes where to look - 
it's hard-coded into the Shapely __init__ and there's no way I can see 
to override the search path that ctypes uses.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Christopher Barker wrote:
[...]
> As for ctypes vs. pyrex -- I find it ironic that you've chosen pyrex for 
> dependency reasons -- there are lot of folks that using ctypes to asve 
> the hassles of compiliation, particularly on Windows (see geoGjango, for 
> instance). But I guess MPL required compilation anyway.
Not just dependency reasons. When I tried to use Jeff's version with 
Shapely, I had to set LD_LIBRARY_PATH=/usr/local/lib for ctypes to find 
my geos library. I couldn't find any cleaner way to do it, and I don't 
consider that acceptable. Is there a clean way to tell ctypes where a 
library is? I was surprised it was not even checking that standard 
location.
Also, pyrex does a *lot* more than ctypes, and I think Jeff will tell 
you he has put that power to good use in his new basemap version.
Eric

Jeff,
as you mentioned license as one issue in not using shapely, I thought 
you might be interested in this:
-------- Original Message --------
Subject: [Community] Proposal to change Shapely license from LGPL to BSD
From: Sean Gillies <sgi...@fr...>
I propose that the Shapely license be changed to the 3 clause modified
BSD used by OWSLib, GeoJSON, Rtree, and WorldMill. I choose LGPL
orginally to match the GEOS license, but I think consistency across the
new GIS-Python projects is more important.
--------
As for ctypes vs. pyrex -- I find it ironic that you've chosen pyrex for 
dependency reasons -- there are lot of folks that using ctypes to asve 
the hassles of compiliation, particularly on Windows (see geoGjango, for 
instance). But I guess MPL required compilation anyway.
I'm just poking at this 'cause I'd really like to see as little 
redundancy of python bindings for stuff as possible. WE alrady have geos 
bound by ogr, shapely (I think geoDjango), and who knows who else.
Oh well, we all need to do what works best for our needs. I guess it's 
real credit to tools like swig, ctypes and pyrex (and python itself) 
that anyone would even consider writing their own bindings to something!
-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...

Publishers sometimes require electronic figures as tif or eps, and using 
the cymk color system. We do everything in rgb. I don't understand 
color systems well. What would be needed to give mpl the ability to 
produce files using the cymk system?
Thanks.
Eric