matplotlib-devel Mailing List for matplotlib

David Trem wrote:
> Thank you very much Eric !
> 
>  It basically works for me but I think there is still a small bug
> related to sharing y axes. I attach a small script that reproduce the
> problem.
> The end of the related error message is the following:
> 
>   File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
> __init__
>     if sharex._adjustable == 'box':
> AttributeError: 'NoneType' object has no attribute '_adjustable'
> 
> Hope it could help.

It certainly does, thank you.  In a cut'n'paste operation, I had 
neglected to change a couple of 'x's to 'y's.  Fixed in svn.

Thanks again, and keep testing!

Eric

This is now fixed in SVN r6318.  I also added some of the PNG test suite 
images to out regression tests so we're sure that it works with all of 
the basic PNG types.

Mike

Joshua Lippai wrote:
> Hello all,
>
> Earlier today I looked into a problem someone on the users list was
> having with imread working on a binary png file of his (attached). The
> array returned does not correspond to the picture, as verified by
> imshow'ing the imread'd file, which results in a distorted image with
> rainbow colouring at parts. After working through how imread would
> handle his file, it seems the problem has to be somewhere in
> matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
> the source tree. Interestingly enough, using the function pil_to_array
> from matplotlib.image on the output of Image.open(fname) works
> correctly on the file. I plan on poking around in the cpp file more
> myself later tonight, but I was wondering if anyone more familiar with
> matplotlib's png-handling could see something immediately obvious that
> would break imread's capabilities on binary PNGs.
>
> Josh
>   
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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'm looking into this.  It seems that matplotlib is not making the right 
calls to libpng to convert < 8-bit images for us.

Mike

Joshua Lippai wrote:
> Hello all,
>
> Earlier today I looked into a problem someone on the users list was
> having with imread working on a binary png file of his (attached). The
> array returned does not correspond to the picture, as verified by
> imshow'ing the imread'd file, which results in a distorted image with
> rainbow colouring at parts. After working through how imread would
> handle his file, it seems the problem has to be somewhere in
> matplotlib._png.read_png, which stems from matplotlib/src/_png.cpp in
> the source tree. Interestingly enough, using the function pil_to_array
> from matplotlib.image on the output of Image.open(fname) works
> correctly on the file. I plan on poking around in the cpp file more
> myself later tonight, but I was wondering if anyone more familiar with
> matplotlib's png-handling could see something immediately obvious that
> would break imread's capabilities on binary PNGs.
>
> Josh
>   
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Thank you very much Eric !

 It basically works for me but I think there is still a small bug
related to sharing y axes. I attach a small script that reproduce the
problem.
The end of the related error message is the following:

  File "*/lib/python2.5/site-packages/matplotlib/axes.py", line 515, in
__init__
    if sharex._adjustable == 'box':
AttributeError: 'NoneType' object has no attribute '_adjustable'

Hope it could help.

David

Eric Firing a écrit :
> David Trem wrote:
>> Hi,
>>
>>  Eric, I will be happy to test your possible fix too. I have similar
>> problem with autoscaling shared axes like you Mark.
>>
>> David
> 
> I have committed to svn some changes to support autoscaling with shared
> axes, so please test.  I have done only very simple and cursory
> checking.  You might try reversed axes, log axes, etc.
> 
> I have not yet addressed the aspect ratio part of Mark's original post,
> below, but I think my changes have fixed the first of the two problems,
> in addition to adding autoscaling support, which I don't think we ever
> had before.
> 
> At present, autoscaling does not work with shared axes if an aspect
> ratio is specified.
> 
> Eric
> 
>>
>> Mark Bakker a écrit :
>>> Thanks Eric.
>>>
>>> You know that this has been on my wish list for a long time.
>>>
>>> Let me know if I can test anything or help in any other way,
>>>
>>> Mark
>>>
>>> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha...
>>> <mailto:ef...@ha...>> wrote:
>>>
>>>     Mark Bakker wrote:
>>>
>>>         Hello list (especially Erik, who can fix this I hope) -
>>>
>>>         I have had problems with shared axes, especially when one of the
>>>         axis has an aspect ratio that is set 'equal'. It has been
>>>         discussed on the list before (mostly with Erik Firing), but it
>>>         hasn't been fixed yet. What I want to do is have two plots. The
>>>         top plot has an aspect ratio that is 'equal'. The idea is to
>>>         have a contour plot in the top figure, while the bottom figure
>>>         gives a cross-sectional picture of what I am plotting. This used
>>>         to work well (quite some time ago), including zooming and such.
>>>         But now I cannot plot it at all, let alone zoom.
>>>
>>>         My first problem is when I add a subplot with a shared x-axis,
>>>         it changes the limits on the original x-axis. That seems to be a
>>>         bug:
>>>         ax1 = subplot(211)
>>>         plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
>>>         subplot(212,sharex=ax1)  # Now the limits of both x-axis go from
>>>         0 to 1.
>>>
>>>         After all, the new subplot shares the axis with the existing
>>>         subplot, so why doesn't it copy the axis limits from that
>>> subplot?
>>>
>>>
>>>     I may have the fix for this, but I need more time to check and
>>>     refine it--and try to make sure that I don't break anything else in
>>>     the process.
>>>
>>>
>>>
>>>         But the bigger problem occurs when I want the aspect ratio of
>>>         one of the first axis to be 'equal'.
>>>
>>>         ax1 = subplot(211,aspect='equal')
>>>         plot([1,2,3]) subplot(212,sharex=ax1)
>>>
>>>         The second subplot is added, but the length of the graph is not
>>>         the same as for the first subplot. It also resets the xlimits to
>>>         go from 0 to 1, as before, which means the first subplot becomes
>>>         unreadable (it still enforces 'equal' in the first subplot by
>>>         changing the limits of the y-axis). When I now change the limits
>>>         on the x-axis, the aspect ratio is not equal anymore
>>>
>>>
>>>     I will see what I can do.  There are definitely some bugs that need
>>>     to be squashed.
>>>
>>>     Eric
>>>
>>>
>>>         ax1.set_xlim(0,2)
>>>         draw()
>>>
>>>         Thanks for your help. I am willing to help in testing any
>>> changes.
>>>
>>>         Best regards, Mark
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Mark Bakker wrote:
> Hello list (especially Erik, who can fix this I hope) -
> 
> I have had problems with shared axes, especially when one of the axis 
> has an aspect ratio that is set 'equal'. It has been discussed on the 
> list before (mostly with Erik Firing), but it hasn't been fixed yet. 
> What I want to do is have two plots. The top plot has an aspect ratio 
> that is 'equal'. The idea is to have a contour plot in the top figure, 
> while the bottom figure gives a cross-sectional picture of what I am 
> plotting. This used to work well (quite some time ago), including 
> zooming and such. But now I cannot plot it at all, let alone zoom.
> 
> My first problem is when I add a subplot with a shared x-axis, it 
> changes the limits on the original x-axis. That seems to be a bug:
> ax1 = subplot(211)
> plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
> subplot(212,sharex=ax1)  # Now the limits of both x-axis go from 0 to 1.
> 
> After all, the new subplot shares the axis with the existing subplot, so 
> why doesn't it copy the axis limits from that subplot?
> 
> But the bigger problem occurs when I want the aspect ratio of one of the 
> first axis to be 'equal'.
> 
> ax1 = subplot(211,aspect='equal')
> plot([1,2,3]) 
> subplot(212,sharex=ax1)

Mark,

I made some more changes so that the above works by changing the 
adjustable to 'datalim'.  Have I broken anything?  Does this work for 
your applications?

Eric

> 
> The second subplot is added, but the length of the graph is not the same 
> as for the first subplot. It also resets the xlimits to go from 0 to 1, 
> as before, which means the first subplot becomes unreadable (it still 
> enforces 'equal' in the first subplot by changing the limits of the 
> y-axis). When I now change the limits on the x-axis, the aspect ratio is 
> not equal anymore
> 
> ax1.set_xlim(0,2)
> draw()
> 
> Thanks for your help. I am willing to help in testing any changes.
> 
> Best regards, Mark
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

David Trem wrote:
> Hi,
> 
>  Eric, I will be happy to test your possible fix too. I have similar
> problem with autoscaling shared axes like you Mark.
> 
> David

I have committed to svn some changes to support autoscaling with shared 
axes, so please test.  I have done only very simple and cursory 
checking.  You might try reversed axes, log axes, etc.

I have not yet addressed the aspect ratio part of Mark's original post, 
below, but I think my changes have fixed the first of the two problems, 
in addition to adding autoscaling support, which I don't think we ever 
had before.

At present, autoscaling does not work with shared axes if an aspect 
ratio is specified.

Eric

> 
> Mark Bakker a écrit :
>> Thanks Eric.
>>
>> You know that this has been on my wish list for a long time.
>>
>> Let me know if I can test anything or help in any other way,
>>
>> Mark
>>
>> On Wed, Oct 22, 2008 at 10:54 AM, Eric Firing <ef...@ha...
>> <mailto:ef...@ha...>> wrote:
>>
>>     Mark Bakker wrote:
>>
>>         Hello list (especially Erik, who can fix this I hope) -
>>
>>         I have had problems with shared axes, especially when one of the
>>         axis has an aspect ratio that is set 'equal'. It has been
>>         discussed on the list before (mostly with Erik Firing), but it
>>         hasn't been fixed yet. What I want to do is have two plots. The
>>         top plot has an aspect ratio that is 'equal'. The idea is to
>>         have a contour plot in the top figure, while the bottom figure
>>         gives a cross-sectional picture of what I am plotting. This used
>>         to work well (quite some time ago), including zooming and such.
>>         But now I cannot plot it at all, let alone zoom.
>>
>>         My first problem is when I add a subplot with a shared x-axis,
>>         it changes the limits on the original x-axis. That seems to be a
>>         bug:
>>         ax1 = subplot(211)
>>         plot([1,2,3])  # Now the limits of the x-axis go from 0 to 2.
>>         subplot(212,sharex=ax1)  # Now the limits of both x-axis go from
>>         0 to 1.
>>
>>         After all, the new subplot shares the axis with the existing
>>         subplot, so why doesn't it copy the axis limits from that subplot?
>>
>>
>>     I may have the fix for this, but I need more time to check and
>>     refine it--and try to make sure that I don't break anything else in
>>     the process.
>>
>>
>>
>>         But the bigger problem occurs when I want the aspect ratio of
>>         one of the first axis to be 'equal'.
>>
>>         ax1 = subplot(211,aspect='equal')
>>         plot([1,2,3]) subplot(212,sharex=ax1)
>>
>>         The second subplot is added, but the length of the graph is not
>>         the same as for the first subplot. It also resets the xlimits to
>>         go from 0 to 1, as before, which means the first subplot becomes
>>         unreadable (it still enforces 'equal' in the first subplot by
>>         changing the limits of the y-axis). When I now change the limits
>>         on the x-axis, the aspect ratio is not equal anymore
>>
>>
>>     I will see what I can do.  There are definitely some bugs that need
>>     to be squashed.
>>
>>     Eric
>>
>>
>>         ax1.set_xlim(0,2)
>>         draw()
>>
>>         Thanks for your help. I am willing to help in testing any changes.
>>
>>         Best regards, Mark
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel