matplotlib-devel Mailing List for matplotlib (Page 2)

On Thu, Jul 24, 2008 at 10:00 PM, Ryan May <rm...@gm...> wrote:

> What else is confusing is how that relates to DPI.  When I change the
> figure's dpi, using set_dpi, (and redraw), I get physically *bigger* barbs.
>  To me, if I'm actually specifying pixels, there's no way that they should
> get bigger when I change the DPI.

When you increase the dpi, the canvas gets bigger (inches*dpi equals
canvas size in pixels).  If you are drawing in pixels, and not
scaling, the barbs should look smaller, since they are a smaller
proportion of the canvas size.  So if this explanation is right, the
barbs will look smaller with larger dpi.

> Then I also can't figure out what the PS backend is doing.  If PS is
> hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect?

ps should be unaffected, but dpi dependent backends will.  By setting
the dpi to be 72, it should make the *other* backend look like the ps
backend and the ps backend should be unaffected.

JDH

Eric Firing wrote:
> John Hunter wrote:
>> On Wed, Jul 23, 2008 at 10:05 PM, Ryan May <rm...@gm...> wrote:
>>
>>> <grumble> Ok, it fixes the problem if I pass dpi=72 to savefig(). 
>>> Curiously,
>>> passing dpi=72 to Figure() does not have the same effect.  So now how 
>>> do I
>>
>> That is because "savefig" has its own dpi, which overrides the figure
>> dpi.  Tee ideas is that you typically want a different dpi for the UI
>> window and for the harcopy
>>
>>> fix it?  I'm really not sure what's going wrong here.  If I had to 
>>> guess,
>>> it's a problem between figure size being in inches while I'm drawing in
>>> pixels (still don't know how that works, because there's no way those 
>>> barbs
>>> are 9 pixels long).
>>
>> I'm not familiar enough with the windbarb code to know where the "9
>> pixel" thing that is bothering you is creeping in, I'm just saying
>> that using an identity transform means you are drawing in canvas
>> (pixel) space and not accounting for dpi.  The Figure instance has a
>> "dpi_scale_transform" that is designed to handle dpi scaling, and
>> updates itself when the figure dpi is changed so you don't have to
>> handle the callbacks.  Take a look at this and see if you can
>> incorporate it.  If you have troubles, Michael or I can advise
>> further.
>>
>> If you clarify the "9 pixel" problem that is bothering you, I may be
>> able to help more sooner...
> 
> Part of the problem is the horrible and misleading sizes arg in 
> PolyCollections, probably a hangover (yes, a headache) from supporting a 
> Matlab-compatible argument in scatter.  I can try to straighten this out 
> and clarify the situation after the release, not before.  I will add an 
> alternative kwarg to scatter at the same time, and hope the old usage 
> gradually dies out.

That might be part of it, I'm not sure.  My problem is that I have 
length set to 7 in the code.  That implies that when I draw, the 
distance along the y-axis between where I start and where I end is 7 
units (which is then rotated).  What gets shown on my screen (when the 
BarbCollection transform is set to IdentityTransform()) is not possibly 
7 pixels long.  My gnome-panel bar is 22 pixels high, and that looks 
like a pretty good fit to how long things are actually in the figure I 
see on screen.  This is at my default figure dpi of 72.

What else is confusing is how that relates to DPI.  When I change the 
figure's dpi, using set_dpi, (and redraw), I get physically *bigger* 
barbs.  To me, if I'm actually specifying pixels, there's no way that 
they should get bigger when I change the DPI.

Then I also can't figure out what the PS backend is doing.  If PS is 
hardcoded to 72 DPI, why does passing dpi=72 to savefig() have any effect?

I found the fig.dpi_scale_trans.  However, this then makes things too 
big on the on screen figure when I use this as the tranform for the 
BarbCollection.

Thoughts?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,

This is probably best directed to Eric, but to anyone who knows how 
quiver works with regard to units: QuiverKey right now is failing if 
coordinates="inches".  There are a couple of non-defined variables 
accesses in there, and it just doesn't look right.  The offending part 
of the if chain starts at line 292 of quiver.py.  I'm not familiar 
enough with how this code works to try and fix it.  None of the example 
code seems to exercise the coordinates parameter of quiverkey, just the 
units parameter for quiver.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric Firing wrote:
>> Anyone have any ideas?
> 
> I don't, but it appears that the set_clip_path method was introduced in 
> 4817 by Mike D., complete with the commented-out lines.
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 

Uncommenting them doesn't seem to break anything and it solves my 
problem as well.  I guess there could be performance impacts so I'll 
wait for Mike to weigh in.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

David Kaplan wrote:
>> * Using an empty list in a python kwarg as the default is a gotcha, as in
>>
>>     def calc_label_rot_and_inline( self, slc, ind, lw, lc=[], spacing=5 ):
>>
>> The reason is that if the function mutates the list, this often leads
>> to unintended consequences as the list is module level and thus shared
>> between instances and method calls.  The standard idiom for mutable
>> (lists and dicts) keyword args s
>>
>>     def func(x=None):
>>         if x is None: x = []
>>
>> I have fixed this in contour.py
>>
> 
> I don't really understand how this can be a problem, but it probably
> isn't that important unless you feel like enlightening me.

The default value for the function is created when the interpreter 
executes the define statement.  Thus, if you were to do something that 
modifies the list inplace, like append(), the default argument will 
retain those changes.  For instance, try this:

def foo(l=[]):
     l.append('foo')
     print l
foo()
foo()
foo(['bar'])
foo()

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Thu, Jul 24, 2008 at 12:25 PM, Paul Kienzle <pki...@ni...> wrote:

>  canvas interface for interactive plotting applications

The Chaco devs (in particular Peter Wang) will be there, so it would
be worthwhile having a detailed conversation with him on this matter,
as this is definitely Chaco's strong suit and I'm sure he'd have a lot
of good ideas on the matter.  Who knows, we might even inch a bit
closer towards that mythical mpl/chaco unification :)

Cheers,

f

Paul Kienzle wrote:
> Hi,
> 
> I added support for scroll wheel events in wx.  This includes
> a new attribute event.step since the wx mouse wheel event
> reports larger steps when scrolling faster.  I don't see
> how to check step in gtk, so I set step to +1 and -1 for up 
> and down.
> 
> Can someone with gtk please run the following to make sure
> I didn't break anything:
> 
>     examples/pylab_examples/image_slices_viewer.py
> 
> 

Works for me.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Paul Kienzle wrote:
> Hello,
> 
> Anyone planning to attend post-SciPy2008 code sprints?
> 
> Some projects I'm interested in:
> 
>   support for units (px, pt/in/cm/mm, em/ex/<font height>, %axis/%figure)
>   style sheet editor (needs backend support for forms and menus)
>   canvas interface for interactive plotting applications
> 
> - Paul

I'll be there the whole week, Monday-Sunday.  I'm good to help out where 
I can.  My personal goal is to get some work on OpenGL going, but that's 
less sprinty and more by myself kind of stuff (unless someone else is 
interested).

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric Firing wrote:
> Ryan May wrote:
>> Hey,
>>
>> I noticed today, while working on my skewT, that you can't tell the 
>> axis objects to clip their ticklines. If you want to set clipping on 
>> each individual tickline.  I saw that the code is there in the 
>> relevant classes, but the lines to set clipping are disabled in 
>> set_clip_path() or _set_artist_props().  My SVN foo is failing me 
>> right now, so I can't find anything to tell me why these changes were 
>> made.
> 
> Does this link work for you?  (Sometimes sourceforge is painfully slow, 
> sometimes bits of it seem to simply go away.)
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/ 
> 
> 
> I find the browser view quite helpful for finding out which changes were 
> made when, and by whom.  To find out why, one must often ask or go to 
> the mailing list archive.

Typical.  I find it quite useful too, which is why I tried going there 
earlier today.  SF had turned off Viewvc due to the server load it was 
causing.  Now of course when you go to it, it's on.... :)

>> Anyone have any ideas?
> 
> I don't, but it appears that the set_clip_path method was introduced in 
> 4817 by Mike D., complete with the commented-out lines.
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651 
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817 

Alright.  Mike?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Hey,
> 
> I noticed today, while working on my skewT, that you can't tell the axis 
> objects to clip their ticklines. If you want to set clipping on each 
> individual tickline.  I saw that the code is there in the relevant 
> classes, but the lines to set clipping are disabled in set_clip_path() 
> or _set_artist_props().  My SVN foo is failing me right now, so I can't 
> find anything to tell me why these changes were made.

Does this link work for you?  (Sometimes sourceforge is painfully slow, 
sometimes bits of it seem to simply go away.)

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/

I find the browser view quite helpful for finding out which changes were 
made when, and by whom.  To find out why, one must often ask or go to 
the mailing list archive.


> 
> Anyone have any ideas?

I don't, but it appears that the set_clip_path method was introduced in 
4817 by Mike D., complete with the commented-out lines.
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?annotate=5651
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/lib/matplotlib/axis.py?view=diff&r1=4816&r2=4817
> 
> Ryan
> 

Hey,

I noticed today, while working on my skewT, that you can't tell the axis 
objects to clip their ticklines. If you want to set clipping on each 
individual tickline.  I saw that the code is there in the relevant 
classes, but the lines to set clipping are disabled in set_clip_path() 
or _set_artist_props().  My SVN foo is failing me right now, so I can't 
find anything to tell me why these changes were made.

Anyone have any ideas?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma