matplotlib-devel Mailing List for matplotlib

Hello,

I've noticed a bug with matplotlib.pyplot.imsave.  Say I have an array that is 1000*1000.  This works perfectly:

pylab.imsave(outfile,data,format='png',origin='lower')

and I get image1.png.

However, if the array is not a square, say 1000*1500, then the output image is rotated 90 degrees compared to the image it prints out.  Example, image2.png.

I tried numpy.rot90(frame) to rotate my data, and though my data did rotate, so did the output frame.  Example, image3.png.

If there is a way around this, please let me know.  Otherwise, it should be fixed  ;)

Cheers,
Rachel

BTW -- the diff is so large that viewing this page crashes my browser 
tab (in Chrome).  YMMV.  You can view the diff locally by first getting 
my repository:

    git remote add mdboom git://github.com/mdboom/matplotlib.git
    git fetch mdboom

then diffing with an external tool:

    git diff --ext-diff upstream/master mdboom/py3-merge

Of course, we can't use github's code review features that way :(

Mike


On 10/31/2011 09:16 AM, Michael Droettboom wrote:
> The pull request to merge the py3 fork back into matplotlib/master is 
> here:
>
> https://github.com/matplotlib/matplotlib/pull/565
>
> Thanks to everyone who worked on it.
>
> I plan to leave this up for a while and get as much chance for review 
> as possible.
>
> Mike
>
> On 10/28/2011 01:50 PM, Michael Droettboom wrote:
>> Now that we have 1.1.0 out, I was thinking maybe now is the time to
>> merge the matplotlib-py3 branch into master.  As a reminder, the main
>> downside is losing compatibility with Python 2.5 and earlier.  We would
>> continue to have a 1.1.x maintenance branch for the foreseeable future
>> for small-yet-critical bugfixes, and can still make a Python
>> 2.5-compatible bugfix release from that.
>>
>> Any objections or concerns?  Any reason to hold off?
>>
>> Mike
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Cisco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> Get your Android app more play: Bring it to the BlackBerry PlayBook
> in minutes. BlackBerry App World™ now supports Android™ Apps
> for the BlackBerry® PlayBook™. Discover just how easy and simple
> it is! http://p.sf.net/sfu/android-dev2dev
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

The pull request to merge the py3 fork back into matplotlib/master is here:

https://github.com/matplotlib/matplotlib/pull/565

Thanks to everyone who worked on it.

I plan to leave this up for a while and get as much chance for review as 
possible.

Mike

On 10/28/2011 01:50 PM, Michael Droettboom wrote:
> Now that we have 1.1.0 out, I was thinking maybe now is the time to
> merge the matplotlib-py3 branch into master.  As a reminder, the main
> downside is losing compatibility with Python 2.5 and earlier.  We would
> continue to have a 1.1.x maintenance branch for the foreseeable future
> for small-yet-critical bugfixes, and can still make a Python
> 2.5-compatible bugfix release from that.
>
> Any objections or concerns?  Any reason to hold off?
>
> Mike
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I'm trying to develop some control-systems libraries and I would like to
add some functionality to give plots of transfer-function representations,
but I've run into a bit of a stumbling-block. For a given transfer
function, I would like to give a way of constructing a an Axes object to be
added into a figure. Normally, it would be just fine to send in an Axes
from the user, but I need a particular (Polar) projection, which can only
be specified at the Axes creation and requires suficient user knowledge to
do something that should be done by the library.

I could not find any way to construct my graph in a function exactly as it
should be represented and then return it for the user to add it into a
figure as a subplot. I could simply be going about this the wrong way, but
I've dug into the sources a bit and I see from the inheritance of the
Artist object that Axes is quite strongly tied into the figure that created
it. It seems that Matplotlib is particularly figure-centric. Now this is
great because it gives you very great tools such as sharex and sharey and
many of the layout options that exist, but for library development, I think
that an axes-centric approach is more useful (so that the user can decide
how to layout multiple graphs representing the library objects, some of
which may need particular labeling and projection settings).

I wanted to see what others thought about this and some options to help
this situation (and to see if others think this is a big issue at all).

Changing Axes itself seems too large a task since it would break API
compatibility, but perhaps there could be ways of importing
already-constructed Axes into a figure. Here are some options:

1) allow the add_subplot and add_axes kwarg 'axes=' to accept any axis,
which it then imports into the figure (possibly creating deep copies of the
Projections and Labels and such)

2) Make new Axes-like (but non-Artist) objects for the user to use (very
similar interface). These would register to figure-aware Axes (possibly
many of them) and propagate plotting function calls down to the Axes. They
would remember the high-level plotting calls that were used on them so that
future registrations of Artist-Axes would reflect everything. this is the
most invasive, yet natural solution to me, but relegates the current
incarnation of Axes into being "back-end" objects.

3) Make Axes its own object and make it use draw calls that take an Artist
to draw high-level plotting functions. This leaves it completely decoupled,
but is likely infeasible.

Please let me know what you think. If there is a clear direction on this,
I'll commit some time to a fix, but I'm not so familiar with the ins and
outs of the code yet.

Lee