matplotlib-devel Mailing List for matplotlib

Actually, it seems that the following thread is also relevant to this 
issue : [matplotlib-devel] merging sympy plotting stuff with matplotlib 
<http://www.mail-archive.com/mat...@li.../msg02276.html>

Hi,
I was wondering if anyone had thought about finding homes for some of
the functions in mlab that are useful outside of matplotlib? I'm
specifically thinking of psd, which has no equivalent (to my knowledge)
in numpy/scipy.
Thanks,
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Paul Kienzle wrote:
> On Thu, Jan 31, 2008 at 08:38:35AM +0100, Rob Hetland wrote:
>> I was just working with a student to do this. It is straightforward 
>> (using norms, as Eric suggests), but not short. I think it would be 
>> good to include wrappers for creating these norms to MPL.
>>
>> The advantage is then it works for everything: pcolor, scatter, etc.
> 
> Couldn't you also do this by providing a short colourmap instead of
> fiddling the norms?
Yes, but it is not as general a solution. The BoundaryNorm that I will 
add allows arbitrary color boundaries, just as the specification of 
levels in contourf does.
Eric
> 
> 	- Paul

I have to report two more issues (sorry I'm reporting, not squashing, I'm 
swamped at work.)
imshow(rand(100,100))
colorbar()
The horizontal alignment of the ticklabels is off, they are centered on the 
axis rather than being positioned to the right of it. Also, the image appears 
to be shifted in the axes, to the left and the top by one pixel.
Darren

On Thu, Jan 31, 2008 at 08:38:35AM +0100, Rob Hetland wrote:
> 
> I was just working with a student to do this. It is straightforward 
> (using norms, as Eric suggests), but not short. I think it would be 
> good to include wrappers for creating these norms to MPL.
> 
> The advantage is then it works for everything: pcolor, scatter, etc.
Couldn't you also do this by providing a short colourmap instead of
fiddling the norms?
	- Paul

On Thu, Jan 31, 2008 at 08:20:37AM -0600, John Hunter wrote:
> As you know, this has been a much requested feature,
I know. I have wanted it pretty badly.
> and the hard part is to get something working across backends, which it
> looks like you've done.
Looks like it works OK. I would appreciate heads up from people who know
GTK, as I am not too sure of possibly garbbling the mainloop with my
kludge. But I have tested it quit extensively and it seems to work.
> I suggest a minor reorganization. Get rid of ginput.py altogether,
> add the BlockingMouseInput code to either backend_bases.py or
> figure.py. Make a figure.Figure.ginput method, so folks can use it
> outside of pylab, and then add a ginput method to pyplot.py which is a
> thin wrapper to the Figure.ginput method.
Yup, this seems like a good solution.
> If this seems like a good organization to you, I'll wait for a new
> patch and then contribute that.
Give me a few days, but it will come.
Cheers,
Gaël

Eric Firing wrote:
> Jordan,
>
> This sounds useful, but I think it can be implemented without any new 
> plot type, simply by using a different sort of norm to do the 
> colormapping. I need to add this anyway, and I have a prototype. It 
> is very simple. I will get it in within the next few days, and then 
> you can see whether it meets your needs.
>
> Eric
I assume you mean to use pcolor for this kind of plot, but with the 
added ability to specify levels. This doesn't do what I want; I want 
the ability to make large contiguous contourf-style areas outlined with 
contour-style lines that follow the grid edges, not the hundreds of 
little squares that pcolor makes. But I agree that this may not be 
useful enough to warrant a new plot type. I'll just keep using my 
hacked add-on code and if anyone else wants this kind of functionality, 
you can direct them to me.
Jordan

Fixed in SVN r4910. It was a mistake when upgrading agg from 2.3 to 2.4.
Cheers,
Mike
Darren Dale wrote:
> I just wanted to report some artifacts that appear when I use imshow from the 
> trunk:
> 
> a=arange(10000)
> a.shape=(100,100)
> #ok:
> figure()
> imshow(a,interpolation='nearest')
> figure()
> imshow(a,interpolation='bilinear')
> #odd:
> figure()
> imshow(a,interpolation='bicubic')
> figure()
> imshow(a,interpolation='spline16')
> figure()
> imshow(a,interpolation='gaussian')
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I just wanted to report some artifacts that appear when I use imshow from the 
trunk:
a=arange(10000)
a.shape=(100,100)
#ok:
figure()
imshow(a,interpolation='nearest')
figure()
imshow(a,interpolation='bilinear')
#odd:
figure()
imshow(a,interpolation='bicubic')
figure()
imshow(a,interpolation='spline16')
figure()
imshow(a,interpolation='gaussian')
Darren

This should now be fixed in SVN r4909. The padding between the axes and 
the tick labels was not getting updated when the dpi changed. (That's 
why Rob's workaround worked, because it set the dpi "early enough").
There is still a known dpi bug with custom-shaped scatter plots, but I 
hope to tackle that next.
Cheers,
Mike
Rob Hetland wrote:
> I noticed this bug last week (and forgot to send it in until now.. I 
> know.. shame on me..).
> 
> Here is the workaround (responsible for my laziness):
> 
> figure(dpi=500)
> # make a figure
> savefig(dpi=500)
> 
> That is, as long as the figure and savefig dpi match, it looks 
> alright. Otherwise, the tick labels are off.
> 
> I'm using recent svn (trunk).
> 
> -Rob
> 
> On Jan 31, 2008, at 8:00 AM, Eric Firing wrote:
> 
>> In the course of answering a question by Alan Isaac, I saved some
>> figures at different dpi values and hit a bug with png output:
>>
>> imshow(rand(100,100))
>> gcf().savefig('f200.png', dpi=200)
>>
>> This results in tick labels that overlap the image, and it gets worse
>> with higher dpi. PS backend output is OK.
>>
>> This is with svn trunk.
>>
>> Eric
>>
>> ---------------------------------------------------------------------- 
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jan 29, 2008 8:15 PM, Gael Varoquaux <gae...@no...> wrote:
> Ooops, I had forgotten to add the Wx backend. Here is a new patch.
>
> By the way, with the wx backend, there seems to be a simple mistake in
> the "show" method of the figure manager, to reproduce the traceback do
> (with a recent ipython):
Hey Gael -- this is really cool. As you know, this has been a much
requested feature, and the hard part is to get something working
across backends, which it looks like you've done.
I suggest a minor reorganization. Get rid of ginput.py altogether,
add the BlockingMouseInput code to either backend_bases.py or
figure.py. Make a figure.Figure.ginput method, so folks can use it
outside of pylab, and then add a ginput method to pyplot.py which is a
thin wrapper to the Figure.ginput method.
If this seems like a good organization to you, I'll wait for a new
patch and then contribute that.
Thanks!
JDH

I noticed this bug last week (and forgot to send it in until now.. I 
know.. shame on me..).
Here is the workaround (responsible for my laziness):
figure(dpi=500)
# make a figure
savefig(dpi=500)
That is, as long as the figure and savefig dpi match, it looks 
alright. Otherwise, the tick labels are off.
I'm using recent svn (trunk).
-Rob
On Jan 31, 2008, at 8:00 AM, Eric Firing wrote:
> In the course of answering a question by Alan Isaac, I saved some
> figures at different dpi values and hit a bug with png output:
>
> imshow(rand(100,100))
> gcf().savefig('f200.png', dpi=200)
>
> This results in tick labels that overlap the image, and it gets worse
> with higher dpi. PS backend output is OK.
>
> This is with svn trunk.
>
> Eric
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

I was just working with a student to do this. It is straightforward 
(using norms, as Eric suggests), but not short. I think it would be 
good to include wrappers for creating these norms to MPL.
The advantage is then it works for everything: pcolor, scatter, etc.
-Rob
On Jan 31, 2008, at 12:07 AM, Eric Firing wrote:
> Jordan,
>
> This sounds useful, but I think it can be implemented without any new
> plot type, simply by using a different sort of norm to do the
> colormapping. I need to add this anyway, and I have a prototype. 
> It is
> very simple. I will get it in within the next few days, and then you
> can see whether it meets your needs.
>
> Eric
>
> Jordan Dawe wrote:
>> So I have a (slightly) new plot type I would like to add to the
>> matplotlib codebase, and I'd like to ask A) if people would be
>> interested in the patch and B) what the best way to implement it 
>> would be.
>>
>> I am currently calling the plot type "pcontourf"--it's essentially a
>> pcolor, but instead of a continuous color spectra of value, it plots
>> discrete levels of data like contourf does. I find this kind of plot
>> useful for model output--it displays the model grid, and also 
>> emphasizes
>> data transitions, for example, between the negative and positive 
>> areas
>> of a plot, better than pcolor. Essentially it is just a contourf
>> wrapper that, instead of calling contourf with values at the 
>> 'center' of
>> a grid cell, calls contourf with points at the edges of the grid 
>> cell so
>> you end up with rectangular areas.
>>
>> If someone is actually interested in clean this up and put it into 
>> svn,
>> my next question is where in the codebase would be the best place 
>> to put
>> it so I can make a clean diff file? pyplot.py? I don't quite
>> understand how the matplotlib module hierarchy works.
>>
>> Jordan
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

In the course of answering a question by Alan Isaac, I saved some 
figures at different dpi values and hit a bug with png output:
imshow(rand(100,100))
gcf().savefig('f200.png', dpi=200)
This results in tick labels that overlap the image, and it gets worse 
with higher dpi. PS backend output is OK.
This is with svn trunk.
Eric