[matplotlib-devel] basemap in recent matplotlib
Hi, Trying out version 0.87.4 I noticed that the example given on pages http://matplotlib.sourceforge.net/screenshots/plotmap.py and http://scipy.org/Cookbook/Matplotlib/Maps fail with : In [1]: from matplotlib.toolkits.basemap import Basemap --- exceptions.ImportError Traceback (most recent call last) /home/varoquau/ ImportError: No module named toolkits.basemap I had a quick look and couldn't find where basemap had gone. How should these pages be modified ? -- Gaël - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib as a separate process
Bill Baxter wrote: > I think all these problems could be fixed if the display interface > were turned into a separate process Have you tried ipython? http://ipython.scipy.org/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] When matplotlib is embeded in a pyGTK application, how to make the NavigationToolbar2 key ('1' '2' 'a' 'g' ..) working??
Hi all, I would like to enable the key pressed event (key '1' '2' 'a' 'g' .. ) of NavigationToolbar2 in my pyGTK app.(These keys shortcut are described here: http://sourceforge.net/tracker/index.php?func=detail&aid=1432252&group_id=80706&atid=560722)The shorcuts work perfectly using pylab. But when I include matplotlib in my pyGTK app the shorcuts are broken. How could I manage to make them work, and/or, where I should start in the source code to undestand how it work, that I could reproduce the shorkey behavior directly in my own application code?.Thanks, David - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] imshow with PS backend
Hi,
I've just moved from MATLAB to matplotlib, and I'm really impressed
with the quality of the PS figures it generates with usetex and the
xpdf distiller. I've hit a couple of problems though, one I've manged
to solve (patch against 0.87.4 attached) and the other I'd be greatful
if you could help me with please.
I've been using imshow to basically put a set of axes round an image
produced my simulation code. Here's a minimal version of my script:
--
from pylab import *
rc('text', usetex=True)
rc('ps', usedistiller="xpdf")
figure(1,figsize=(6, 4))
im=imread('image.png') # a 301x318 image
imshow(im,interpolation='nearest',extent=[0.98, 20, 0.01, 0.5])
axis('normal');
savefig('image.eps')
The first problem I noticed is that the distilling process was causing
some of my images to have (lossy) compression applied and others not.
It turns out that it is a feature of ps2pdf that it tries to detect
the content of the image and apply appropriate compression. You can
over ride this distiller options. My patch adds a new rc option
ps.image_compression that can be set to auto (preserves the current
behaviour), DCTEncode (applies lossy JPEG compression), and
FlateEncode (lossless compression). The distiller commands are
embedded in the ps file. I looked at making it a flag on each image,
but couldn't get it to work. Another way to do it is to pass extra
command line options to ps2pdf (-dAutoFilterColorImages=false
-sColorImageFilter=FlateEncode should do it for colour images). I
thought embedding it in the PS file would be more flexible.
My second problem involved the resolutions of the image. I'd like to
preserve the resolution of my image in the PS output, but I can't
figure out how to stop the image being resized and interpolated.
Obviously you need to do this for the bitmap backends, but for vector
ones surely you can just scale the original image in the vector
output.
Thanks in advance for you help and some great software!
JIM
---
--- matplotlib-0.87.4/lib/matplotlib/backends/backend_ps.py 2006-07-10 18:55:59.0 +0100
+++ matplotlib-0.87.4.new/lib/matplotlib/backends/backend_ps.py 2006-07-27 13:00:42.0 +0100
@@ -367,9 +367,11 @@ class RendererPS(RendererBase):
if im.is_grayscale:
h, w, bits = self._gray(im)
imagecmd = "image"
+imagetype="Gray"
else:
h, w, bits = self._rgb(im)
imagecmd = "false 3 colorimage"
+imagetype="Color"
hexlines = '\n'.join(self._hex_lines(bits))
xscale, yscale = w, h
@@ -381,7 +383,21 @@ class RendererPS(RendererBase):
clipx,clipy,clipw,cliph = bbox.get_bounds()
clip = '%s clipbox' % _nums_to_str(clipw, cliph, clipx, clipy)
#y = figh-(y+h)
-ps = """gsave
+
+distilleroptions_pre = ''
+distilleroptions_post = ''
+compressiontype=rcParams['ps.image_compression']
+if compressiontype != 'auto':
+distilleroptions_pre="""
+/setdistillerparams where {pop} {userdict /setdistillerparams {pop} put} ifelse
+<< /AutoFilter%(imagetype)sImages false
+/%(imagetype)sImageFilter /%(compressiontype)s
+>> setdistillerparams
+""" % locals()
+distilleroptions_post="""<< /AutoFilter%(imagetype)sImages true >> setdistillerparams
+""" % locals()
+
+ps = """gsave%(distilleroptions_pre)s
%(clip)s
%(x)s %(y)s translate
%(xscale)s %(yscale)s scale
@@ -391,7 +407,7 @@ class RendererPS(RendererBase):
currentfile DataString readhexstring pop
} bind %(imagecmd)s
%(hexlines)s
-grestore
+%(distilleroptions_post)sgrestore
""" % locals()
self._pswriter.write(ps)
--- matplotlib-0.87.4/lib/matplotlib/__init__.py2006-07-12 03:23:59.0 +0100
+++ matplotlib-0.87.4.new/lib/matplotlib/__init__.py2006-07-27 12:08:40.0 +0100
@@ -646,6 +646,13 @@ xpdf unless xpdf-%s or later is installe
raise ValueError('matplotlibrc ps.usedistiller must either be none, \
ghostscript or xpdf')
+def validate_ps_image_compression(s):
+if s in ('auto', 'FlateEncode', 'DCTEncode'):
+return s
+else:
+raise ValueError('not a valid Image compression type for PS backend \
+must be one of auto, DCTEncode FlateEncode')
+
def validate_usetex(s):
bl = validate_bool(s)
if bl:
@@ -860,6 +867,7 @@ defaultParams = {
'ps.papersize' : [ 'letter', validate_ps_papersize], # Set the papersize/type
'ps.useafm' : [ False, validate_bool], # Set PYTHONINSPECT
'ps.usedistiller' : [ False, validate_ps_distiller], # use ghostscript or xpdf to distill ps output
+'ps.image_compression' : [ 'auto', validate_ps_image_compression], # type of image compression for the distiller to use.
'ps.distiller.res' : [6000, validate_int], # dpi
'pdf.compression' : [6, validate_int],# compression level from
Re: [matplotlib-devel] Matplotlib as a separate process
Hi Stephen, Yep, ipython is not bad, but it is not really a replacement for a real IDE. IPython also seems to act a little wanky with graphs to me. For instance my plots seem to get drawn interactively (read: very SLOWLY) when I use the special -pylab mode. Maybe I'm not configuring ipython properly, but part of my point is that end users shouldn't have to think about it, and shouldn't need some special -pylab mode. It should just work. And I think it would if the displayer's guts were in a completely separate process, acting as a graph display server. The only complication I can see is for callbacks from mouse and keyboard events that occur on the graphs (but does matplotlib even support that yet?-- I only saw it mentioned on the web page). Those events would still need to find their way into callbacks in the original process. But that's doable too, I think. Just use a separate thread for communication with the graph display server. And would perhaps be even less painful than dealing with the wx event loop. Anyway, it's more of a 'food for thought' suggestion than anything else. It's not like I'm going to have time to implement it (though it seems like it would be a fun project if I did have the time). I am curious as to what the current thinking is about tacking such event loop issues, though. Surely folks don't think that "use ipython" is the be-all-and-end-all ultimate solution. --bb On 7/26/06, Stephen Walton <[EMAIL PROTECTED]> wrote: > Bill Baxter wrote: > > I think all these problems could be fixed if the display interface > > were turned into a separate process > Have you tried ipython? > > http://ipython.scipy.org/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
