matplotlib-devel Mailing List for matplotlib

On Thu, Oct 7, 2010 at 12:25 PM, braingram <bra...@gm...> wrote:
> Thanks for the tips on adding 3d subplots. I tested to see if the
> points bled over into the other subplots and they do not. When I was
> referring to the points not being clipped I was talking about the the
> points falling outside of the drawn 3d axes within the subplot, not
> falling outside of the subplot.
>
> I tested the subplot clipping out with the TkAgg and MacOSX backends
> (two subplots side-by-side) with the these results:
> 1. the 3d points in one subplot do not extend into the other subplot
> (the unseen points: [2,2], [3,3], [4,4] in the left subplot do not
> appear in the right subplot)
> 2. the 3d points in a single subplot can appear outside of the drawn
> 3d axes (as seen in the right subplot)
>
> The clipping error (2 above) within a given subplot is not related to
> the panning code (the attached plot was not panned) and occurs
> whenever the axis limits are changed from their autoscaled values
> (either by set_xlim etc, by zooming, or by panning).
>
>
Right, this concurs with my observations when I was fiddling around with
mplot3d code over the summer. I am not exactly sure exactly where the fault
lies, but it is related to the Agg backend renderer either not being told
what should be clipped out, or is not understanding the information coming
from mplot3d to know what should be clipped. This will happen in any sort
of situation that moves the plot from the original view.
Ben Root

Thanks for the tips on adding 3d subplots. I tested to see if the
points bled over into the other subplots and they do not. When I was
referring to the points not being clipped I was talking about the the
points falling outside of the drawn 3d axes within the subplot, not
falling outside of the subplot.
I tested the subplot clipping out with the TkAgg and MacOSX backends
(two subplots side-by-side) with the these results:
1. the 3d points in one subplot do not extend into the other subplot
(the unseen points: [2,2], [3,3], [4,4] in the left subplot do not
appear in the right subplot)
2. the 3d points in a single subplot can appear outside of the drawn
3d axes (as seen in the right subplot)
The clipping error (2 above) within a given subplot is not related to
the panning code (the attached plot was not panned) and occurs
whenever the axis limits are changed from their autoscaled values
(either by set_xlim etc, by zooming, or by panning).
On Thu, Oct 7, 2010 at 11:28 AM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Oct 7, 2010 at 10:19 AM, braingram <bra...@gm...> wrote:
>>
>> Thanks for catching that! I added the changes to mouse_init and
>> improved the panning so it works more consistently at different 'zoom'
>> levels and attached an updated patch.
>>
>> I tried to sort out the clipping issue you mentioned but failed to
>> wrap my head around how to clip the 3d data. It looks like (at least
>> in the svn trunk) there is no clipping of the 3d data (I tried
>> panning, zooming, and changing the axis limits and saw no clipping).
>> I'm also unsure how to make 3d subplots. I might just be too lost to
>> fix this one but if I make any progress I'll pass it along.
>>
>
> Ok, so you do see that the 3d image is not clipped when panning? I believe
> this is an issue with the backend's interface with mplot3d's special axes,
> and it is certainly not trivial. Until such issue is resolved, it is
> probably best to continue disabling the pan feature.
>
> By the way, subplotting 3d figures is a new feature made available in
> version 1.0. It is very easy. While you still have to use the same import
> command as before, you can now create a subplot axes of type 3d by doing:
>
> fig = plt.figure()
> ax = fig.add_subplot(1, 1, 1, projection='3d')
>
> As for the issue with the MacOSX backend, you might need to file a separate
> trouble ticket for that.
>
> Thank you for helping to improve matplotlib!
> Ben Root
>
>

On Thu, Oct 7, 2010 at 10:19 AM, braingram <bra...@gm...> wrote:
> Thanks for catching that! I added the changes to mouse_init and
> improved the panning so it works more consistently at different 'zoom'
> levels and attached an updated patch.
>
> I tried to sort out the clipping issue you mentioned but failed to
> wrap my head around how to clip the 3d data. It looks like (at least
> in the svn trunk) there is no clipping of the 3d data (I tried
> panning, zooming, and changing the axis limits and saw no clipping).
> I'm also unsure how to make 3d subplots. I might just be too lost to
> fix this one but if I make any progress I'll pass it along.
>
>
Ok, so you do see that the 3d image is not clipped when panning? I believe
this is an issue with the backend's interface with mplot3d's special axes,
and it is certainly not trivial. Until such issue is resolved, it is
probably best to continue disabling the pan feature.
By the way, subplotting 3d figures is a new feature made available in
version 1.0. It is very easy. While you still have to use the same import
command as before, you can now create a subplot axes of type 3d by doing:
fig = plt.figure()
ax = fig.add_subplot(1, 1, 1, projection='3d')
As for the issue with the MacOSX backend, you might need to file a separate
trouble ticket for that.
Thank you for helping to improve matplotlib!
Ben Root

doh! I hate to spam the mailing list, but I didn't respond to your
other question.
I tested this out on the MacOSX and TkAgg backends (the only ones I
have available on this machine). The MacOSX backend suffered from the
bug I mentioned earlier (no 'motion_notify_event' for click+drag
middle mouse) but the TkAgg worked fine.
On Thu, Oct 7, 2010 at 11:19 AM, braingram <bra...@gm...> wrote:
> Thanks for catching that! I added the changes to mouse_init and
> improved the panning so it works more consistently at different 'zoom'
> levels and attached an updated patch.
>
> I tried to sort out the clipping issue you mentioned but failed to
> wrap my head around how to clip the 3d data. It looks like (at least
> in the svn trunk) there is no clipping of the 3d data (I tried
> panning, zooming, and changing the axis limits and saw no clipping).
> I'm also unsure how to make 3d subplots. I might just be too lost to
> fix this one but if I make any progress I'll pass it along.
>
> On Wed, Oct 6, 2010 at 4:57 PM, Benjamin Root <ben...@ou...> wrote:
>> On Wed, Oct 6, 2010 at 3:45 PM, braingram <bra...@gm...> wrote:
>>>
>>> I fiddled around with the mplot3d axes3d panning today with some
>>> useful results. I've never submitted a patch before so please let me
>>> know if I did so incorrectly.
>>>
>>> On a related note, I noticed that middle mouse click+drags were not
>>> triggering 'motion_notify_event' events with the mac osx backend.
>>> However, when I Option(Alt) left mouse click+dragged The events were
>>> being triggered. I'm not sure if this is a osx thing or something to
>>> do with how the backend is passing on the event.
>>>
>>
>> Thanks for this, but if I recall, the panning feature was disabled because
>> of problems with (not) clipping the image outside the viewing area (which is
>> noticeable when doing subplots). Which backends have you tested this for?
>> Note, I haven't time to test patches to mplot3d for another 2 weeks.
>>
>> As an additional request, the mouse_init() function should have another
>> keyword argument added for pan_btn=2, and then use that to initialize
>> self._pan_btn in the function. Then, instead of checking if the button
>> number is equal to 2, it should compare against self._pan_btn.
>>
>> Ben Root
>>
>>
>

Thanks for catching that! I added the changes to mouse_init and
improved the panning so it works more consistently at different 'zoom'
levels and attached an updated patch.
I tried to sort out the clipping issue you mentioned but failed to
wrap my head around how to clip the 3d data. It looks like (at least
in the svn trunk) there is no clipping of the 3d data (I tried
panning, zooming, and changing the axis limits and saw no clipping).
I'm also unsure how to make 3d subplots. I might just be too lost to
fix this one but if I make any progress I'll pass it along.
On Wed, Oct 6, 2010 at 4:57 PM, Benjamin Root <ben...@ou...> wrote:
> On Wed, Oct 6, 2010 at 3:45 PM, braingram <bra...@gm...> wrote:
>>
>> I fiddled around with the mplot3d axes3d panning today with some
>> useful results. I've never submitted a patch before so please let me
>> know if I did so incorrectly.
>>
>> On a related note, I noticed that middle mouse click+drags were not
>> triggering 'motion_notify_event' events with the mac osx backend.
>> However, when I Option(Alt) left mouse click+dragged The events were
>> being triggered. I'm not sure if this is a osx thing or something to
>> do with how the backend is passing on the event.
>>
>
> Thanks for this, but if I recall, the panning feature was disabled because
> of problems with (not) clipping the image outside the viewing area (which is
> noticeable when doing subplots). Which backends have you tested this for?
> Note, I haven't time to test patches to mplot3d for another 2 weeks.
>
> As an additional request, the mouse_init() function should have another
> keyword argument added for pan_btn=2, and then use that to initialize
> self._pan_btn in the function. Then, instead of checking if the button
> number is equal to 2, it should compare against self._pan_btn.
>
> Ben Root
>
>

> From: Eric Firing [mailto:ef...@ha...] 
> Sent: Wednesday, October 06, 2010 20:53
> 
> I modified it slightly and applied to the maintenance branch. It will 
> get merged into the trunk eventually.
> 
> Your patch as submitted was not respecting the previously-set value of 
> self._tight, hence my modification.
Thank you for the review and correction, Eric. Your modification clarified
for me another behavior of the prior and new implementations: The argument
tight=True is retained for future autoscaling calls with tight=None, but
tight=False doesn't stick; future calls use the automatic children-based
logic. Does the Axes._tight attribute need to have three legal values
(corresponding to tight, loose, and children-based) to yield the documented
behavior?

On Wed, Jul 28, 2010 at 3:27 PM, Sandro Tosi <mo...@de...> wrote:
>
> I don't want to put pressure on this but... was there any progress? :)
> It would be nice to have this somehow fixed or worked-around, so that
> I can upload to debian (experimental branch) and get some testing
> there. The fact doc generation requires downloading datafiles from web
> it's the only thing left that holds upload of mpl.
Bump from this side... Dav Clark just pointed this out to me:
https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/607395
and lo and behold, unfortunately for the upcoming maverick, Ubuntu
didn't update to mpl 1.0:
http://packages.ubuntu.com/hu/maverick/python-matplotlib
If an enterprising user who is knowledgeable in the ways of Debian
could contribute a patch for these data downloading calls to be
modified/disabled, it would be a great help.
It would be a shame to see mpl stuck at 0.99 for a long time just due to this...
Here's to hoping :)
Cheers,
f