matplotlib-users Mailing List for matplotlib (Page 14)

Thanks I got it fixed.
This leads to the follow up question:
What is the right way to keep an application responsive while the graph is
drawn?
Drawing a scatter plot with 300 points seems to take a while. I guess I need
to launch the drawing in another thread but don't know exactly how to do
this and only find examples of doing calculations in the background and not
actual widget interaction.
- Alex
On Sun, Jan 3, 2010 at 3:37 PM, Darren Dale <dsd...@gm...> wrote:
> On Sun, Jan 3, 2010 at 5:26 PM, Alexander Hupfer <so...@gm...> wrote:
> > Ok, that at least fixed the tkinter error, but I still don't get a
> colorbar
> > attached to my plot. (which worked fine when I didn't embedd it in a Qt
> > application)
>
> If you are importing from pylab or pyplot in your program, don't.
> These modules are not compatible with embedding.
>
> Darren
>

Phillip M. Feldman wrote:
> What is meant by "draw time"?
When you call text(...), a Text object is created and added to a list of 
things (Artists) to be drawn, but no drawing occurs (unless using pyplot 
in interactive mode) until a draw(), show(), or savefig() command is 
given. That's "draw time".
> 
> For most purposes, I think that I'd want to specify an offset in font 
> units (points). If offsets are specified in units of pixels, then the 
> results would be display-dependent, and achieving display-independent 
> results would require some additional fiddling. I would recommend 
> allowing the user to select units of points, pixels, mm, inches, or plot 
> units, with a default of points.
Much easier said than done, unfortunately. Not impossible. Who's going 
to bell the cat?
Eric
> 
> Phillip
> 
> John Hunter wrote:
>> On Sun, Jan 3, 2010 at 2:50 PM, Eric Firing <ef...@ha...> wrote:
>> 
>>> I think that allowing display units would be easy to implement (as 
>>> indicated
>>> by Ryan's example), but font or physical units would be much trickier
>>> because they would involve draw-time determinations. Starting by 
>>> allowing
>>> only display units still would be much better than the present 
>>> situation.
>>>
>>> Collections already have something like this, with their offset and
>>> offset_transform kwargs, but they are still a little more difficult 
>>> to use
>>> than what I am thinking of for text.
>>> 
>>
>> This would be a nice feature, but a little tricky to do generally
>> since the text objects are already so complicated ... I mean feature
>> rich.
>>
>> One could simply do a draw time offset and convert points->pixels (eg
>> as in Annotation) but to get everything to play consistently with
>> annotations, arrows, fancy boxes, etc, would require some care and
>> thought.
>>
>> JDH
>>
>> 
> 

What is meant by "draw time"?
For most purposes, I think that I'd want to specify an offset in font 
units (points). If offsets are specified in units of pixels, then the 
results would be display-dependent, and achieving display-independent 
results would require some additional fiddling. I would recommend 
allowing the user to select units of points, pixels, mm, inches, or plot 
units, with a default of points.
Phillip
John Hunter wrote:
> On Sun, Jan 3, 2010 at 2:50 PM, Eric Firing <ef...@ha...> wrote:
> 
>> I think that allowing display units would be easy to implement (as indicated
>> by Ryan's example), but font or physical units would be much trickier
>> because they would involve draw-time determinations. Starting by allowing
>> only display units still would be much better than the present situation.
>>
>> Collections already have something like this, with their offset and
>> offset_transform kwargs, but they are still a little more difficult to use
>> than what I am thinking of for text.
>> 
>
> This would be a nice feature, but a little tricky to do generally
> since the text objects are already so complicated ... I mean feature
> rich.
>
> One could simply do a draw time offset and convert points->pixels (eg
> as in Annotation) but to get everything to play consistently with
> annotations, arrows, fancy boxes, etc, would require some care and
> thought.
>
> JDH
>
> 

On Sun, Jan 3, 2010 at 5:26 PM, Alexander Hupfer <so...@gm...> wrote:
> Ok, that at least fixed the tkinter error, but I still don't get a colorbar
> attached to my plot. (which worked fine when I didn't embedd it in a Qt
> application)
If you are importing from pylab or pyplot in your program, don't.
These modules are not compatible with embedding.
Darren

Ok, that at least fixed the tkinter error, but I still don't get a colorbar
attached to my plot. (which worked fine when I didn't embedd it in a Qt
application)
On Sun, Jan 3, 2010 at 3:13 PM, Laurent Dufrechou <
lau...@gm...> wrote:
> Hello,
>
> You are using the TK backend.
> Add this at the top of your script:
>
> import matplotlib
> matplotlib.use('QT4Agg')
>
> from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as
> FigureCanvas
> from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg as
> NavigationToolbar
>
> Should work.
> (Or at least will no more show errors related to TK backend...)
>
> Laurent
>

Hello,
You are using the TK backend.
Add this at the top of your script:
import matplotlib
matplotlib.use('QT4Agg')
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as
FigureCanvas
from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg as
NavigationToolbar
Should work.
(Or at least will no more show errors related to TK backend...)
Laurent

ok here comes some more code:
def plot_angles(results, axes):
 lk.acquire()
 x = list(results[0])
 y = list(results[1])
 lk.release()
 p = axes.scatter(x,y, c = range(len(results[0])))
 axes.set_xlabel('psi')
 axes.set_ylabel('delta')
 colorbar(p)
def update_figure(self):
 plot_angles(results, self.axes)
 self.draw()
_tkinter.TclError: bad screen distance "320.0"
Traceback (most recent call last):
 File "/home/sonium/UbuntuOne/elipsometry/fitting.py", line 156, in
update_figure
 plot_angles(results, self.axes)
 File "/home/sonium/UbuntuOne/elipsometry/fitting.py", line 173, in
plot_angles
 colorbar(p)
 File "/usr/lib/pymodules/python2.6/matplotlib/pyplot.py", line 1367, in
colorbar
 ax = gca()
 File "/usr/lib/pymodules/python2.6/matplotlib/pyplot.py", line 582, in gca
 ax = gcf().gca(**kwargs)
 File "/usr/lib/pymodules/python2.6/matplotlib/pyplot.py", line 276, in gcf
 return figure()
 File "/usr/lib/pymodules/python2.6/matplotlib/pyplot.py", line 254, in
figure
 **kwargs)
 File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_tkagg.py",
line 91, in new_figure_manager
 canvas = FigureCanvasTkAgg(figure, master=window)
 File "/usr/lib/pymodules/python2.6/matplotlib/backends/backend_tkagg.py",
line 159, in __init__
 self._tkcanvas.create_image(w/2, h/2, image=self._tkphoto)
 File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 2159, in create_image
 return self._create('image', args, kw)
 File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 2150, in _create
 *(args + self._options(cnf, kw))))
_tkinter.TclError: bad screen distance "320.0"
On Sun, Jan 3, 2010 at 1:07 PM, John Hunter <jd...@gm...> wrote:
> On Sun, Jan 3, 2010 at 11:34 AM, Alexander Hupfer <so...@gm...>
> wrote:
> > Hi, I have a scatter plot embedded in qt4 according to
> >
> http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_qt4.html
> > what works fine
> > However if I try to add a colorbar to it by simply calling
> >
> > p = scatter(....)
> > colorbar(p)
> >
> > I get an error that says that something is outside the drawable area.
>
> Please post example code which replicates the problem and a full
> traceback. From the snippet you posted, it looks like you may be
> using the pylab/pyplot interface which is not consistent with
> embedding mpl in qt or any other widget set. Rather, you need to be
> using the mpl API.
>
> JDH
>

thanks very much. Using expand_subplot for that purpose worked great,
but I am now trying a variant of this and am having trouble getting it
to work.
I'd like to create a subplot that has two parts: the left part is a
square plot, and the right part is a 2x2 set of square subplots.
Something like this:
http://www.mathworks.com/access/helpdesk_archive_ja_JP/r2007/help/toolbox/matlab/ref/image/subplot_vert.gif
Except the left hand plot should have square axes. just imagine
taking a square plot and putting it on the left, and then making a 2x2
subplot, which each subplot is less than 1/4 the size of the square
plot on the left, and putting that on the right hand panel.
is there a way to do this in matplotlib?
thanks.
On Sat, Dec 26, 2009 at 10:55 PM, Jae-Joon Lee <lee...@gm...> wrote:
> On Thu, Dec 24, 2009 at 3:53 PM, per freem <per...@gm...> wrote:
>> i want it to eliminate the second
>> subplot of the first row and instead make the first subplot on the
>> first row take up two plots worth of space,
>
> Matpltlib's subplot does not support it as of now.
>
> There a few work around you may try, but it will at least take a few
> tens of lines of code. Attached is a way to do this by patching the
> object method, which I personally do not prefer but may be one of the
> easiest for normal users.
>
> Also, there is a patch I once worked on, but haven't pushed into the
> svn yet (i'm not sure if I ever will). So give it a try if you want.
>
> http://article.gmane.org/gmane.comp.python.matplotlib.general/19097
>
> Regards,
>
> -JJ
>
>
> import matplotlib.transforms as mtransforms
>
> def expand_subplot(ax, num2):
>  update_params_orig = ax.update_params
>
>  ax._num2 = num2 - 1
>  def _f(self=ax):
>    num_orig = self._num
>
>    self._num = self._num2
>    update_params_orig()
>    right, top = self.figbox.extents[2:]
>
>    self._num = num_orig
>    update_params_orig()
>    left, bottom = self.figbox.extents[:2]
>
>    self.figbox = mtransforms.Bbox.from_extents(left, bottom,
>                          right, top)
>
>  ax.update_params = _f
>  ax.update_params()
>  ax.set_position(ax.figbox)
>
>
> ax = subplot(231)
> expand_subplot(ax, 2)
>

On Sun, Jan 3, 2010 at 2:50 PM, Eric Firing <ef...@ha...> wrote:
> I think that allowing display units would be easy to implement (as indicated
> by Ryan's example), but font or physical units would be much trickier
> because they would involve draw-time determinations. Starting by allowing
> only display units still would be much better than the present situation.
>
> Collections already have something like this, with their offset and
> offset_transform kwargs, but they are still a little more difficult to use
> than what I am thinking of for text.
This would be a nice feature, but a little tricky to do generally
since the text objects are already so complicated ... I mean feature
rich.
One could simply do a draw time offset and convert points->pixels (eg
as in Annotation) but to get everything to play consistently with
annotations, arrows, fancy boxes, etc, would require some care and
thought.
JDH

John Hunter wrote:
> On Sun, Jan 3, 2010 at 10:22 AM, Ryan May <rm...@gm...> wrote:
>>> the marker. It would be great if one could specify the text offsets in
>>> units of the font size rather than in units of map distance.
>> You can do it, it just takes a bit of knowledge about how different
>> transformations are used under the hood:
> 
> See also, the transforms tutorial:
> 
> http://matplotlib.sourceforge.net/users/transforms_tutorial.html
> 
> Offset transformations are discussed at:
> 
> http://matplotlib.sourceforge.net/users/transforms_tutorial.html#using-offset-transforms-to-create-a-shadow-effect
> 
> though in a different context, that of creating shadow effects. The
> transformation logic is the same as in this case, though.
The case of wanting to offset text by an amount measured ideally in 
units of font size, or, failing that, in display units, is so common 
that it cries out for an easy-to-use syntax. e.g.,
text(x, y, "Honolulu", offset = (1, 1), offset_units='ex')
I think that allowing display units would be easy to implement (as 
indicated by Ryan's example), but font or physical units would be much 
trickier because they would involve draw-time determinations. Starting 
by allowing only display units still would be much better than the 
present situation.
Collections already have something like this, with their offset and 
offset_transform kwargs, but they are still a little more difficult to 
use than what I am thinking of for text.
Eric

On Sun, Jan 3, 2010 at 11:34 AM, Alexander Hupfer <so...@gm...> wrote:
> Hi, I have a scatter plot embedded in qt4 according to
> http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_qt4.html
> what works fine
> However if I try to add a colorbar to it by simply calling
>
> p = scatter(....)
> colorbar(p)
>
> I get an error that says that something is outside the drawable area.
Please post example code which replicates the problem and a full
traceback. From the snippet you posted, it looks like you may be
using the pylab/pyplot interface which is not consistent with
embedding mpl in qt or any other widget set. Rather, you need to be
using the mpl API.
JDH

On Sun, Jan 3, 2010 at 10:22 AM, Ryan May <rm...@gm...> wrote:
>> the marker. It would be great if one could specify the text offsets in
>> units of the font size rather than in units of map distance.
>
> You can do it, it just takes a bit of knowledge about how different
> transformations are used under the hood:
See also, the transforms tutorial:
 http://matplotlib.sourceforge.net/users/transforms_tutorial.html
Offset transformations are discussed at:
 http://matplotlib.sourceforge.net/users/transforms_tutorial.html#using-offset-transforms-to-create-a-shadow-effect
though in a different context, that of creating shadow effects. The
transformation logic is the same as in this case, though.
JDH

Hi, I have a scatter plot embedded in qt4 according to
http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_qt4.htmlwhat
works fine
However if I try to add a colorbar to it by simply calling
p = scatter(....)
colorbar(p)
I get an error that says that something is outside the drawable area.
- sonium

> Jouni K. Sepp?nen wrote:
> 
>> Jordan Dawe <jd...@eo...> writes:
>>
>> 
>>> Contourf plots that I output in vector format files have little
>>> triangular glitches at the contour boundaries if the contoured array
>>> is larger than about 200x200. The same files in png format are
>>> perfect, even at very high dpi values.
>>> 
>> The current svn trunk doesn't have the really jarring little triangles
>> (at least in the pdf output), but there are still several very obtuse
>> white triangles between the regions. Rasterization at a high dpi makes
>> the output somewhat better at the cost of larger output files:
>>
>> c=contourf(X, Y, Z, 10)
>> axis((-3, 3, -3, 3))
>> savefig('unrasterized.pdf')
>> for d in c.collections:
>> d.set_rasterized(True)
>> savefig('rasterized.pdf',dpi=200)
>> 
>
>
> At least in the trunk--and maybe in 0.99.0--the problem is caused by 
> path simplification. In the trunk, for the eps file, it goes away 
> completely if I use a matplotlibrc with
>
> path.simplify : False
>
> In the trunk, what seems to be happening is that when a contour boundary 
> is almost straight, but has an inflection point, the curves for the 
> adjacent patch boundaries are simplified slightly differently. This is 
> not surprising; if nothing else, the path will be traveled in a 
> different direction when it is an outer boundary than when it is an 
> inner boundary (for a set of concentric boundaries).
>
> Jordan, try using a local matplotlibrc with the above. Unless you are 
> already customizing via a local matplotlibrc, that line is all you need.
>
> One reason the trunk behavior differs from 0.99.0 is that contour patch 
> boundaries are now being turned into compound boundaries instead of 
> using a branch cut to connect the outside path to the inside path. I 
> suspect simplification is causing the artifacts in both cases, though.
>
> Eric
>
>
> 
Perfect, that fixed it completely. Thanks.
Jordan

On Sun, Jan 3, 2010 at 1:02 AM, Phillip M. Feldman <pfe...@ve...> wrote:
> Ah. It sounds as though one must consider the scale of the map, and
> then choose these offsets so that the text falls near but not too near
> the marker. It would be great if one could specify the text offsets in
> units of the font size rather than in units of map distance.
You can do it, it just takes a bit of knowledge about how different
transformations are used under the hood:
import matplotlib.transforms as mtransforms
import matplotlib.pyplot as plt
# Basic plot of single point. Adjust limits to give space
x0,y0 = 4,5
plt.plot(x0, y0, 'o')
plt.ylim(-10, 20)
plt.xlim(0, 15)
# Grab axes object so we can get the tranformation used to
# transform data points into axes coords
ax = plt.gca()
# Create a transform that moves to the data point and then
# adds an offset of 10 up (I'm not sure if it's points or pixels)
# Transforms can be combined using just the simple '+'
trans = ax.transData + mtransforms.Affine2D().translate(0, 10)
plt.text(x0, y0, 'Testing', horizontalalignment='center',
 verticalalignment='center', transform=trans, clip_on=True)
# Now do one 15 right
trans2 = ax.transData + mtransforms.Affine2D().translate(15, 0)
plt.text(x0, y0, 'Testing2', horizontalalignment='left',
 verticalalignment='center', transform=trans2, clip_on=True)
plt.show()
I hope this helps. Let me know if anything is unclear.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ah. It sounds as though one must consider the scale of the map, and 
then choose these offsets so that the text falls near but not too near 
the marker. It would be great if one could specify the text offsets in 
units of the font size rather than in units of map distance.
Thanks!
Phillip
Eric Firing wrote:
> Dr. Phillip M. Feldman wrote:
>> The online documentation at URL=
>> http://www.scipy.org/Cookbook/Matplotlib/Maps has an example that uses
>> plt.text as follows:
>>
>> plt.text(xpt+50000,ypt+50000,name)
>>
>> Why is the offset 50000?
>
> The proj library used by Basemap transforms lon, lat to meters, so xpt 
> and ypt are in meters. Hence the offsets are 50 km. Now, what I 
> don't understand is why the San Diego offset on the map looks so much 
> larger than the Boulder offset, for example.
>
> Eric
>

Dr. Phillip M. Feldman wrote:
> The online documentation at URL=
> http://www.scipy.org/Cookbook/Matplotlib/Maps has an example that uses
> plt.text as follows:
> 
> plt.text(xpt+50000,ypt+50000,name)
> 
> Why is the offset 50000?
The proj library used by Basemap transforms lon, lat to meters, so xpt 
and ypt are in meters. Hence the offsets are 50 km. Now, what I don't 
understand is why the San Diego offset on the map looks so much larger 
than the Boulder offset, for example.
Eric

The online documentation at URL=
http://www.scipy.org/Cookbook/Matplotlib/Maps has an example that uses
plt.text as follows:
plt.text(xpt+50000,ypt+50000,name)
Why is the offset 50000?
-- 
View this message in context: http://old.nabble.com/query-about-pyplot.text-example-tp26999119p26999119.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

AlanIsaac wrote:
> 
> http://matplotlib.sourceforge.net/faq/howto_faq.html#use-show
> 
> 
Thanks. Obviously, I did not do a good enough job reading the faq...
-- 
View this message in context: http://old.nabble.com/Problem-with-multiple-plots-tp26976541p26998858.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

http://matplotlib.sourceforge.net/faq/howto_faq.html#use-show

Jouni K. Seppänen wrote:
> Jordan Dawe <jd...@eo...> writes:
> 
>> Contourf plots that I output in vector format files have little
>> triangular glitches at the contour boundaries if the contoured array
>> is larger than about 200x200. The same files in png format are
>> perfect, even at very high dpi values.
> 
> The current svn trunk doesn't have the really jarring little triangles
> (at least in the pdf output), but there are still several very obtuse
> white triangles between the regions. Rasterization at a high dpi makes
> the output somewhat better at the cost of larger output files:
> 
> c=contourf(X, Y, Z, 10)
> axis((-3, 3, -3, 3))
> savefig('unrasterized.pdf')
> for d in c.collections:
> d.set_rasterized(True)
> savefig('rasterized.pdf',dpi=200)
At least in the trunk--and maybe in 0.99.0--the problem is caused by 
path simplification. In the trunk, for the eps file, it goes away 
completely if I use a matplotlibrc with
path.simplify : False
In the trunk, what seems to be happening is that when a contour boundary 
is almost straight, but has an inflection point, the curves for the 
adjacent patch boundaries are simplified slightly differently. This is 
not surprising; if nothing else, the path will be traveled in a 
different direction when it is an outer boundary than when it is an 
inner boundary (for a set of concentric boundaries).
Jordan, try using a local matplotlibrc with the above. Unless you are 
already customizing via a local matplotlibrc, that line is all you need.
One reason the trunk behavior differs from 0.99.0 is that contour patch 
boundaries are now being turned into compound boundaries instead of 
using a branch cut to connect the outside path to the inside path. I 
suspect simplification is causing the artifacts in both cases, though.
Eric