matplotlib-users Mailing List for matplotlib (Page 10)

No michael, that is what I was suggesting. Shame it doesn't work.
I'm looking at using Enthoughts Chaco to do it. It's takes a bit more to get
it doing what I want though, and I don't know if it does alpha transparency
at all.
Thanks for your help.
Pete
2008年8月6日 Michael Droettboom <md...@st...>
> It doesn't seem to matter whether the filled contours are drawn with edges
> or not -- the cuts are still visible because they're caused by over-drawing
> of the fill. (You can set linewidth=0 to try this.) But maybe I
> misunderstand your question.
>
> Cheers,
> Mike
>
>
> kippertoffee wrote:
>
>> Thank you for your reply Michael.
>>
>> Is it possible to make the lines in the contourf plot completely
>> transparent
>> using an alpha setting? That would make a reasonable workaround as I
>> intend
>> to overlay black contours anyway.
>>
>> I've had a look at the source but it is way beyond me; I am a mere
>> dabbler.
>>
>> Cheers,
>> Pete.
>>
>>
>> Michael Droettboom-3 wrote:
>>
>>
>>> This is a known issue with the contouring code. It's borrowed from an
>>> earlier plotting package called GIST, and assumes that the renderer can not
>>> handle compound polygons (for example, donut-shaped, with both an inner and
>>> outer edge). So instead, it draws "cuts" that go from the inner to the
>>> outer edge. When anti-aliasing is turned on, there is a slight overlap or
>>> "drawing twice" along this edge which creates what looks like a line.
>>> Unfortunately, this can't be remedied by plotting the contour fills and
>>> then plotting the contour edges over top (as is done is contourf_demo.py).
>>>
>>> As of matplotlib 0.98.x, matplotlib itself can handle compound paths, so
>>> we no longer need the cuts. I've made a few attempts at updating the
>>> contouring code to avoid them, but got nowhere. The contouring code is very
>>> opaque, almost magical code, and most who've dared to go in have barely made
>>> it out alive... ;) That said, a fresh pair of eyes may have what it
>>> takes...
>>>
>>> As for a workaround, you could render your contour as opaque, save that
>>> out as an image and read it back in. The code to do that won't be pretty,
>>> but it just might work.
>>>
>>> Cheers,
>>> Mike
>>>
>>> kippertoffee wrote:
>>>
>>>
>>>> Hello,
>>>>
>>>> I am attempting to overlay a filled contour over a custom image.
>>>>
>>>> I have managed to get something basic working, but i have encountered a
>>>> problem:
>>>>
>>>> When the contourf plot is set to semi-transparent there are visible
>>>> lines
>>>> joining the bottom of the plot and the filled contour edges. I have
>>>> attached
>>>> an image of the plot.
>>>>
>>>> http://img232.imageshack.us/my.php?image=spambs6.png spam.png
>>>> The code i have used is below; please bear in mind I am not a
>>>> programmer,
>>>> so
>>>> if the code seems botched, that's because it is.
>>>>
>>>> ###############################
>>>>
>>>> import matplotlib.pyplot as plt
>>>> from pylab import *
>>>> try:
>>>> import Image
>>>> except ImportError, exc:
>>>> raise SystemExit("PIL must be installed to run this example")
>>>>
>>>> lena = Image.open('lena.jpg')
>>>> dpi = rcParams['figure.dpi']
>>>> figsize = lena.size[0]/dpi, lena.size[1]/dpi
>>>>
>>>> fig = plt.figure(figsize=figsize)
>>>> #fig.patch.set_alpha(0.5)
>>>> ax = fig.add_subplot(111)
>>>> #ax.patch.set_alpha(0.5)
>>>>
>>>> ax.imshow(lena, origin='lower')
>>>>
>>>> ax.contourf(z2,[10,15,20,25,30,35,40,45,50,55,60,65],alpha=0.7)
>>>> show()
>>>> ############################
>>>>
>>>>
>>>> Can anyone help me with this problem?
>>>>
>>>> Thanks for reading,
>>>> Pete.
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

It doesn't seem to matter whether the filled contours are drawn with 
edges or not -- the cuts are still visible because they're caused by 
over-drawing of the fill. (You can set linewidth=0 to try this.) But 
maybe I misunderstand your question.
Cheers,
Mike
kippertoffee wrote:
> Thank you for your reply Michael.
>
> Is it possible to make the lines in the contourf plot completely transparent
> using an alpha setting? That would make a reasonable workaround as I intend
> to overlay black contours anyway.
>
> I've had a look at the source but it is way beyond me; I am a mere dabbler.
>
> Cheers,
> Pete.
>
>
> Michael Droettboom-3 wrote:
> 
>> This is a known issue with the contouring code. It's borrowed from an 
>> earlier plotting package called GIST, and assumes that the renderer can 
>> not handle compound polygons (for example, donut-shaped, with both an 
>> inner and outer edge). So instead, it draws "cuts" that go from the 
>> inner to the outer edge. When anti-aliasing is turned on, there is a 
>> slight overlap or "drawing twice" along this edge which creates what 
>> looks like a line. Unfortunately, this can't be remedied by plotting 
>> the contour fills and then plotting the contour edges over top (as is 
>> done is contourf_demo.py).
>>
>> As of matplotlib 0.98.x, matplotlib itself can handle compound paths, so 
>> we no longer need the cuts. I've made a few attempts at updating the 
>> contouring code to avoid them, but got nowhere. The contouring code is 
>> very opaque, almost magical code, and most who've dared to go in have 
>> barely made it out alive... ;) That said, a fresh pair of eyes may have 
>> what it takes...
>>
>> As for a workaround, you could render your contour as opaque, save that 
>> out as an image and read it back in. The code to do that won't be 
>> pretty, but it just might work.
>>
>> Cheers,
>> Mike
>>
>> kippertoffee wrote:
>> 
>>> Hello,
>>>
>>> I am attempting to overlay a filled contour over a custom image.
>>>
>>> I have managed to get something basic working, but i have encountered a
>>> problem:
>>>
>>> When the contourf plot is set to semi-transparent there are visible lines
>>> joining the bottom of the plot and the filled contour edges. I have
>>> attached
>>> an image of the plot.
>>>
>>> http://img232.imageshack.us/my.php?image=spambs6.png spam.png 
>>>
>>> The code i have used is below; please bear in mind I am not a programmer,
>>> so
>>> if the code seems botched, that's because it is.
>>>
>>> ###############################
>>>
>>> import matplotlib.pyplot as plt
>>> from pylab import *
>>> try:
>>> import Image
>>> except ImportError, exc:
>>> raise SystemExit("PIL must be installed to run this example")
>>>
>>> lena = Image.open('lena.jpg')
>>> dpi = rcParams['figure.dpi']
>>> figsize = lena.size[0]/dpi, lena.size[1]/dpi
>>>
>>> fig = plt.figure(figsize=figsize)
>>> #fig.patch.set_alpha(0.5)
>>> ax = fig.add_subplot(111)
>>> #ax.patch.set_alpha(0.5)
>>>
>>> ax.imshow(lena, origin='lower')
>>>
>>> ax.contourf(z2,[10,15,20,25,30,35,40,45,50,55,60,65],alpha=0.7)
>>> show()
>>> ############################
>>>
>>>
>>> Can anyone help me with this problem?
>>>
>>> Thanks for reading,
>>> Pete.
>>> 
>>
>> 
>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Thank you for your reply Michael.
Is it possible to make the lines in the contourf plot completely transparent
using an alpha setting? That would make a reasonable workaround as I intend
to overlay black contours anyway.
 I've had a look at the source but it is way beyond me; I am a mere dabbler.
Cheers,
Pete.
Michael Droettboom-3 wrote:
> 
> This is a known issue with the contouring code. It's borrowed from an 
> earlier plotting package called GIST, and assumes that the renderer can 
> not handle compound polygons (for example, donut-shaped, with both an 
> inner and outer edge). So instead, it draws "cuts" that go from the 
> inner to the outer edge. When anti-aliasing is turned on, there is a 
> slight overlap or "drawing twice" along this edge which creates what 
> looks like a line. Unfortunately, this can't be remedied by plotting 
> the contour fills and then plotting the contour edges over top (as is 
> done is contourf_demo.py).
> 
> As of matplotlib 0.98.x, matplotlib itself can handle compound paths, so 
> we no longer need the cuts. I've made a few attempts at updating the 
> contouring code to avoid them, but got nowhere. The contouring code is 
> very opaque, almost magical code, and most who've dared to go in have 
> barely made it out alive... ;) That said, a fresh pair of eyes may have 
> what it takes...
> 
> As for a workaround, you could render your contour as opaque, save that 
> out as an image and read it back in. The code to do that won't be 
> pretty, but it just might work.
> 
> Cheers,
> Mike
> 
> kippertoffee wrote:
>> Hello,
>>
>> I am attempting to overlay a filled contour over a custom image.
>>
>> I have managed to get something basic working, but i have encountered a
>> problem:
>>
>> When the contourf plot is set to semi-transparent there are visible lines
>> joining the bottom of the plot and the filled contour edges. I have
>> attached
>> an image of the plot.
>>
>> http://img232.imageshack.us/my.php?image=spambs6.png spam.png 
>>
>> The code i have used is below; please bear in mind I am not a programmer,
>> so
>> if the code seems botched, that's because it is.
>>
>> ###############################
>>
>> import matplotlib.pyplot as plt
>> from pylab import *
>> try:
>> import Image
>> except ImportError, exc:
>> raise SystemExit("PIL must be installed to run this example")
>>
>> lena = Image.open('lena.jpg')
>> dpi = rcParams['figure.dpi']
>> figsize = lena.size[0]/dpi, lena.size[1]/dpi
>>
>> fig = plt.figure(figsize=figsize)
>> #fig.patch.set_alpha(0.5)
>> ax = fig.add_subplot(111)
>> #ax.patch.set_alpha(0.5)
>>
>> ax.imshow(lena, origin='lower')
>>
>> ax.contourf(z2,[10,15,20,25,30,35,40,45,50,55,60,65],alpha=0.7)
>> show()
>> ############################
>>
>>
>> Can anyone help me with this problem?
>>
>> Thanks for reading,
>> Pete.
> 
> 
> 
-- 
View this message in context: http://www.nabble.com/Filled-contour-transparency-issue-tp18850187p18856313.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Wednesday 06 August 2008 09:24:18 Michael Droettboom wrote:
> (I don't know if the
> new masked arrays have a C API we could use -- the old ones apparently
> didn't.)
They don't. I thought about it before, but decided to forget about it until I 
could find a job where I could learn C and focus exclusively on that for a 
few months. Unlikely anytime soon.

On Tuesday 05 August 2008 22:25:30 Mark Bakker wrote:
> Can we do the same? I am sure we can (not sure we want, as Google has been
> somewhat difficult to people writing scripts to manipulate images from
> google maps).
I tried doing something similar to this a while ago. You can use gdal to point 
to your tile of interest (e.g., 
http://khm3.google.com/kh?v=30&hl=en&t=tqsrsstr), which is a JPG (or PNG, 
can't remember), and then plot the RGB using imshow(). Difficulty is how to 
get the tile (it is documented somewhere, but I don't know how to do it). 
This is some sample code that seems to work, and hopefully gets the ball 
rolling :)
import osgeo.gdal as gdal
g = gdal.Open ("http://khm3.google.com/kh?v=30&hl=en&t=tqsrsstr")
R = g.GetRasterBand(1).ReadAsArray()
G =g.GetRasterBand(2).ReadAsArray()
B =g.GetRasterBand(3).ReadAsArray()
RGB = np.array((256,256,3)) # Clearly, there must be a better way of doing 
this!
RGB[:,:,0] = R
RGB[:,:,1] = G
RGB[:,:,2] = B
[...]
-- 
NERC Centre for Terrestrial Carbon Dynamics,
Department of Geography, University College London
Gower Street, London WC1E 6BT, UK

Eric Firing wrote:
> John Hunter wrote:
> 
>> On Tue, Aug 5, 2008 at 3:46 PM, Mark Bakker <ma...@gm...> wrote:
>>
>> 
>>> But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.
>>>
>>> I know, I know, I can do this with masked arrays, but it cannot be that hard
>>> to make this work correctly, and wouldn't that be much nicer? Desirable?
>>> 
>> The question is: what should happen with inf? Do you know what matlab does?
>> 
>
> Matlab ignores it, same as with a nan.
>
> This needs a bit of thought and checking. Mike went to some trouble, I 
> believe, to make nans work without running everything through masked 
> arrays--whether this is actually *faster* than doing an initial masking 
> operation when needed and then using masked arrays everywhere internally 
> when bad values are present, I don't know. 
It definitely was faster at the time I implemented it (particularly as 
the arrays get larger). The difference is that masked arrays must be 
handled in Python, and converted to regular arrays before passing on to 
the Agg backend by performing a compress (which implies a memcpy) and 
inserting MOVETO codes in the appropriate place. (I don't know if the 
new masked arrays have a C API we could use -- the old ones apparently 
didn't.) 
With the Agg backend, NaNs are all handled in C code -- the iterator 
over the array just skips over them, so there's no memory copy. (The 
other backends still use Python, so the difference is probably a wash.)
> It is possible that 
> everything could be made to work with infs simply by changing all 
> "isnan(x)" to "~isfinite(x)", which has the advantage of being slightly 
> faster (surprisingly) as well as more general.
> 
As long as we can do the equivalent in C, that seems fine. _path.cpp's get_path_extents is probably the most important place to be updated -- it currently doesn't even support NaNs. And then, of course, we'll need to update the "isnan" stuff in agg_py_path_iterator.h
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

This is a known issue with the contouring code. It's borrowed from an 
earlier plotting package called GIST, and assumes that the renderer can 
not handle compound polygons (for example, donut-shaped, with both an 
inner and outer edge). So instead, it draws "cuts" that go from the 
inner to the outer edge. When anti-aliasing is turned on, there is a 
slight overlap or "drawing twice" along this edge which creates what 
looks like a line. Unfortunately, this can't be remedied by plotting 
the contour fills and then plotting the contour edges over top (as is 
done is contourf_demo.py).
As of matplotlib 0.98.x, matplotlib itself can handle compound paths, so 
we no longer need the cuts. I've made a few attempts at updating the 
contouring code to avoid them, but got nowhere. The contouring code is 
very opaque, almost magical code, and most who've dared to go in have 
barely made it out alive... ;) That said, a fresh pair of eyes may have 
what it takes...
As for a workaround, you could render your contour as opaque, save that 
out as an image and read it back in. The code to do that won't be 
pretty, but it just might work.
Cheers,
Mike
kippertoffee wrote:
> Hello,
>
> I am attempting to overlay a filled contour over a custom image.
>
> I have managed to get something basic working, but i have encountered a
> problem:
>
> When the contourf plot is set to semi-transparent there are visible lines
> joining the bottom of the plot and the filled contour edges. I have attached
> an image of the plot.
>
> http://img232.imageshack.us/my.php?image=spambs6.png spam.png 
>
> The code i have used is below; please bear in mind I am not a programmer, so
> if the code seems botched, that's because it is.
>
> ###############################
>
> import matplotlib.pyplot as plt
> from pylab import *
> try:
> import Image
> except ImportError, exc:
> raise SystemExit("PIL must be installed to run this example")
>
> lena = Image.open('lena.jpg')
> dpi = rcParams['figure.dpi']
> figsize = lena.size[0]/dpi, lena.size[1]/dpi
>
> fig = plt.figure(figsize=figsize)
> #fig.patch.set_alpha(0.5)
> ax = fig.add_subplot(111)
> #ax.patch.set_alpha(0.5)
>
> ax.imshow(lena, origin='lower')
>
> ax.contourf(z2,[10,15,20,25,30,35,40,45,50,55,60,65],alpha=0.7)
> show()
> ############################
>
>
> Can anyone help me with this problem?
>
> Thanks for reading,
> Pete.
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, 5 Aug 2008, John Hunter apparently wrote:
> Although intuitively I think of inf as very different from nan, my 
> default is to go with matlab like behavior in the absence 
> of compelling a argument otherwise.
gnuplot also ignores them.
(I am not arguing this is the correct behavior;
just providing a data point.)
Cheers,
Alan Isaac

A little follow-up.
When I use keyword argument inline=False, it doesn't remove the lines
without a label.
So it seems that when using inline=True the unlabeled contours get a white
box, but no label (because it doesn't fit) which essentially removes the
entire contour.
Mark
On Wed, Aug 6, 2008 at 2:27 PM, Mark Bakker <ma...@gm...> wrote:
> Hello list -
>
> There seems to be a bug in labeling contour lines.
> When I call clabel, it removes all contours that are not labeled (because
> the label doesn't fit on the section of contour, I presume).
> This seems like a bug to me (or a really odd feature).
>
> Easy example:
>
> >>> x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) )
> >>> z = log(x**2 + y**2)
> >>> cobj = contour(x,y,z)
> >>> cobj.clabel()
> <a list of 8 text.Text objects>
> >>> draw()
>
> And now all contours without a label are gone. On my machine it draws
> labels on contours from 1 through 5, and erases the contours in the middle
> of the plot with values -2, -1, and 0.
>
> Mark
>
>

Hello,
I am attempting to overlay a filled contour over a custom image.
I have managed to get something basic working, but i have encountered a
problem:
When the contourf plot is set to semi-transparent there are visible lines
joining the bottom of the plot and the filled contour edges. I have attached
an image of the plot.
http://img232.imageshack.us/my.php?image=spambs6.png spam.png 
The code i have used is below; please bear in mind I am not a programmer, so
if the code seems botched, that's because it is.
###############################
import matplotlib.pyplot as plt
from pylab import *
try:
 import Image
except ImportError, exc:
 raise SystemExit("PIL must be installed to run this example")
lena = Image.open('lena.jpg')
dpi = rcParams['figure.dpi']
figsize = lena.size[0]/dpi, lena.size[1]/dpi
fig = plt.figure(figsize=figsize)
#fig.patch.set_alpha(0.5)
ax = fig.add_subplot(111)
#ax.patch.set_alpha(0.5)
ax.imshow(lena, origin='lower')
ax.contourf(z2,[10,15,20,25,30,35,40,45,50,55,60,65],alpha=0.7)
show()
############################
Can anyone help me with this problem?
Thanks for reading,
Pete.
-- 
View this message in context: http://www.nabble.com/Filled-contour-transparency-issue-tp18850187p18850187.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hello list -
There seems to be a bug in labeling contour lines.
When I call clabel, it removes all contours that are not labeled (because
the label doesn't fit on the section of contour, I presume).
This seems like a bug to me (or a really odd feature).
Easy example:
>>> x,y = meshgrid( linspace(-10,10,50), linspace(-10,10,50) )
>>> z = log(x**2 + y**2)
>>> cobj = contour(x,y,z)
>>> cobj.clabel()
<a list of 8 text.Text objects>
>>> draw()
And now all contours without a label are gone. On my machine it draws labels
on contours from 1 through 5, and erases the contours in the middle of the
plot with values -2, -1, and 0.
Mark

Never mind, I found it.
The solution is:
cobj = contour(x,y,z)
cobj.clabel(manual=True)
How nice!
Mark
On Wed, Aug 6, 2008 at 10:05 AM, Mark Bakker <ma...@gm...> wrote:
> Hello list -
>
> I read that in 0.98.3 we can manually select contour label locations!
>
> I searched around, but couldn't find any instructions.
>
> Can anybody point me in the right direction?
>
> Thanks, Mark
>

Mark Bakker wrote:
> Can we set the markerspacing in mpl?
> 
> If I do
> 
> plot( linspace(0,10,100), 'o' )
You can try the following approach: First plot the line and then plot 
the markers separately (and set colors).
x = linspace(0,10,100)
y = x
plot(x, y, '-')
plot(x[::10], y[::10], linestyle='', marker='o')
Manuel
> I get 100 markers. What if I want to plot every tenth marker? Or better
> even, what if I want to have a certain spacing between markers.
> 
> I know how to work around this, of course (just plot every tenth point), but
> I was looking for a keyword argument or so. I thought that would exist and
> be useful.
> 
> Sorry to flood the list with questions this week.
> 
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Can we set the markerspacing in mpl?
If I do
plot( linspace(0,10,100), 'o' )
I get 100 markers. What if I want to plot every tenth marker? Or better
even, what if I want to have a certain spacing between markers.
I know how to work around this, of course (just plot every tenth point), but
I was looking for a keyword argument or so. I thought that would exist and
be useful.
Sorry to flood the list with questions this week.
Mark

Hello list -
I read that in 0.98.3 we can manually select contour label locations!
I searched around, but couldn't find any instructions.
Can anybody point me in the right direction?
Thanks, Mark

Thanks for stepping up to the plate, Eric.
I was asleep on this side of the ocean, so I didn't join in the discussion.
>From a functionality point of view, it seems to be a good idea to me not to
plot nans (that would actually be impossible) and not to plot infs. The
latter are indeed different than nans, but they are the same in that we
cannot plot them. And it will shield the pylab user from having to use
masked arrrays when it is not really necessary.
Eric - you think this will also work for contour, or do we have to keep
using masked arrays there? If this works for contouring, what will you do
with -inf and +inf in contourf?
Thanks, Mark
On Wed, Aug 6, 2008 at 5:54 AM, Eric Firing <ef...@ha...> wrote:
> John Hunter wrote:
>
>> On Tue, Aug 5, 2008 at 7:03 PM, Eric Firing <ef...@ha...> wrote:
>>
>> Matlab ignores it, same as with a nan.
>>>
>>
>> Although intuitively I think of inf as very different from nan, my
>> default is to go with matlab like behavior in the absence of
>> compelling a argument otherwise. I won't be providing that argument
>> for isnan/inf, so if someone wants mpl to behave differently, step up
>> and argue why.
>>
>> This needs a bit of thought and checking. Mike went to some trouble, I
>>> believe, to make nans work without running everything through masked
>>> arrays--whether this is actually *faster* than doing an initial masking
>>> operation when needed and then using masked arrays everywhere internally
>>> when bad values are present, I don't know. It is possible that
>>> everything
>>> could be made to work with infs simply by changing all "isnan(x)" to
>>> "~isfinite(x)", which has the advantage of being slightly faster
>>> (surprisingly) as well as more general.
>>>
>>
>> Perhaps we should centralize this functionality to a cbook analogue of
>> "is_string_like" or "iterable" called "is_plottable" or something to
>> that effect. That way, people writing plotting functions will not
>> have to decide if the inclusion criteria is isnan or ~isinfinite, but
>> instead can simply rely on the cbook function (with a moderate
>> performance hit for the extra function call). We will likely need a
>> version for a single axis (x or y) as well as for points ( (x,y)
>> tuples) -- these ideally will support scalar or array inputs, or we
>> can provide array versions of each. There are only a few modules
>> using isnan currently (axes, contour, mlab and path) so it would not
>> be too difficult to centralize this functionality. Do you want to
>> take the lead on this one, Eric?
>>
>
> Yes, but I think that the cbook approach is overkill in this case, and
> counterproductive. Maybe I should add a bit to the coding guide, but we
> really don't need another wrapper just to handle nans and infs.
>
> I think I see how to fix everything, and improve speed, with only a few
> changes, including a couple in src.
>
> Eric
>
>

John Hunter wrote:
> On Tue, Aug 5, 2008 at 7:03 PM, Eric Firing <ef...@ha...> wrote:
> 
>> Matlab ignores it, same as with a nan.
> 
> Although intuitively I think of inf as very different from nan, my
> default is to go with matlab like behavior in the absence of
> compelling a argument otherwise. I won't be providing that argument
> for isnan/inf, so if someone wants mpl to behave differently, step up
> and argue why.
> 
>> This needs a bit of thought and checking. Mike went to some trouble, I
>> believe, to make nans work without running everything through masked
>> arrays--whether this is actually *faster* than doing an initial masking
>> operation when needed and then using masked arrays everywhere internally
>> when bad values are present, I don't know. It is possible that everything
>> could be made to work with infs simply by changing all "isnan(x)" to
>> "~isfinite(x)", which has the advantage of being slightly faster
>> (surprisingly) as well as more general.
> 
> Perhaps we should centralize this functionality to a cbook analogue of
> "is_string_like" or "iterable" called "is_plottable" or something to
> that effect. That way, people writing plotting functions will not
> have to decide if the inclusion criteria is isnan or ~isinfinite, but
> instead can simply rely on the cbook function (with a moderate
> performance hit for the extra function call). We will likely need a
> version for a single axis (x or y) as well as for points ( (x,y)
> tuples) -- these ideally will support scalar or array inputs, or we
> can provide array versions of each. There are only a few modules
> using isnan currently (axes, contour, mlab and path) so it would not
> be too difficult to centralize this functionality. Do you want to
> take the lead on this one, Eric?
Yes, but I think that the cbook approach is overkill in this case, and 
counterproductive. Maybe I should add a bit to the coding guide, but we 
really don't need another wrapper just to handle nans and infs.
I think I see how to fix everything, and improve speed, with only a few 
changes, including a couple in src.
Eric

On Tue, Aug 5, 2008 at 6:26 PM, Elfnor <el...@gm...> wrote:
> This would be really useful for implementing a user image crop function,
> similar to matlab's imcrop for example.
David, since you are a recent matlab user and are deeply versed in the
blocking code: how hard would it be to simply provide a (mostly)
matlab compatible imcrop function, and is this something you are
interested in doing?
JDH

On Tue, Aug 5, 2008 at 7:03 PM, Eric Firing <ef...@ha...> wrote:
> Matlab ignores it, same as with a nan.
Although intuitively I think of inf as very different from nan, my
default is to go with matlab like behavior in the absence of
compelling a argument otherwise. I won't be providing that argument
for isnan/inf, so if someone wants mpl to behave differently, step up
and argue why.
> This needs a bit of thought and checking. Mike went to some trouble, I
> believe, to make nans work without running everything through masked
> arrays--whether this is actually *faster* than doing an initial masking
> operation when needed and then using masked arrays everywhere internally
> when bad values are present, I don't know. It is possible that everything
> could be made to work with infs simply by changing all "isnan(x)" to
> "~isfinite(x)", which has the advantage of being slightly faster
> (surprisingly) as well as more general.
Perhaps we should centralize this functionality to a cbook analogue of
"is_string_like" or "iterable" called "is_plottable" or something to
that effect. That way, people writing plotting functions will not
have to decide if the inclusion criteria is isnan or ~isinfinite, but
instead can simply rely on the cbook function (with a moderate
performance hit for the extra function call). We will likely need a
version for a single axis (x or y) as well as for points ( (x,y)
tuples) -- these ideally will support scalar or array inputs, or we
can provide array versions of each. There are only a few modules
using isnan currently (axes, contour, mlab and path) so it would not
be too difficult to centralize this functionality. Do you want to
take the lead on this one, Eric?
JDH

John Hunter wrote:
> On Tue, Aug 5, 2008 at 3:46 PM, Mark Bakker <ma...@gm...> wrote:
> 
>> But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.
>>
>> I know, I know, I can do this with masked arrays, but it cannot be that hard
>> to make this work correctly, and wouldn't that be much nicer? Desirable?
> 
> The question is: what should happen with inf? Do you know what matlab does?
Matlab ignores it, same as with a nan.
This needs a bit of thought and checking. Mike went to some trouble, I 
believe, to make nans work without running everything through masked 
arrays--whether this is actually *faster* than doing an initial masking 
operation when needed and then using masked arrays everywhere internally 
when bad values are present, I don't know. It is possible that 
everything could be made to work with infs simply by changing all 
"isnan(x)" to "~isfinite(x)", which has the advantage of being slightly 
faster (surprisingly) as well as more general.
Eric
> 
> JDH
> 
> -------------------------------------------------------------------------
> 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-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

The new ginput function is great.
Would it be possible to have a version that looks to the user like a
RectangleSelector widget but works for the programmer like ginput? That is,
it returns the coordinates of the rectangle. 
This would be really useful for implementing a user image crop function,
similar to matlab's imcrop for example.
One can functionally do this with:
import os.path, sys
import pylab
import Image
img = Image.open('test_image.png')
fig = pylab.imshow(img, origin='lower')
print "Please click on top left, bottom right of crop area"
x = pylab.ginput(2)
#PIL and matplotlib have different origin
roi = img.crop([int(x[0][0]),int(img.size[1]-x[0][1]),
int(x[1][0]),int(img.size[1]-x[1][1])])
filenm = os.path.join(sys.path[0], 'crop_image.png')
roi.save(filenm)
show()
But users expect a rectangle for cropping.
I've had a look a the BlockingMouseInput class but its all a bit beyond me
at the moment.
Eleanor
-- 
View this message in context: http://www.nabble.com/Feature-Request%3A-RectangleSelector-BlockingInput-tp18841798p18841798.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Tue, Aug 5, 2008 at 3:46 PM, Mark Bakker <ma...@gm...> wrote:
> But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.
>
> I know, I know, I can do this with masked arrays, but it cannot be that hard
> to make this work correctly, and wouldn't that be much nicer? Desirable?
The question is: what should happen with inf? Do you know what matlab does?
JDH

Ewald,
It is very much a work in progress (and poorly named) but you can check out a project of mine:
http://code.google.com/p/subplot/
I created a custom matplotlib widget that you can promote from a regular widget in Designer. I hope it helps, let me know if you have any questions. The ui files are also included in the SVN. One thing to note there was a recent change to the Qt backend that altered the nature of the toolbar so you may want to comment that part out if you are using the latest matplotlib. If it is a must have I think I'm sure I could update the code when I find some time (Currently, I'm using v 0.91 I believe). Good luck.
Cheers,
Brian
--- On Tue, 8/5/08, Ewald Zietsman <ewa...@gm...> wrote:
From: Ewald Zietsman <ewa...@gm...>
Subject: [Matplotlib-users] Using matplotlib in Qt4/Qt4 Designer
To: mat...@li...
Date: Tuesday, August 5, 2008, 10:06 AM
Hi All,
I'd like to use a matplotlib widget in a GUI app I'm working on. I have tried qwt but I know matplotlib a lot better and would like to use it instead. Is there anybody who have done this before? More specifically, does anyone know how to add a matplotlib widget as a custom widget in qt4 designer?
Any help will be greatly appreciated,
Ewald Zietsman
-------------------------------------------------------------------------
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-users mailing list
Mat...@li...
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
 

Hello list -
There is a recent matlab script floating around that downloads an image from
google map and plots it in a matlab figure.
Can we do the same? I am sure we can (not sure we want, as Google has been
somewhat difficult to people writing scripts to manipulate images from
google maps).
My second question is: Has someone done it and does he/she want to share?
Thanks, Mark

I have a question about plotting an array with an inf.
For example:
y = np.array([2.,1.,0,1.,2.])
y = 1.0 / y
So y is array([ 0.5, 1. , Inf, 1. , 0.5])
When I plot this, I get an error, of which the last line is:
OverflowError: math range error
I presume the problem is using the autoscale or something like that to set
the data limits.
But if I replace the Inf by a nan: y[2] = np.nan, then it plots fine.
I know, I know, I can do this with masked arrays, but it cannot be that hard
to make this work correctly, and wouldn't that be much nicer? Desirable?
Mark