Re: [Matplotlib-users] Some questions regarding pcolor(mesh)/nbagg/FuncAnimate
Tom,
Thanks for the code. As it was given, I had to change `blit=True` in the
`FuncAnimation` call in order to get this to work in a regular Qt backend.
It did not work with the nbagg backend; however, if I used this code it
works fine:
%matplotlib nbagg
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animate
class Testing(object):
def __init__(self, ):
self.fig = plt.figure()
array = np.random.rand(4,5)
array = np.zeros((4,5))
self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.)#,
animated=True)
self.pc.set_clim([0, 1])
self.points = [plt.scatter(np.random.rand(), np.random.rand())]#,
animated=True)]
def update(self, iter_num):
array = np.random.rand(4*5)
self.pc.set_array(array)
for point in self.points:
point.set_offsets([np.random.rand(), np.random.rand()])
#return (self.pc, ) + tuple(self.points)
test = Testing()
ani = animate.FuncAnimation(test.fig, test.update, interval=250,
blit=False, frames=50)
plt.show()
Also this code solves the problem I was having with several scatter points
being displayed upon multiple runs of the same code cell.
I wasn't familiar with the "animated" keyword, and it is not well
documented yet. Can you give me a quick explanation of what it is doing?
Ben: thanks for the hint about the _stop() method. I might look into that
for my example.
Thank you all for your assistance. Things are working pretty much as I need
now!
Ryan
On Sun, Apr 12, 2015 at 9:24 AM, Thomas Caswell wrote:
> You can
>
>
> ```
>
> #import matplotlib
>
> #matplotlib.use('nbagg')
>
> #%matplotlib nbagg
>
> import numpy as np
>
> import matplotlib.pyplot as plt
>
> import matplotlib.animation as animate
>
>
> class Testing(object):
>
> def __init__(self, ):
>
> self.fig = plt.figure()
>
> array = np.random.rand(4,5)
>
> array = np.zeros((4,5))
>
> self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.,
> animated=True)
>
> self.pc.set_clim([0, 1])
>
> self.points = [plt.scatter(np.random.rand(), np.random.rand(),
> animated=True)]
>
>
> def update(self, iter_num):
>
> array = np.random.rand(4*5)
>
> self.pc.set_array(array)
>
> for point in self.points:
>
> point.set_offsets([np.random.rand(), np.random.rand()])
>
>
> return (self.pc, ) + tuple(self.points)
>
>
>
> test = Testing()
>
> ani = animate.FuncAnimation(test.fig, test.update, interval=10,
> blit=False, frames=50)
>
> plt.show()
>
> ```
>
> note the addition of the `set_clim` line in the `__init__` method.
>
>
> You can also update the scatter artist in-place. The other changes will
> make it a bit for performant if you use bliting (which does not work with
> nbagg currently)
>
> Sorry I missed that part of the question first time through.
>
> Tom
>
> On Sun, Apr 12, 2015, 08:31 Ryan Nelson wrote:
>
>> Tom,
>>
>> Thanks for the links. It does seem like fragments of my problem are
>> addressed in each of those comments, so I guess I'll have to wait for a bit
>> until those things get resolved. For now, I can just tell my students to
>> restart the IPython kernel each time they run the animation, which isn't
>> that hard. It's too bad that there isn't a 'stop' method now, but it's good
>> to hear that it isn't a completely terrible idea.
>>
>> I do still need help with Question #3 from my original email, though,
>> because it affects both the Qt and nbagg backends, and it is a bit of a
>> show stopper. I can't quite understand why initializing a pcolor(mesh) with
>> random numbers makes it possible to update the array in an animation, but
>> if you use all zeros or ones, it seems to be immutable.
>>
>> Ryan
>>
>> On Sat, Apr 11, 2015 at 8:35 PM, Thomas Caswell
>> wrote:
>>
>>> Ryan,
>>>
>>> I have not looked at your exact issue yet, but there seems to be some
>>> underlying issues with animation and nbagg which we have not tracked down
>>> yet. See:
>>>
>>> https://github.com/matplotlib/matplotlib/pull/4290
>>> https://github.com/matplotlib/matplotlib/issues/4287
>>> https://github.com/matplotlib/matplotlib/issues/4288
>>>
>>> Running until a given condition is an interesting idea, but I think that
>>> means the animation objects needs to have a public 'stop' method first!
>>>
>>> Tom
>>>
>>> On Fri, Apr 10, 2015 at 3:00 PM Ryan Nelson
>>> wrote:
>>>
Good afternoon, all!
I'm really digging the nbagg backend, and I'm trying to use it to make
an animation. As the subject suggests, though, I'm having some issues with
these features. I'm using Python 3.4, Matplotlib 1.4.3, and IPython 3.1.
Below is a small code sample that emulates my system. The pcolor call can
be substituted for pcolormesh, and I see the same behavior. (Sorry this is
a bit long. I tried to break it up as best as possible.)
#
#import matplotlib
#matplotlib
Re: [Matplotlib-users] Some questions regarding pcolor(mesh)/nbagg/FuncAnimate
I just noticed your use of "animated=True". I have had trouble using that
in the past with the animation module. It is a leftover from the days
before the animation module and isn't actually used by it, IIRC. Try not
supplying that argument.
On Thu, Apr 16, 2015 at 8:18 AM, Ryan Nelson wrote:
> Tom,
>
> Thanks for the code. As it was given, I had to change `blit=True` in the
> `FuncAnimation` call in order to get this to work in a regular Qt backend.
> It did not work with the nbagg backend; however, if I used this code it
> works fine:
>
> %matplotlib nbagg
>
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib.animation as animate
>
> class Testing(object):
> def __init__(self, ):
> self.fig = plt.figure()
> array = np.random.rand(4,5)
> array = np.zeros((4,5))
> self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.)#,
> animated=True)
> self.pc.set_clim([0, 1])
> self.points = [plt.scatter(np.random.rand(), np.random.rand())]#,
> animated=True)]
>
> def update(self, iter_num):
> array = np.random.rand(4*5)
> self.pc.set_array(array)
> for point in self.points:
> point.set_offsets([np.random.rand(), np.random.rand()])
> #return (self.pc, ) + tuple(self.points)
>
>
> test = Testing()
> ani = animate.FuncAnimation(test.fig, test.update, interval=250,
> blit=False, frames=50)
> plt.show()
>
> Also this code solves the problem I was having with several scatter points
> being displayed upon multiple runs of the same code cell.
>
> I wasn't familiar with the "animated" keyword, and it is not well
> documented yet. Can you give me a quick explanation of what it is doing?
>
> Ben: thanks for the hint about the _stop() method. I might look into that
> for my example.
>
> Thank you all for your assistance. Things are working pretty much as I
> need now!
>
> Ryan
>
> On Sun, Apr 12, 2015 at 9:24 AM, Thomas Caswell
> wrote:
>
>> You can
>>
>>
>> ```
>>
>> #import matplotlib
>>
>> #matplotlib.use('nbagg')
>>
>> #%matplotlib nbagg
>>
>> import numpy as np
>>
>> import matplotlib.pyplot as plt
>>
>> import matplotlib.animation as animate
>>
>>
>> class Testing(object):
>>
>> def __init__(self, ):
>>
>> self.fig = plt.figure()
>>
>> array = np.random.rand(4,5)
>>
>> array = np.zeros((4,5))
>>
>> self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.,
>> animated=True)
>>
>> self.pc.set_clim([0, 1])
>>
>> self.points = [plt.scatter(np.random.rand(), np.random.rand(),
>> animated=True)]
>>
>>
>> def update(self, iter_num):
>>
>> array = np.random.rand(4*5)
>>
>> self.pc.set_array(array)
>>
>> for point in self.points:
>>
>> point.set_offsets([np.random.rand(), np.random.rand()])
>>
>>
>> return (self.pc, ) + tuple(self.points)
>>
>>
>>
>> test = Testing()
>>
>> ani = animate.FuncAnimation(test.fig, test.update, interval=10,
>> blit=False, frames=50)
>>
>> plt.show()
>>
>> ```
>>
>> note the addition of the `set_clim` line in the `__init__` method.
>>
>>
>> You can also update the scatter artist in-place. The other changes will
>> make it a bit for performant if you use bliting (which does not work with
>> nbagg currently)
>>
>> Sorry I missed that part of the question first time through.
>>
>> Tom
>>
>> On Sun, Apr 12, 2015, 08:31 Ryan Nelson wrote:
>>
>>> Tom,
>>>
>>> Thanks for the links. It does seem like fragments of my problem are
>>> addressed in each of those comments, so I guess I'll have to wait for a bit
>>> until those things get resolved. For now, I can just tell my students to
>>> restart the IPython kernel each time they run the animation, which isn't
>>> that hard. It's too bad that there isn't a 'stop' method now, but it's good
>>> to hear that it isn't a completely terrible idea.
>>>
>>> I do still need help with Question #3 from my original email, though,
>>> because it affects both the Qt and nbagg backends, and it is a bit of a
>>> show stopper. I can't quite understand why initializing a pcolor(mesh) with
>>> random numbers makes it possible to update the array in an animation, but
>>> if you use all zeros or ones, it seems to be immutable.
>>>
>>> Ryan
>>>
>>> On Sat, Apr 11, 2015 at 8:35 PM, Thomas Caswell
>>> wrote:
>>>
Ryan,
I have not looked at your exact issue yet, but there seems to be some
underlying issues with animation and nbagg which we have not tracked down
yet. See:
https://github.com/matplotlib/matplotlib/pull/4290
https://github.com/matplotlib/matplotlib/issues/4287
https://github.com/matplotlib/matplotlib/issues/4288
Running until a given condition is an interesting idea, but I think
that means the animation objects needs to have a public 'stop' method
first!
Tom
On Fri, Apr 10, 2015 at 3:00 PM Ryan Nelson
wrote:
> Good afternoon, all!
>
>
Re: [Matplotlib-users] Qt4 Designer Example
That will be up to him. The only reason why I know about the work is because our publisher wanted to make sure that our two books didn't cover the same material. He isn't a regular on the mailing list, so I don't know if he even would see this message. I'll let him know that there is interest. Ben Root On Wed, Apr 15, 2015 at 9:16 PM, Chris O'Halloran wrote: > On 16 April 2015 at 09:51, Benjamin Root wrote: > >> A little birdie has told me that someone else is writing a new >> comprehensive matplotlib book (I think it would replace Sandros' book). >> Last I heard from the birdie, he was most of the way done with the >> manuscript. Based on my experience with the edit/review process, I would >> guess 2-3 more months to see it finished and published. >> >> > Oh cool. I'll look out for this. Will it be advertised on this list? > > > -- > BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT > Develop your own process in accordance with the BPMN 2 standard > Learn Process modeling best practices with Bonita BPM through live > exercises > http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- > event?utm_ > source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF > ___ > Matplotlib-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___ Matplotlib-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] weird matplotlib imread question for png
Firstly, thanks, Fabrice Silva
I have checked my picture files again.
For python-gray.png, now it is attacched here or can be downloaded
from
http://bbs.blendercn.org/data/attachment/forum/201504/16/222351w3952n3o9968m9a5.png.
xnview says it is 128*128*8, but "print
imread('python-gray.png').shape" says (128, 128, 3), however I suppose
it should be (128, 128)!
For python-color.png, it is my fault. xnview says it is 128*128*32, so
it has alpha channel. Hence "imread().shape =(128, 128, 4)" is right
btw. imread return array which has value between 0 and 1 for PNG file.
But for other picture format, the value is 0~255. The manual says
matplotlib reads PNG only by it self, and other files via PIL.But I
think it is better to make the returned array consistent.
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] weird matplotlib imread question for png
Le jeudi 16 avril 2015, oyster a écrit :
> Firstly, thanks, Fabrice Silva
>
> I have checked my picture files again.
>
> For python-gray.png, now it is attacched here or can be downloaded
> from
> http://bbs.blendercn.org/data/attachment/forum/201504/16/222351w3952n3o9968m9a5.png.
> xnview says it is 128*128*8, but "print
> imread('python-gray.png').shape" says (128, 128, 3), however I suppose
> it should be (128, 128)!
Funnily (or not), the png is in fact 8-bits depth so you could infer it
is grayscale, but matplotlib is right : your file uses a color palette.
The 8-bits values refer to indices of the 256-length color palette.
These indices are then converted back to the colorspace, so the shape is
eventually (...,3). Unfortunately, the color palette is here the
grayscale...
--
Fabrice
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] weird matplotlib imread question for png
>
> xnview says it is 128*128*8, but "print
> imread('python-gray.png').shape" says (128, 128, 3), however I suppose
> it should be (128, 128)!
Not sure that this is true, but I guess that xnview is using the third
dimension here to refer to a number of bytes. In this case, it is two
bytes, one for the black/white level and the other for alpha level. When
you import this with imread, the png is converted into a Numpy array. The
default behavior in this case is to create an array which is 128*128*3
because the third dimmension is the (R,G,B) levels, which will all be equal
for a gray scale image. This behavior is probably intentional so that you
don't have to write different code to handle gray/color images.
For python-color.png, it is my fault. xnview says it is 128*128*32, so
> it has alpha channel. Hence "imread().shape =(128, 128, 4)" is right
If the third dimension from xnview is bytes, then yes, you are correct.
btw. imread return array which has value between 0 and 1 for PNG file.
> But for other picture format, the value is 0~255. The manual says
> matplotlib reads PNG only by it self, and other files via PIL.But I
> think it is better to make the returned array consistent.
That is most likely due to the way that PNG and e.g. older JPG are defined.
PNG defines each RGBA value using float32, while older JPG uses uint8.
Therefor, it would not make sense to change the dtype of the image on
import.
Hope that helps.
Ryan
On Thu, Apr 16, 2015 at 10:51 AM, oyster wrote:
> Firstly, thanks, Fabrice Silva
>
> I have checked my picture files again.
>
> For python-gray.png, now it is attacched here or can be downloaded
> from
> http://bbs.blendercn.org/data/attachment/forum/201504/16/222351w3952n3o9968m9a5.png
> .
> xnview says it is 128*128*8, but "print
> imread('python-gray.png').shape" says (128, 128, 3), however I suppose
> it should be (128, 128)!
>
> For python-color.png, it is my fault. xnview says it is 128*128*32, so
> it has alpha channel. Hence "imread().shape =(128, 128, 4)" is right
>
> btw. imread return array which has value between 0 and 1 for PNG file.
> But for other picture format, the value is 0~255. The manual says
> matplotlib reads PNG only by it self, and other files via PIL.But I
> think it is better to make the returned array consistent.
>
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> Matplotlib-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Some questions regarding pcolor(mesh)/nbagg/FuncAnimate
Ben,
Sorry. I probably should have just dropped that entirely. In my code
sample, it is actually commented out because it breaks the animation with
the nbagg backend. It was in Tom's example, so I left it in because I
wanted to find out what it was doing.
Ryan
On Thu, Apr 16, 2015 at 9:30 AM, Benjamin Root wrote:
> I just noticed your use of "animated=True". I have had trouble using that
> in the past with the animation module. It is a leftover from the days
> before the animation module and isn't actually used by it, IIRC. Try not
> supplying that argument.
>
> On Thu, Apr 16, 2015 at 8:18 AM, Ryan Nelson
> wrote:
>
>> Tom,
>>
>> Thanks for the code. As it was given, I had to change `blit=True` in the
>> `FuncAnimation` call in order to get this to work in a regular Qt backend.
>> It did not work with the nbagg backend; however, if I used this code it
>> works fine:
>>
>> %matplotlib nbagg
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import matplotlib.animation as animate
>>
>> class Testing(object):
>> def __init__(self, ):
>> self.fig = plt.figure()
>> array = np.random.rand(4,5)
>> array = np.zeros((4,5))
>> self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.)#,
>> animated=True)
>> self.pc.set_clim([0, 1])
>> self.points = [plt.scatter(np.random.rand(), np.random.rand())]#,
>> animated=True)]
>>
>> def update(self, iter_num):
>> array = np.random.rand(4*5)
>> self.pc.set_array(array)
>> for point in self.points:
>> point.set_offsets([np.random.rand(), np.random.rand()])
>> #return (self.pc, ) + tuple(self.points)
>>
>>
>> test = Testing()
>> ani = animate.FuncAnimation(test.fig, test.update, interval=250,
>> blit=False, frames=50)
>> plt.show()
>>
>> Also this code solves the problem I was having with several scatter
>> points being displayed upon multiple runs of the same code cell.
>>
>> I wasn't familiar with the "animated" keyword, and it is not well
>> documented yet. Can you give me a quick explanation of what it is doing?
>>
>> Ben: thanks for the hint about the _stop() method. I might look into that
>> for my example.
>>
>> Thank you all for your assistance. Things are working pretty much as I
>> need now!
>>
>> Ryan
>>
>> On Sun, Apr 12, 2015 at 9:24 AM, Thomas Caswell
>> wrote:
>>
>>> You can
>>>
>>>
>>> ```
>>>
>>> #import matplotlib
>>>
>>> #matplotlib.use('nbagg')
>>>
>>> #%matplotlib nbagg
>>>
>>> import numpy as np
>>>
>>> import matplotlib.pyplot as plt
>>>
>>> import matplotlib.animation as animate
>>>
>>>
>>> class Testing(object):
>>>
>>> def __init__(self, ):
>>>
>>> self.fig = plt.figure()
>>>
>>> array = np.random.rand(4,5)
>>>
>>> array = np.zeros((4,5))
>>>
>>> self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.,
>>> animated=True)
>>>
>>> self.pc.set_clim([0, 1])
>>>
>>> self.points = [plt.scatter(np.random.rand(), np.random.rand(),
>>> animated=True)]
>>>
>>>
>>> def update(self, iter_num):
>>>
>>> array = np.random.rand(4*5)
>>>
>>> self.pc.set_array(array)
>>>
>>> for point in self.points:
>>>
>>> point.set_offsets([np.random.rand(), np.random.rand()])
>>>
>>>
>>> return (self.pc, ) + tuple(self.points)
>>>
>>>
>>>
>>> test = Testing()
>>>
>>> ani = animate.FuncAnimation(test.fig, test.update, interval=10,
>>> blit=False, frames=50)
>>>
>>> plt.show()
>>>
>>> ```
>>>
>>> note the addition of the `set_clim` line in the `__init__` method.
>>>
>>>
>>> You can also update the scatter artist in-place. The other changes will
>>> make it a bit for performant if you use bliting (which does not work with
>>> nbagg currently)
>>>
>>> Sorry I missed that part of the question first time through.
>>>
>>> Tom
>>>
>>> On Sun, Apr 12, 2015, 08:31 Ryan Nelson wrote:
>>>
Tom,
Thanks for the links. It does seem like fragments of my problem are
addressed in each of those comments, so I guess I'll have to wait for a bit
until those things get resolved. For now, I can just tell my students to
restart the IPython kernel each time they run the animation, which isn't
that hard. It's too bad that there isn't a 'stop' method now, but it's good
to hear that it isn't a completely terrible idea.
I do still need help with Question #3 from my original email, though,
because it affects both the Qt and nbagg backends, and it is a bit of a
show stopper. I can't quite understand why initializing a pcolor(mesh) with
random numbers makes it possible to update the array in an animation, but
if you use all zeros or ones, it seems to be immutable.
Ryan
On Sat, Apr 11, 2015 at 8:35 PM, Thomas Caswell
wrote:
> Ryan,
>
> I have not looked at your exact issue yet, but there seems to be some
> underlying issues with animation and nbagg which we have not tracked do
Re: [Matplotlib-users] weird matplotlib imread question for png
Oops. I meant bits not bytes in my earlier statements. Sorry.
On Thu, Apr 16, 2015 at 11:24 AM, Ryan Nelson wrote:
> xnview says it is 128*128*8, but "print
>> imread('python-gray.png').shape" says (128, 128, 3), however I suppose
>> it should be (128, 128)!
>
> Not sure that this is true, but I guess that xnview is using the third
> dimension here to refer to a number of bytes. In this case, it is two
> bytes, one for the black/white level and the other for alpha level. When
> you import this with imread, the png is converted into a Numpy array. The
> default behavior in this case is to create an array which is 128*128*3
> because the third dimmension is the (R,G,B) levels, which will all be equal
> for a gray scale image. This behavior is probably intentional so that you
> don't have to write different code to handle gray/color images.
>
> For python-color.png, it is my fault. xnview says it is 128*128*32, so
>> it has alpha channel. Hence "imread().shape =(128, 128, 4)" is right
>
> If the third dimension from xnview is bytes, then yes, you are correct.
>
> btw. imread return array which has value between 0 and 1 for PNG file.
>> But for other picture format, the value is 0~255. The manual says
>> matplotlib reads PNG only by it self, and other files via PIL.But I
>> think it is better to make the returned array consistent.
>
> That is most likely due to the way that PNG and e.g. older JPG are
> defined. PNG defines each RGBA value using float32, while older JPG uses
> uint8. Therefor, it would not make sense to change the dtype of the image
> on import.
>
> Hope that helps.
> Ryan
>
>
>
>
> On Thu, Apr 16, 2015 at 10:51 AM, oyster wrote:
>
>> Firstly, thanks, Fabrice Silva
>>
>> I have checked my picture files again.
>>
>> For python-gray.png, now it is attacched here or can be downloaded
>> from
>> http://bbs.blendercn.org/data/attachment/forum/201504/16/222351w3952n3o9968m9a5.png
>> .
>> xnview says it is 128*128*8, but "print
>> imread('python-gray.png').shape" says (128, 128, 3), however I suppose
>> it should be (128, 128)!
>>
>> For python-color.png, it is my fault. xnview says it is 128*128*32, so
>> it has alpha channel. Hence "imread().shape =(128, 128, 4)" is right
>>
>> btw. imread return array which has value between 0 and 1 for PNG file.
>> But for other picture format, the value is 0~255. The manual says
>> matplotlib reads PNG only by it self, and other files via PIL.But I
>> think it is better to make the returned array consistent.
>>
>>
>> --
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live
>> exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
>> event?utm_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> ___
>> Matplotlib-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF___
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Some questions regarding pcolor(mesh)/nbagg/FuncAnimate
The 'animated' property is used _deep_ with in `axes.draw` (
https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/axes/_base.py#L2035)
to skip artists with the 'animated' flag set. This makes them play nice
with blitting (which explicitly uses `axes.draw_artist`) so they are not
drawn on a call to `ax.draw` (which sets up the background canvas). Sorry,
I should not have included them with out a good explanation, I was feeling
too fancy with that example.
Tom
On Thu, Apr 16, 2015 at 11:27 AM Ryan Nelson wrote:
> Ben,
>
> Sorry. I probably should have just dropped that entirely. In my code
> sample, it is actually commented out because it breaks the animation with
> the nbagg backend. It was in Tom's example, so I left it in because I
> wanted to find out what it was doing.
>
> Ryan
>
> On Thu, Apr 16, 2015 at 9:30 AM, Benjamin Root wrote:
>
>> I just noticed your use of "animated=True". I have had trouble using that
>> in the past with the animation module. It is a leftover from the days
>> before the animation module and isn't actually used by it, IIRC. Try not
>> supplying that argument.
>>
>> On Thu, Apr 16, 2015 at 8:18 AM, Ryan Nelson
>> wrote:
>>
>>> Tom,
>>>
>>> Thanks for the code. As it was given, I had to change `blit=True` in the
>>> `FuncAnimation` call in order to get this to work in a regular Qt backend.
>>> It did not work with the nbagg backend; however, if I used this code it
>>> works fine:
>>>
>>> %matplotlib nbagg
>>>
>>> import numpy as np
>>> import matplotlib.pyplot as plt
>>> import matplotlib.animation as animate
>>>
>>> class Testing(object):
>>> def __init__(self, ):
>>> self.fig = plt.figure()
>>> array = np.random.rand(4,5)
>>> array = np.zeros((4,5))
>>> self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.)#,
>>> animated=True)
>>> self.pc.set_clim([0, 1])
>>> self.points = [plt.scatter(np.random.rand(),
>>> np.random.rand())]#, animated=True)]
>>>
>>> def update(self, iter_num):
>>> array = np.random.rand(4*5)
>>> self.pc.set_array(array)
>>> for point in self.points:
>>> point.set_offsets([np.random.rand(), np.random.rand()])
>>> #return (self.pc, ) + tuple(self.points)
>>>
>>>
>>> test = Testing()
>>> ani = animate.FuncAnimation(test.fig, test.update, interval=250,
>>> blit=False, frames=50)
>>> plt.show()
>>>
>>> Also this code solves the problem I was having with several scatter
>>> points being displayed upon multiple runs of the same code cell.
>>>
>>> I wasn't familiar with the "animated" keyword, and it is not well
>>> documented yet. Can you give me a quick explanation of what it is doing?
>>>
>>> Ben: thanks for the hint about the _stop() method. I might look into
>>> that for my example.
>>>
>>> Thank you all for your assistance. Things are working pretty much as I
>>> need now!
>>>
>>> Ryan
>>>
>>> On Sun, Apr 12, 2015 at 9:24 AM, Thomas Caswell
>>> wrote:
>>>
You can
```
#import matplotlib
#matplotlib.use('nbagg')
#%matplotlib nbagg
import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animate
class Testing(object):
def __init__(self, ):
self.fig = plt.figure()
array = np.random.rand(4,5)
array = np.zeros((4,5))
self.pc = plt.pcolor(array, edgecolor='k', linewidth=1.,
animated=True)
self.pc.set_clim([0, 1])
self.points = [plt.scatter(np.random.rand(), np.random.rand(),
animated=True)]
def update(self, iter_num):
array = np.random.rand(4*5)
self.pc.set_array(array)
for point in self.points:
point.set_offsets([np.random.rand(), np.random.rand()])
return (self.pc, ) + tuple(self.points)
test = Testing()
ani = animate.FuncAnimation(test.fig, test.update, interval=10,
blit=False, frames=50)
plt.show()
```
note the addition of the `set_clim` line in the `__init__` method.
You can also update the scatter artist in-place. The other changes
will make it a bit for performant if you use bliting (which does not work
with nbagg currently)
Sorry I missed that part of the question first time through.
Tom
On Sun, Apr 12, 2015, 08:31 Ryan Nelson wrote:
> Tom,
>
> Thanks for the links. It does seem like fragments of my problem are
> addressed in each of those comments, so I guess I'll have to wait for a
> bit
> until those things get resolved. For now, I can just tell my students to
> restart the IPython kernel each time they run the animation, which isn't
> that hard. It's too bad that there isn't a 'stop' method now, but
Re: [Matplotlib-users] weird matplotlib imread question for png
Two 8bpp(Gimp, xnview say so) graylevel png files can be downloaded
The first (ramp-gray.png) which gives right array shape is
http://bbs.blendercn.org/data/attachment/forum/201504/17/090627ejhixti8vdthdnnn.png
The second one (python-gray.png) which gives 'wrong' array shape, at
least to me, is
http://bbs.blendercn.org/data/attachment/forum/201504/16/222351w3952n3o9968m9a5.png
[code]
from pylab import *
imgRampPng=imread('ramp-gray.png')
print (imgRampPng.shape) #(1, 255), that is right
print (imgRampPng.min(),imgRampPng.max()) #(0.0, 0.99607843)
print ()
imgGrayPng=imread('python-gray.png')
print (imgGrayPng.shape)#(128, 128, 3), *but I suppose it should
be (128, 128)*
print (imgGrayPng.min(),imgGrayPng.max()) #(0.0, 0.98823529)
print ()
Ch1=imgGrayPng[:,:,0]
Ch2=imgGrayPng[:,:,1]
Ch3=imgGrayPng[:,:,2]
print (Ch1.min(), Ch1.max())#(0.0, 0.98823529)
print (Ch2.min(), Ch2.max())#(0.0, 0.98823529)
print (Ch3.min(), Ch3.max())#(0.0, 0.98823529) #that is to say,
Ch1/2/3 hold same data
print ()
[/code]
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
Matplotlib-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] segfault creating polarplot with GridHelperCurveLinear
Hi,
with normal polar plot it would work, but there is the problem with the
half plot. So I use AxisArtist already. The segfault is caused by
GridHelperCurveLinear and it appears on all my Computers here Python 2.7
(2 x Win7 64Bit, 1xWin7 32Bit, 2x Linux 64Bit) and mpl 1.4.2
The current solution would work for me, if I could change the axis tick
labels created with axisartist.
Maik
Am 12.04.2015 um 03:02 schrieb Thomas Caswell:
> Malk,
>
> This is a bit of a gap in mpl currently (but has come up a couple of times (
> https://github.com/matplotlib/matplotlib/issues/4217,
> https://github.com/matplotlib/matplotlib/issues/2203, and
> http://matplotlib.org/devdocs/devel/MEP/MEP24.html).
>
> One of the hold ups has been lack of a developer that uses polar plots
> day-to-day and a lack of really clear use cases. I think we have three (at
> least) distinct use cases.
>
> 1. origin always an 0, negative radius rotates by pi, always full 2pi
> around, always solid circle (no inner axes) (useful for plotting bunches of
> vectors against each other)
> 2. center is at arbitrary 'r', values less than 'origin' are just not
> shown, always full 2pi, no inner axes (use for for dB plots showing power
> as function of angle)
> 3. inner axes with arbitrary origin, possibly not full 2pi
>
> It is not immediately clear to me if these can all be done with the same
> projection or even if they can be done with the 'standard' Axes class or if
> we need to user AxesArtist here.
>
> This discussion should probably move to MEP24/the devel list.
>
> What version of mpl are you using? Your example causes seg-faults (!) on
> my system, but I have not sorted out why (may be really strange install
> issues on my end).
>
> Tom
>
> On Thu, Apr 9, 2015 at 6:08 AM Maik Hoffmann wrote:
>
>> Hello,
>> I'm using mpl_toolkits.axisartist.floating_axes.GridHelperCurveLinear
>> for creating half-polar plots from 180 degree measurements for receive
>> sensitivity.
>>
>> Working with the measurement values itself is no problem if I let the
>> values scaling start at zero.
>> If I use normalized values I can plot it also, but if I transform it
>> into the dB scale I got a segfault in this lib.
>>
>> I provide an example. For my problems I would like to have a solution
>> that I can either use r limit from -30 to 0 (f3) or changing the tick
>> labels in figure f2.
>>
>> And by the way is there a possibility that the if i want to plot data in
>> the range from 80 to 120, that rlim(80,120) would set the 80 to the
>> centerpoint? At the moment I got only a small stripe.
>>
>> [code]
>> """Demo of polar plot of arbitrary theta. This is a workaround for MPL's
>> polar plot limitation
>> to a full 360 deg.
>>
>> Based on
>> http://matplotlib.org/mpl_toolkits/axes_grid/examples/
>> demo_floating_axes.py
>>
>> get from
>> https://github.com/neuropy/neuropy/blob/master/neuropy/
>> scripts/polar_demo.py
>> TODO: license / copyright
>> """
>>
>> from __future__ import division
>> from __future__ import print_function
>>
>> import numpy as np
>> import matplotlib.pyplot as plt
>>
>> from matplotlib.transforms import Affine2D
>> from matplotlib.projections import PolarAxes
>> from mpl_toolkits.axisartist import angle_helper
>> from mpl_toolkits.axisartist.grid_finder import MaxNLocator
>> from mpl_toolkits.axisartist.floating_axes import GridHelperCurveLinear,
>> FloatingSubplot
>>
>>
>> def fractional_polar_axes(f, thlim=(0, 180), rlim=(0, 1), step=(30, 0.2),
>> thlabel='theta', rlabel='r', ticklabels=True,
>> theta_offset=0):
>> """Return polar axes that adhere to desired theta (in deg) and r
>> limits. steps for theta
>> and r are really just hints for the locators."""
>> th0, th1 = thlim # deg
>> r0, r1 = rlim
>> thstep, rstep = step
>>
>> tr_rotate = Affine2D().translate(theta_offset, 0)
>> # scale degrees to radians:
>> tr_scale = Affine2D().scale(np.pi/180., 1.)
>> #pa = axes(polar="true") # Create a polar axis
>> pa = PolarAxes
>> tr = tr_rotate + tr_scale + pa.PolarTransform()
>> theta_grid_locator = angle_helper.LocatorDMS((th1-th0)//thstep)
>> r_grid_locator = MaxNLocator((r1-r0)//rstep)
>> theta_tick_formatter = angle_helper.FormatterDMS()
>>
>> grid_helper = GridHelperCurveLinear(tr,
>> extremes=(th0, th1, r0, r1),
>> grid_locator1=theta_grid_locator,
>> grid_locator2=r_grid_locator,
>>
>> tick_formatter1=theta_tick_formatter,
>> tick_formatter2=None)
>>
>> a = FloatingSubplot(f, 111, grid_helper=grid_helper)
>>
>> f.add_subplot(a)
>>
>> # adjust x axis (theta):
>> a.axis["bottom"].set_visible(False)
>> a.axis["top"].set_axis_direction("bottom") # tick direction
>> a.axis["top"].toggle(ticklabels=ticklabels, label=bool(
