matplotlib-devel Mailing List for matplotlib

Ryan May wrote:
> Hi,
> 
> I'll continue my current flood of emails to the list. :)  I'm finally 
> getting back to my work on Skew-T plots, and I have a semi-working 
> implementation (attached.)  It runs, and as is, plots up some of the 
> grid, with the x-value grid lines skewed 45 degrees to the right (as 
> they should be.)  The problem is as you resize the plot horizontally, 
> some weird things happen.  First, some of the lines that start overlaid 
> end up separating as you expand the plot.  The difference is between 
> what is added using ax.plot and what is added using ax.vlines.  The 
> former adds Line2D objects while the latter adds a LineCollection which 
> is holding path objects.  I'm really not sure what's going on there. I'm 
> not done checking it out yet, but I'm curious if anyone has any ideas 
> off the top of their head.
> 
> The second issue, which is more pressing, is when you resize vertically, 
> the axes limits of the plot don't change (good), but unfortunately the 
> lines don't stay connected to their lower y-coordinate in data space 
> (bad).  I'm really needing to draw things in a coordinate system that's 
> independant of the data scale but also doesn't depend on the aspect 
> ratio of the axes, so that I can get lines (and data plots) where the x 
> gridlines are always at a 45 degree angle and the lower Y-value point 
> stays fixed.  By problem right now is that while I can find the lower 
> left corner in pixel space and use that to do the proper adjustments, 
> this changes when you resize.  This changing is especially important in 
> the y-direction.  What I need is either of:
> 
>     1) Axes space adjusted for aspect ratio (and updated with resizes)
>     2) Pixel space relative to some corner of the axes
> 
> Or something similar that I don't know about.  Any thoughts, or do I 
> just need to come up with some magical combination of transforms that 
> works?  You can see what I have so far in my attached file.
> 

Ryan, based only on your description of the problems, and of what you 
need, I think the answer, or at least part of it, may be in good old 
quiver.  Look at the way the transform is being generated depending on 
the units chosen, and note that preserving a specified angle on the page 
is part of it.  Also note that the transform has to be regenerated on 
resize events, so a custom draw method is required.

(Mike D. translated my original quiver code to use his transforms 
framework.)

It seems like there should be an easier-to-use and more general way to 
do these sorts of things, and maybe there is--or maybe it can be ginned up.

This reminds me of a thread a long time ago regarding adding hooks so 
that classes could register methods to be executed before their artists 
are rendered but after things like window and axes sizes have been 
determined.

Eric

Hi,

I'll continue my current flood of emails to the list. :)  I'm finally 
getting back to my work on Skew-T plots, and I have a semi-working 
implementation (attached.)  It runs, and as is, plots up some of the 
grid, with the x-value grid lines skewed 45 degrees to the right (as 
they should be.)  The problem is as you resize the plot horizontally, 
some weird things happen.  First, some of the lines that start overlaid 
end up separating as you expand the plot.  The difference is between 
what is added using ax.plot and what is added using ax.vlines.  The 
former adds Line2D objects while the latter adds a LineCollection which 
is holding path objects.  I'm really not sure what's going on there. I'm 
not done checking it out yet, but I'm curious if anyone has any ideas 
off the top of their head.

The second issue, which is more pressing, is when you resize vertically, 
the axes limits of the plot don't change (good), but unfortunately the 
lines don't stay connected to their lower y-coordinate in data space 
(bad).  I'm really needing to draw things in a coordinate system that's 
independant of the data scale but also doesn't depend on the aspect 
ratio of the axes, so that I can get lines (and data plots) where the x 
gridlines are always at a 45 degree angle and the lower Y-value point 
stays fixed.  By problem right now is that while I can find the lower 
left corner in pixel space and use that to do the proper adjustments, 
this changes when you resize.  This changing is especially important in 
the y-direction.  What I need is either of:

	1) Axes space adjusted for aspect ratio (and updated with resizes)
	2) Pixel space relative to some corner of the axes

Or something similar that I don't know about.  Any thoughts, or do I 
just need to come up with some magical combination of transforms that 
works?  You can see what I have so far in my attached file.

Thanks in advance,

Ryan

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

John Hunter wrote:
> On Mon, Jul 21, 2008 at 11:35 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> Has anyone ever thought about creating a TextCollection class?  The
>> purpose would be similar to the other collections, to group a bunch of
>> text objects with similar properties.  This probably couldn't inherit
>> from Collection as of now though, since Collection assumes things like
>> edgecolor and facecolor.  The bigger question to me is, could the
>> backends make use of this to any improvement?  Or would this simply
>> serve as an API to eliminate having to loop yourself (which would pretty
>> much make this useless).
>>
>> My own personal use case is (once again) in meteorology, where we do
>> station plots.  This involves printing the actual value of observed
>> variables relative to the location of the station.  This isn't hard to
>> do right now (especially since I have offset_copy back, thanks Mike!).
>> I just wasn't sure if the batch functionality of a Collection might
>> serve some purpose to the users at large.
> 
> I've thought of it many times and it would definitely be useful, eg
> for tick labels.  Treating every label as a separate instance
> definitely slows things down.
> 

Ok, good to know.  I'll put it on my todo list then.  Do you think this 
can inherit from Collection at all?  It seemed like a lot of the methods 
in the Collection base class were specific to polygons or other geometry 
and don't really make sense in the case of text.

Anyone else have thoughts on how this should be implemented?

Ryan

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

On Mon, Jul 21, 2008 at 04:42:39PM -0700, Ted Drain wrote:
> The public layer would just do conversions and then pass through to the
> private layer.  Any code in the public layer would have to concern itself
> with possible different types (numpy vs lists, units vs floats, color names
> vs rgb).  Any code written in the private layer could be assured of having
> some specific input types and would be much easier to write.

Keep in mind that public units need to be tied to font in order 
to get nice looking results.  I commented on this earlier:

   http://www.nabble.com/font-troubles-td16601826.html#a16601826

I'm not sure all the necessary information to transform to pixels will
be available at the time the units are parsed, and we may need to carry 
them into the private layer.

> Of course this would be a lot work and would require refactoring axis and
> maybe some of the collections.  In theory it should be possible, but only
> you guys can decide if it's actually worthwhile or not.

One of the things I miss from Tcl/Tk is the ability to use units 
on values.  The link above shows that you can simulate units from
outside, but the code is ugly.

   - Paul

On Tue, Jul 22, 2008 at 6:30 AM, Jeff Whitaker <js...@fa...> wrote:

> Chris: I've now added a griddata function to matplotlib.mlab that uses
> Robert Kern's scikit.delaunay code (which is now included in matplotlib
> as matplotlib.delaunay).  The more bulletproof natgrid code, with the
> dubious license, is included as a toolkit (mpl_toolkits.natgrid), which
> griddata is configured to automatically use if installed.

Jeff, thanks for the extra effort to do it this way -- I know it was a
pain.  But at least now we get

  * commercial users can rely on our license as iron-clad

  * griddata will work transparently out of the box for regular users

  * we provide a path to the more bullet proof code for those who need it

I have a few comments I'll include below.

* Let's move the try/except natgrid/griddata import to the griddata
function itself so users not using griddata will not have to pay for
the import, since this will likely be 99% of the mpl users

* Expose griddata to the pylab interface and add it to the pylab  and
mlab module doc strings

* We should provide some help for those who may want to try the
natgrid code, eg if you plan on releasing it on the sf site as a
toolkit, which I think is best, then we can link to the download page
in the docstring.  If not, perhaps just provide an svn checkout line
for folks.

* Let's report which package is being used at the verbose helpful
level, preferably with some version info if it is available.  When
questions come in on the mailing list later, we will want to know
which package griddata is using.  You might set a flag on the griddata
function along the lines of

def griddata(blah)
    if not griddata._reported:
        if _use_natgrid:
            verbose.report('using natgrid version blah')
        else:
            verbose.report('using delaunay version blah')
        natgrid._reported = True
griddata._reported = False

* After the next release, let's remember to update the cookbook entry
- http://www.scipy.org/Cookbook/Matplotlib/Gridding_irregularly_spaced_data

Anyway, this is a great piece of additional functionality that we've
literally been waiting years for, so thanks for taking the extra time
to do it so thoroughly.

And enterprising developers everywhere, it would still be extremely
useful to follow Robert's suggestions to improve the delaunay code
along the lines discussed in this thread earlier.  Not for the faint
of heart, but users for generations to come will thank you.

JDH

On Mon, Jul 21, 2008 at 11:35 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Has anyone ever thought about creating a TextCollection class?  The
> purpose would be similar to the other collections, to group a bunch of
> text objects with similar properties.  This probably couldn't inherit
> from Collection as of now though, since Collection assumes things like
> edgecolor and facecolor.  The bigger question to me is, could the
> backends make use of this to any improvement?  Or would this simply
> serve as an API to eliminate having to loop yourself (which would pretty
> much make this useless).
>
> My own personal use case is (once again) in meteorology, where we do
> station plots.  This involves printing the actual value of observed
> variables relative to the location of the station.  This isn't hard to
> do right now (especially since I have offset_copy back, thanks Mike!).
> I just wasn't sure if the batch functionality of a Collection might
> serve some purpose to the users at large.

I've thought of it many times and it would definitely be useful, eg
for tick labels.  Treating every label as a separate instance
definitely slows things down.

JDH

Christopher Barker wrote:
> arrg!
>
> When am I going to learn not to click "send" until after I've read the 
> entire thread!
>
> Jeff Whitaker wrote:
>   
>> John:  I just contacted NCAR again, and it seems that they have 
>> relicensed the software under an OSI-based license similar to the 
>> University of Illinois/NCSA:
>>     
> ...
>   
>> What do you think?  If it's OK I say we use the natgrid package in 
>> matplotlib, since it's more bulletproof than the scikits package (it 
>> passes Robert's degenerate triangulation test, and has been pounded on 
>> by user of NCAR graphics since the 1980's).
>>     
>
> that would be nice, but while it is a good solution to the re-gridding 
> problem, it doesn't appear to provide a general purpose delauney 
> triangulation solution, which is too bad -- it would be nice to have 
> that in MPL.
>
> -Chris
>
>
>   
Chris: I've now added a griddata function to matplotlib.mlab that uses 
Robert Kern's scikit.delaunay code (which is now included in matplotlib 
as matplotlib.delaunay).  The more bulletproof natgrid code, with the 
dubious license, is included as a toolkit (mpl_toolkits.natgrid), which 
griddata is configured to automatically use if installed.

-Jeff

Klaus Zimmermann wrote:
> Eric Firing schrieb:
>> John Hunter wrote:
>>> On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann
>>> <kla...@fm...> wrote:
>>>> Hello *,
>>>>
>>>> right now the NonUniformImage class in image.py uses numpy's asarray
>>>> method. All similar classes instead use numpy.ma.asarray, thus allowing
>>>> for masked images.
> [...]
>> Masked arrays are handled automatically as needed by the 
>> ScalarMappable.to_rgba() method.
>>
>> What we really wanted, and the change I made throughout image.py, is 
>> to keep masked input as masked, and to ensure that anything else is a 
>> plain ndarray.  This is now committed.
> I just checked and I think your changes solve my problem well, obviously 
> without introducing the potential problems you mentioned above. Thanks!
> I was just confused by the different semantics:
> AxesImage : does masks, NxM array expects N, M dimensions.
> NonUniformImage : didn't do masks, NxM array expects N, M dimensions.
> PcolorImage: does masks, NxM array expects N+1, M+1 dimensions.

Note that Image also handles PIL arrays, and all three handle NxMx3 and 
NxMx4 rbg and rgba arrays, in place of color mapping.

> 
> Though I think the mask thingie in the NonUniformImage was simply a bug 
> and I understand why PcolorImage is the way it is, it still stumped me 
> at first sight. Also I find it difficult to understand the difference 
> Pcolor and NonUniform since NonUniform does pseudo colors just as well?
> However if you feel this is just a lack of RTFM on my part please feel 
> free to ignore.

NonUniformImage came first, and sat around for a long time without 
getting an Axes or pylab interface.  Exactly what it should do always 
seemed a bit ambiguous to me; when the "pixels" are not uniformly 
spaced, where should the boundaries be?  The only thing that makes sense 
to me in this case is to explicitly provide the boundaries, which is 
what pcolor does.  But the original pcolor was slow, so I modified the 
NonUniformImage extension and python code to handle explicit boundaries 
to make a faster pcolor.  I ended up with pcolorfast, which uses image 
code if the grid is uniform, PcolorImage code if it is rectangular but 
not uniform, and quadmesh if it is not even rectangular.  In all of 
this, since I had never used NonUniformImage, and had no idea who was 
using it for what, I simply left it alone.  It could be reimplemented as 
a wrapper around PcolorImage, thereby reusing rather than duplicating 
some code, but this is at best low priority.

> 
>> I considered using np.asanyarray(A) but rejected it because it could 
>> fail for matrix input if any code is expecting iteration or 
>> single-indexing to return a 1-D array.
> Makes sense. But perhaps we should refactor that check into a (module) 
> function of its own, as to avoid recundancy? I can do that if you want, 
> or if you prefer a classmethod in AxesImage?
> 

I think the check is so short and simple that for now it is best to 
leave it as-is; maybe later there will be an attempt to factor some 
argument handling like this out from mpl as a whole, not just the image 
classes.

> 
>> We lack examples to test masking of various types of input in the 
>> various types of image, though.  Maybe I will add that later.  Klaus, 
>> if you have any nice, small examples you would like to add to the mpl 
>> examples directory, that illustrate features or use cases that are not 
>> exercised in any present examples, please submit them.
> Will do.
>

Good, thank you.

Eric

> Cheers,
> Klaus

Hi,

Has anyone ever thought about creating a TextCollection class?  The 
purpose would be similar to the other collections, to group a bunch of 
text objects with similar properties.  This probably couldn't inherit 
from Collection as of now though, since Collection assumes things like 
edgecolor and facecolor.  The bigger question to me is, could the 
backends make use of this to any improvement?  Or would this simply 
serve as an API to eliminate having to loop yourself (which would pretty 
much make this useless).

My own personal use case is (once again) in meteorology, where we do 
station plots.  This involves printing the actual value of observed 
variables relative to the location of the station.  This isn't hard to 
do right now (especially since I have offset_copy back, thanks Mike!). 
I just wasn't sure if the batch functionality of a Collection might 
serve some purpose to the users at large.

Thoughts?

Ryan

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

Michael Droettboom wrote:
> Ryan May wrote:
>> 5) I added an empty circle marker for low wind speeds (vector 
>> magnitudes).  Accomplishing having the unfilled circle while having 
>> the barbs filled involved a bit of a "elegant hack".  Using the set of 
>> vertices that draws the CirclePolygon, I add an additional copy of 
>> these vertices, basically drawing the circle back the other way.  This 
>> is basically tricking the drawing algorithm into drawing a really thin 
>> annulus with a very small gap, but it works perfectly as far as I can 
>> tell.  It's also somewhat consistent with the way the lines on the 
>> barb are drawn.  It is *far* simpler than any other solution, which 
>> would have required somehow mapping a color to each polygon *before* 
>> calling
>> draw_path_collection().  None of the backends I test had a problem, 
>> including PS, PDF, and SVG (tested with Evince, Firefox, and Acroread).
> Having replied before reading all my e-mail, I see you arrived at a 
> similar solution to the one I suggested.  Great to hear that it worked.

I'm just glad to know that it's an accepted hack. :)

Ryan

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

Eric Firing wrote:
> Eric Firing wrote:
>> Ryan May wrote:
>>> Hi,
>>>
>>> As promised, here's a short patch to add get_offsets() and 
>>> set_offsets() to the Collections() base class.  I tried to make it do 
>>> the right thing with regard to _offsets vs. _uniform_offsets, 
>>> depending on whether _uniform_offsets is None.  I also had tried to 
>>> make __init__ use set_offsets, but that proved to be too much of a 
>>> hassle for too little code reuse.
>>>
>>> Comments?
>>
>> I have applied this patch along with entries in API_CHANGES and 
>> CHANGELOG.  It looks correct in the context of the present code, and 
>> since it is completely new functionality it can't hurt.
> 
> Rats!  I see I fouled up the commit message.  I don't know how I came up 
> with "Ryan Kraus"!  Sorry...  I should have just left the commit to you.

Don't worry about it. It's not a big deal, even though I am only doing 
open source for the credit, and the fame, fortune and women.....I still 
get those right?

Ryan "Kraus" May

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