matplotlib-devel Mailing List for matplotlib (Page 4)

Gary,
Thanks for the prompt test and report.
I agree that the ability to put a dot at locations where arrows are 
below a threshold would be good. I will add it. I think it should be 
similar to a circle marker that scales with the arrow width, and has a 
diameter that is a fraction of that width.
I also observed the stroking problem with small arrows and finite 
linewidth. I haven't checked into it, but I am wondering whether the 
problem is in the specification of the line join type.
Eric
Gary Ruben wrote:
> Hi Eric,
> 
> Having entered the build-from-source world with the latest ubuntu, I 
> applied your patch and tried it out with the example code I sent you 
> using a call similar to
> 
> quiver2(x,y,u,v,units='x',width=0.5,headwidth=3,headlength=3,headaxislength=2) 
> 
> 
> This works very nicely for my purposes - perfectly in fact.
> Many thanks for your work on this.
> The only thing I think might be nice to add is some sort of minsize 
> parameter so that you could get a pixel or something marking the 
> existence of a data value for a grid point or a tiny arrowhead, sort of 
> like the current svn quiver behaves, but size settable. I tried adding 
> linewidths=(1,) to see if this would work. It sort of works, but looks 
> pretty ugly and I think confirms my suspicion that the problems I had 
> seen in my attempts were due to line stroking.
> 
> Thanks and good work!
> 
> Gary

John Hunter wrote:
> In the last figure 4 of contour_demo.py, the positioning of the
> vertical colorbar looks too low. I would expect it to align roughly
> with the vertical extent of the image axes. Is this intentional,
> configurable, or a bug?
I would call it a design deficiency. In mpl as in matlab, automatic 
colorbar positioning is done in a very simple way: an existing axes is 
shrunken and a colorbar is added using liberated space, and positioned 
relative to the shrunken axes. When a colorbar is added, the same thing 
happens, and the first colorbar is not repositioned to take into account 
the new size and position of the master axes. The key point is that the 
positioning is done once for each colorbar--it is static.
The nicest way to fix this might require something that I think you have 
deliberately and wisely left out of mpl so far: a layout engine, like 
the Tk packer etc.
Simpler methods might be devised. I am not inclined to spend time on 
this right now, however, because (1) the problem only arises when using 
two colorbars, which is probably not a very common use case, and (2) it 
is easily fixed by manually repositioning the colorbars, so it is not a 
problem for publication-quality plots. Also (3) getting the 
aspect-ratio handling working has been enough of a struggle that I am 
reluctant to risk destabilizing it right now (under the optimistic 
assumption that it actually is stable now), and (4) I think there are 
much more important things that need work.
Maybe what I should do is add the manual positioning to the demo so the 
plot looks nice, and serves as an example of how to do the positioning.
> 
> Also, in many of the contour examples, the text labels overlap the
> contour lines, especially when the text labels are large. Should we
> revisit the code which removes line segments that overlap the text
> code to see if we can improve this a bit?
To do this well might require quite a different strategy than the 
present one; the segment removal might need to be done at drawing time, 
so that it could adapt to the scale of the plot when it is drawn. The 
problem is that the lines scale with the figure size but the labels 
don't. So one might need a "LabelledLineCollection" artist instead of 
using separate LineCollection and Text artists.
Eric

1. All the set calls should be setp calls
So:
 set(gca(), 'xticks', [1,2,3,4])
should be:
from pylab import *
 setp(gca(), 'xticks', [1,2,3,4])
2. Question:
"Can I just generate images without having a window popup?"
HTML markup is bad, so I get this in my browser
href=backends.html#Cairo>Cairo
Here goes the patch (first one ever :))
--- faq.html.template	2006年06月05日 01:33:45.531250000 +0200
+++ faq.html.template.new	2006年06月05日 01:37:15.203125000 +0200
@@ -747,7 +747,7 @@
 'Can I just generate images without having a window popup?',
 """
 The easiest way to do this is use an image backend, either <a
-href=backends.html#Agg>Agg</a>, href=backends.html#Cairo>Cairo</a>, <a
+href=backends.html#Agg>Agg</a>, <a href=backends.html#Cairo>Cairo</a>, <a
 href=backends.html#GD>GD</a> or <a href=backends.html#Paint>Paint</a>
 if you want to generate PNG images, eg, for use in a web page, or PS
 if you want publication quality, scalable images. All of these
@@ -858,7 +858,7 @@
 <pre>
 locs, labels = xticks()
-set(labels, fontsize=8)
+setp(labels, fontsize=8)
 </pre>
 You can also set the default ticklabel size in your <a
@@ -901,10 +901,10 @@
 <pre>
 from pylab import *
 plot([1,2,3,4], [1,4,9,16])
- set(gca(), 'xticks', [1,2,3,4])
- labels = set(gca(), 'xticklabels',
+ setp(gca(), 'xticks', [1,2,3,4])
+ labels = setp(gca(), 'xticklabels',
 ['Frogs', 'Hogs', 'Bogs', 'Slogs'])
- set(labels, 'rotation', 'vertical')
+ setp(labels, 'rotation', 'vertical')
 show()
 </pre>
 """),

Robert Hetland wrote:
> 
> Let me know if you would like to do a quick alpha test before you 
> commit. I'll help to put it through the paces..
> 
> -Rob.
Rob,
Thanks. Attached are a diff against svn and a test script to get you 
started. If you apply the diff as a patch, you should be able to call 
quiver2 from the pylab interface. Docstrings are provided. I made no 
attempt to copy the kwarg part of the API from the old quiver; this one 
is just too different. Most of the arg part of the API is the same, 
except that the optional third or fifth argument is a mappable array 
instead of a scale; I made the scale a kwarg, and it operates completely 
differently from the one in the old quiver--but for good reason, I think.
The key idea for the scale is that the "units" kwarg establishes a unit 
of measure ("arrow unit") for the arrows, and the scale gives the U,V 
data units per arrow unit. For example, if units="inches" and you have 
a 1 m/s velocity vector, then setting scale=2 will mean 2 m/s per inch, 
and the vector will be half an inch (assuming the figure dpi value is 
correct), regardless of how you change the window size or zoom. If 
units="x", and your x-axis goes from 0 to 50 km, then you might set 
scale=1/5.0 so that 1 m/s corresponds to 5 km along the x-axis; if you 
zoom in, the vector will grow. If units="width" (present default, though 
maybe not a good one), then the unit is the width of the plot, so you 
might make scale=50, so that 1 m/s makes an arrow 1/50th the width of 
the plot. Change the window width, and the arrow length changes along 
with it. Zoom, and it does not change, however. In all cases, the 
arrow direction remains constant, regardless of window or view limit 
manipulations. (This is all because of John's transform magic--it is a 
little hard to understand at first, but it certainly provides wonderful 
functionality.)
There is a simple auto-scaling algorithm, so one does not have to 
specify the scale kwarg initially.
Once quiver.py is in place, I will add related functionality such as 
ellipses, so you can plot mean velocities and standard error ellipses, 
for example.
One thing I have not looked into yet is what it will take to do all this 
correctly with polar axes and with basemap, which I will need.
Eric

John Hunter wrote:
> In the last figure 4 of contour_demo.py, the positioning of the
> vertical colorbar looks too low. I would expect it to align roughly
> with the vertical extent of the image axes. Is this intentional,
> configurable, or a bug?
> 
I committed a change to the demo that repositions the colorbar.
Eric

John Hunter wrote:
>>>>>>"Charlie" == Charlie Moad <cw...@gm...> writes:
> 
> 
> Charlie> On 6/2/06, David S. <dav...@al...> wrote:
> >> I have just installed numpy-0.9.8, scipy-0.4.9, and
> >> matplotlib-0.87.2 on a Windows machine with Python 2.4.2.
> 
> Charlie> matplotlib-0.87.2 requires numpy-0.9.6. You will get an
> Charlie> error otherwise.
> 
> 
> This is starting to bite enough people that we should consider rolling
> out a release. We had hope to get the 3d stuff working before the
> next release, but having a version up there that doesn't work with the
> latest numpy is a more pressing problem to me. Does this seem like a
> good idea to you Charlie? Are there other features or fixes that
> other developers would like to get in first?
John,
I agree that it is time for a new release.
The changes I have been making involving not rendering things with alpha 
== 0 or linewidth == 0 are certainly not complete, but I don't think 
this is a showstopper. Anything using agg should be OK, postscript is 
OK, svg is OK with linewidth == 0, which I think is what matters most 
immediately--some things rely on this. Help from other developers will 
be needed for other backends.
A new quiver could come before or after a release. I have not committed 
anything yet. I would like to be able to start doing so fairly soon, but 
in a way that does not cause trouble with a release. (At present, I am 
calling the new version quiver2 so that I can work with the pylab 
interface without clobbering the original version. The API will differ 
from that of the original, so maybe both should be present, with 
different names, for a while.) It would help to know when the actual 
production of the release is likely to occur, of course.
Eric

In the last figure 4 of contour_demo.py, the positioning of the
vertical colorbar looks too low. I would expect it to align roughly
with the vertical extent of the image axes. Is this intentional,
configurable, or a bug?
Also, in many of the contour examples, the text labels overlap the
contour lines, especially when the text labels are large. Should we
revisit the code which removes line segments that overlap the text
code to see if we can improve this a bit?
JFH

Jordan, Gary,
I have been working on another implementation of quiver functionality. It is not ready to commit yet, but I think I have the transforms worked out reasonably well. The arrows never get distorted, and their orientation is preserved as the axes are manipulated. Length can be preserved or not, depending on the units one chooses. Below a threshold, the whole arrow is scaled down as its length is reduced; above that threshold, only the length changes. I am subclassing PolyCollection, so there is full flexibility in rendering with or without an edge.
I expect I will be ready to commit something within a week.
Eric

Eric Firing wrote:
> Jeff,
>
> Thanks for the report. I have committed a bugfix combined with a speedup: the check for gray will not occur if the image is cached.
>
> Eric
>
> 
Thanks Eric - that works fine.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
NOAA/OAR/CDC R/PSD1 FAX : (303)497-6449
325 Broadway Boulder, CO, USA 80305-3328

Jeff,
Thanks for the report. I have committed a bugfix combined with a speedup: the check for gray will not occur if the image is cached.
Eric
----- Original Message -----
From: Jeff Whitaker <js...@fa...>
Date: Friday, June 2, 2006 1:07 pm
Subject: [matplotlib-devel] RGBA in imshow
To: matplotlib development list <mat...@li...>
> Hi all:
> 
> It looks like one can no longer plot an array of RGBA values in 
> imshow - 
> I suspect this is a consequence of the recent changes to the way 
> colors 
> are handled. For example
> 
> from pylab import *
> # make a random rgba matrix
> rgba = ones((64,64,4),'f')
> for k in range(3):
> rgba[:,:,k] = rand(64,64).astype('f')
> imshow(rgba)
> show()
> 
> works in 0.87.2, but fails with
> 
> Traceback (most recent call last):
> File "/Users/jsw/lib/python/matplotlib/backends/backend_gtk.py", 
> line 
> 283, in expose_event
> self._render_figure(self._pixmap, w, h)
> File 
> "/Users/jsw/lib/python/matplotlib/backends/backend_gtkagg.py", 
> line 72, in _render_figure
> FigureCanvasAgg.draw(self)
> File "/Users/jsw/lib/python/matplotlib/backends/backend_agg.py", 
> line 
> 389, in draw
> self.figure.draw(renderer)
> File "/Users/jsw/lib/python/matplotlib/figure.py", line 531, in draw
> for a in self.axes: a.draw(renderer)
> File "/Users/jsw/lib/python/matplotlib/axes.py", line 991, in draw
> im.draw(renderer)
> File "/Users/jsw/lib/python/matplotlib/image.py", line 184, in draw
> im = self.make_image()
> File "/Users/jsw/lib/python/matplotlib/image.py", line 130, in 
> make_image im.is_grayscale = (self.cmap.is_gray() and
> File "/Users/jsw/lib/python/matplotlib/colors.py", line 634, in 
> is_gray return (alltrue(self._lut[:,0] == self._lut[:,1])
> 
> with the latest svn.
> 
> This patch to image.py seems to fix it, but I'm not sure it's the 
> right 
> solution
> 
> --- /Users/jsw/lib/python/matplotlib/image.py.orig 2006年06月02日 
> 17:04:52.000000000 -0600
> +++ /Users/jsw/lib/python/matplotlib/image.py 2006年06月02日 
> 17:05:24.000000000 -0600
> @@ -127,8 +127,10 @@
> im.flipud_in()
> 
> im.set_bg( *bg)
> - im.is_grayscale = (self.cmap.is_gray() and
> - len(self._A.shape) == 2)
> + if len(self._A.shape) == 2:
> + im.is_grayscale = self.cmap.is_gray()
> + else:
> + im.is_grayscale = False
> 
> im.set_interpolation(self._interpd[self._interpolation])
> 
> 
> -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
> 
> 
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hi all:
It looks like one can no longer plot an array of RGBA values in imshow - 
I suspect this is a consequence of the recent changes to the way colors 
are handled. For example
from pylab import *
# make a random rgba matrix
rgba = ones((64,64,4),'f')
for k in range(3):
 rgba[:,:,k] = rand(64,64).astype('f')
imshow(rgba)
show()
works in 0.87.2, but fails with
Traceback (most recent call last):
 File "/Users/jsw/lib/python/matplotlib/backends/backend_gtk.py", line 
283, in expose_event
 self._render_figure(self._pixmap, w, h)
 File "/Users/jsw/lib/python/matplotlib/backends/backend_gtkagg.py", 
line 72, in _render_figure
 FigureCanvasAgg.draw(self)
 File "/Users/jsw/lib/python/matplotlib/backends/backend_agg.py", line 
389, in draw
 self.figure.draw(renderer)
 File "/Users/jsw/lib/python/matplotlib/figure.py", line 531, in draw
 for a in self.axes: a.draw(renderer)
 File "/Users/jsw/lib/python/matplotlib/axes.py", line 991, in draw
 im.draw(renderer)
 File "/Users/jsw/lib/python/matplotlib/image.py", line 184, in draw
 im = self.make_image()
 File "/Users/jsw/lib/python/matplotlib/image.py", line 130, in make_image
 im.is_grayscale = (self.cmap.is_gray() and
 File "/Users/jsw/lib/python/matplotlib/colors.py", line 634, in is_gray
 return (alltrue(self._lut[:,0] == self._lut[:,1])
with the latest svn.
This patch to image.py seems to fix it, but I'm not sure it's the right 
solution
--- /Users/jsw/lib/python/matplotlib/image.py.orig 2006年06月02日 
17:04:52.000000000 -0600
+++ /Users/jsw/lib/python/matplotlib/image.py 2006年06月02日 
17:05:24.000000000 -0600
@@ -127,8 +127,10 @@
 im.flipud_in()
 
 im.set_bg( *bg)
- im.is_grayscale = (self.cmap.is_gray() and
- len(self._A.shape) == 2)
+ if len(self._A.shape) == 2:
+ im.is_grayscale = self.cmap.is_gray()
+ else:
+ im.is_grayscale = False
 
 im.set_interpolation(self._interpd[self._interpolation])
-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