matplotlib-users Mailing List for matplotlib

On 8/20/12 4:41 PM, Scott Henderson wrote:
> I'm having trouble with transform_scalar() and imshow() with basemap. 
> Essential I have data from satellite tracks that are either smaller or 
> larger than the map extent, so I don't want to use Basemap.imshow() 
> which sets the 'extent' keyword automatically.
>
> I tried following the following suggestion, but I can't get things to 
> line up..
> http://comments.gmane.org/gmane.comp.python.matplotlib.general/25085
>
> I suspect I've done something wrong in the code below?:
Scott: If you use the pcolormesh or contourf Basemap methods (instead 
of imshow), you can specify the map projection coordinates of your data 
and it will be plotted correctly (whether or not it covers the whole map 
projection region).
-Jeff
>
>
> # -------------------------------
> from mpl_toolkits.basemap import Basemap
> import matplotlib.pyplot as plt
>
> LL = (-68, -26)
> UR = (-66, -21)
> bmap = Basemap(projection='merc',
> llcrnrlat=LL[1],
> urcrnrlat=UR[1],
> llcrnrlon=LL[0],
> urcrnrlon=UR[0],
> resolution='i',
> suppress_ticks=False,
> ax=ax)
> bmap.drawcountries(linewidth=1)
>
> # Overlay image with extents that don't match map boundaries
> nLon, nLat = image.shape
> LL = (-69.915, -31.161)
> UR = (-65.075, -17.334)
> dy = -0.006666664
> lats = UR[1] + dy * np.arange(nLat)
> extent = (LL[0], UR[0], LL[1], UR[1])
> nx = nLon; ny = nLat
> image_xy = bmap.transform_scalar(image, lons, lats[::-1], nx, ny)
> x, y = bmap(extent[:2],extent[2:])
> extent_xy = (x[0], x[1], y[0], y[1])
> im = plt.imshow(image_xy, extent=extent_xy)
>
>
>
> -- 
> ---------------
> Scott T. Henderson
> http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
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-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

I have been generating boxplots with matplotlib 1.1.0 and the plots look 
great.
How can I find the median, fliers, etc. that are used for the boxplots? 
In general, where can I find documentation on how to get these data from 
a boxplot?
Best regards!
[Using matplotlib 1.1.0 with Python 2.7.3 on a Windows Vista 32-bit 
platform]

I'm having trouble with transform_scalar() and imshow() with basemap. 
Essential I have data from satellite tracks that are either smaller or 
larger than the map extent, so I don't want to use Basemap.imshow() 
which sets the 'extent' keyword automatically.
I tried following the following suggestion, but I can't get things to 
line up..
http://comments.gmane.org/gmane.comp.python.matplotlib.general/25085
I suspect I've done something wrong in the code below?:
# -------------------------------
from mpl_toolkits.basemap import Basemap
import matplotlib.pyplot as plt
LL = (-68, -26)
UR = (-66, -21)
bmap = Basemap(projection='merc',
 llcrnrlat=LL[1],
 urcrnrlat=UR[1],
 llcrnrlon=LL[0],
 urcrnrlon=UR[0],
 resolution='i',
 suppress_ticks=False,
 ax=ax)
bmap.drawcountries(linewidth=1)
# Overlay image with extents that don't match map boundaries
nLon, nLat = image.shape
LL = (-69.915, -31.161)
UR = (-65.075, -17.334)
dy = -0.006666664
lats = UR[1] + dy * np.arange(nLat)
extent = (LL[0], UR[0], LL[1], UR[1])
nx = nLon; ny = nLat
image_xy = bmap.transform_scalar(image, lons, lats[::-1], nx, ny)
x, y = bmap(extent[:2],extent[2:])
extent_xy = (x[0], x[1], y[0], y[1])
im = plt.imshow(image_xy, extent=extent_xy)
-- 
---------------
Scott T. Henderson
http://www.geo.cornell.edu/eas/gstudent/sth54/contact.html

Thanks for this. It's been a long-standing bug that text is handled by 
bounding box, but it's been difficult to find a way forward without 
breaking backward compatibility.
I've filed an issue for this here.
https://github.com/matplotlib/matplotlib/issues/1121
It may be, in the long run, that we want to fix the other backends to 
use baselines rather than fixing Cairo to use bounding boxes.
Mike
On 08/20/2012 01:07 PM, Freddie Witherden wrote:
> On 19/08/12 23:48, Freddie Witherden wrote:
>> Hello,
>>
>> Using the Cairo backend with the following snippet:
>>
>> from matplotlib.figure import Figure
>> from matplotlib.artist import setp
>> from matplotlib.backends.backend_agg import FigureCanvasAgg
>> from matplotlib.backends.backend_cairo import FigureCanvasCairo
>> import numpy as np
>>
>> fig = Figure()
>> ax1 = fig.add_axes([0.1, 0.1, 0.8, 0.8])
>> x = np.arange(0, 10, 0.2)
>>
>> ax1.plot(x, np.sin(x))
>> ax1.xaxis.set_ticklabels(['Apr', 'Jul', 'Oct', '\'12', 'Apr', 'Jul'])
>> setp(ax1.yaxis.get_ticklabels(), visible=False)
>>
>> FigureCanvasCairo(fig).print_figure('test.png')
>>
>>
>> Results in the x-axis tick labels being significantly displaced.
>> Specifically, "Oct" and "'12" are positioned far closer to the axis than
>> either "Apr" or "Jul".
>>
>> With the AGG backend all of the labels are roughly aligned to the
>> baseline of the font -- give or take a pixel.
>>
>> I have observed this on a Gentoo and Debian system, both running 1.1.1,
>> albeit with different default fonts.
>>
>> Although I am not completely sure it appears as if a label contains a
>> glyph that extends below the baseline, e.g. 'p' or 'J', that the label
>> is forced away from the axis.
>>
>> Can anyone suggest a workaround for this (or explain where I am going
>> wrong)?
> I have been looking into this issue today and it /appears/ to be because
> the Cairo backend -- or more precisely -- cairo::show_text method takes
> a y-coordinate relative to the baseline. This makes sense given that
> the descent of a font is a well-defined concept in Cairo (and can be
> extracted via the font_extents method). However, as far as I can tell,
> matplotlib expects the draw_text method to provide an absolute y-coordinate.
>
> The result is that any text with a descender is pushed downwards
> (assuming a default rotation angle). This can be visualized by
>
> setp(ax1.xaxis.get_ticklabels(), backgroundcolor='r')
>
> The solution is to have the draw_text method account for any descenders.
> After a bit of juggling the relevant portion of draw_text becomes:
>
> ctx = gc.ctx
> ctx.new_path()
> #ctx.move_to (x, y)
> ctx.select_font_face (prop.get_name(),
> self.fontangles [prop.get_style()],
> self.fontweights[prop.get_weight()])
>
> size = prop.get_size_in_points() * self.dpi / 72.0
> ctx.set_font_size(size)
>
> y_bearing, w, h = ctx.text_extents(s.encode("utf-8"))[1:4]
> ctx.move_to(x, y - (h + y_bearing))
>
> ctx.save()
> if angle:
> ctx.rotate (-angle * np.pi / 180)
> #ctx.set_font_size (size)
> ctx.show_text (s.encode("utf-8"))
> ctx.restore()
>
> where commented lines highlight modifications (specifically, the
> movement of the set_font_size and move_to calls). In my limited testing
> this fixes the aforementioned issues. Discrepancies between baselines
> are now limited to +/- 1px (the same as with the AGG backend).
> Eliminating these one pixel misalignments is rather difficult so long as
> text rendering is performed relative to the bounding box as opposed to a
> baseline.
>
> Regards, Freddie.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On 19/08/12 23:48, Freddie Witherden wrote:
> Hello,
> 
> Using the Cairo backend with the following snippet:
> 
> from matplotlib.figure import Figure
> from matplotlib.artist import setp
> from matplotlib.backends.backend_agg import FigureCanvasAgg
> from matplotlib.backends.backend_cairo import FigureCanvasCairo
> import numpy as np
> 
> fig = Figure()
> ax1 = fig.add_axes([0.1, 0.1, 0.8, 0.8])
> x = np.arange(0, 10, 0.2)
> 
> ax1.plot(x, np.sin(x))
> ax1.xaxis.set_ticklabels(['Apr', 'Jul', 'Oct', '\'12', 'Apr', 'Jul'])
> setp(ax1.yaxis.get_ticklabels(), visible=False)
> 
> FigureCanvasCairo(fig).print_figure('test.png')
> 
> 
> Results in the x-axis tick labels being significantly displaced.
> Specifically, "Oct" and "'12" are positioned far closer to the axis than
> either "Apr" or "Jul".
> 
> With the AGG backend all of the labels are roughly aligned to the
> baseline of the font -- give or take a pixel.
> 
> I have observed this on a Gentoo and Debian system, both running 1.1.1,
> albeit with different default fonts.
> 
> Although I am not completely sure it appears as if a label contains a
> glyph that extends below the baseline, e.g. 'p' or 'J', that the label
> is forced away from the axis.
> 
> Can anyone suggest a workaround for this (or explain where I am going
> wrong)?
I have been looking into this issue today and it /appears/ to be because
the Cairo backend -- or more precisely -- cairo::show_text method takes
a y-coordinate relative to the baseline. This makes sense given that
the descent of a font is a well-defined concept in Cairo (and can be
extracted via the font_extents method). However, as far as I can tell,
matplotlib expects the draw_text method to provide an absolute y-coordinate.
The result is that any text with a descender is pushed downwards
(assuming a default rotation angle). This can be visualized by
setp(ax1.xaxis.get_ticklabels(), backgroundcolor='r')
The solution is to have the draw_text method account for any descenders.
 After a bit of juggling the relevant portion of draw_text becomes:
 ctx = gc.ctx
 ctx.new_path()
 #ctx.move_to (x, y)
 ctx.select_font_face (prop.get_name(),
 self.fontangles [prop.get_style()],
 self.fontweights[prop.get_weight()])
 size = prop.get_size_in_points() * self.dpi / 72.0
 ctx.set_font_size(size)
 y_bearing, w, h = ctx.text_extents(s.encode("utf-8"))[1:4]
 ctx.move_to(x, y - (h + y_bearing))
 ctx.save()
 if angle:
 ctx.rotate (-angle * np.pi / 180)
 #ctx.set_font_size (size)
 ctx.show_text (s.encode("utf-8"))
 ctx.restore()
where commented lines highlight modifications (specifically, the
movement of the set_font_size and move_to calls). In my limited testing
this fixes the aforementioned issues. Discrepancies between baselines
are now limited to +/- 1px (the same as with the AGG backend).
Eliminating these one pixel misalignments is rather difficult so long as
text rendering is performed relative to the bounding box as opposed to a
baseline.
Regards, Freddie.

<html style="direction: ltr;">
 <head>
 <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
 <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
 </head>
 <body style="direction: ltr;"
 bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
 text="#000000">
 <pre wrap="">Hello
I have set rcParams['axes.color_cycle'] = ['r','Blue',&nbsp;&nbsp;&nbsp; 'g', 'm','c','k',&nbsp;&nbsp;&nbsp; 'Tomato... ] to a long list of colors.
Later in the program I have many figure() commands floowed by plot commands.
The color sequence does not repateat itself for each new figure
How do I reset the sequence?
Thanks
Ilan</pre>
 </body>
</html>

Thank you for your help, but I have already read this link.
I am using zoomed_inset_axes, but the default position overlaps the yticks
and the parent axe ticks, so I am trying:
axins = zoomed_inset_axes(ax,
3,bbox_to_anchor(0.5,1),bbox_transform=ax.figure.transFigure, loc=2)
but it doesn't work.
I have also tried:
box = axins.get_position()
axins.set_position([box.x0+0.5, box.y0,box.width, box.height])
and the position is changed (doing a print I check the differences), but
not in the plot.
I guess I am doing something wrong, but I can't tell.
Any help would be really useful.
Cheers!
Illa
2012年8月9日 Benjamin Root <ben...@ou...>
>
> On Wed, Aug 8, 2012 at 7:03 AM, darkside <in....@gm...>wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: darkside <in....@gm...>
>> Date: 2012年8月2日
>> Subject: Re: [Matplotlib-users] zoomed in detail box
>> To: Jae-Joon Lee <lee...@gm...>
>>
>>
>> Hi everyone!
>>
>> I'm also trying to do a detailed zoomed area of my plot, but I can't
>> manage to put the box in the position I want, bbox_to_anchor didn't work in
>> my case:
>>
>> axins =
>> zoomed_inset_axes(ax,3,loc=2,bbox_to_anchor=(0,0,0.5,0.5),bbox_transform=ax.transAxes)
>>
>> This bbox_to_anchor tuple is just an example. I only want to move the
>> zoomed box a little to the right, since the ticklabels overlap.
>>
>> Any idea?
>>
>> I really appreciate your help!
>>
>>
> Is this what you are looking for?
>
>
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#insetlocator
>
> Cheers!
> Ben Root
>
>

I've filed an issue for this here:
https://github.com/matplotlib/matplotlib/issues/1110
Mike
On 08/19/2012 05:55 PM, Eric Firing wrote:
> On 2012年08月19日 10:31 AM, Christopher Graves wrote:
>> Hi
>>
>>
>> I do not think this is the expected behavior. First, run the following:
>>
>>
>> from pylab import *
>>
>> plot([0,3],[0.2,0.7])
>>
>> ax1 = gca()
>>
>> ax1.set_yscale('log')
>>
>> gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$'))
>>
>> #ax2 = ax1.twiny()
>>
>> #ax2.set_xlim(ax1.get_xlim())
>>
>> show()
>>
>>
>> You will see that the y-axis is log10rithmic and axis labels are 0.1 and
>> 1 rather than 10^-1 and 10^0, due to the use of set_major_formatter().
>>
>>
>> Now uncomment the 2 commented lines and run it again. It seems that upon
>> applying a twiny(), the set_major_formatter() action is removed and the
>> y-axis is now displayed as 10^-1 and 10^0. Or more likely, the y-axis is
>> "overwritten" with a new y-axis present in ax2. One can add another
>> gca().yaxis.set_major_formatter(FormatStrFormatter('$%g$')) before the
>> show() and it works as intended. However, it seems like unexpected
>> behavior to "lose" the formatting when twinning the axis to add a
>> secondary x-axis. Any advice or agreement that this could be a bug?
> Yes, I think this is a bug.
>
> Eric
>
>>
>> Best,
>>
>> Chris
>>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users