matplotlib-devel Mailing List for matplotlib (Page 2)

On Sunday, December 11, 2011, Mike Kaufman <mc...@gm...> wrote:
>
> Both Skim 1.3.18 and Preview on OSX 10.6.8 show this. I'm using gv 3.7.1
as a postscript viewer.
>
> M
>

Could you send the PDF and a screen capture of what you see as a png so we
can check?  The mac's Preview program was the one that I found to be faulty.

Ben Root

Both Skim 1.3.18 and Preview on OSX 10.6.8 show this. I'm using gv 3.7.1 
as a postscript viewer.

M

> Mike,
>
> I was recently tracking down a somewhat similar problem a few days ago.
>   It turned out not to have been related to mpl at all, but rather a bug
> in the PDF viewer.  Which viewer are you using so that I can make sure
> that I check something different?
>
> Ben Root

On Sunday, December 11, 2011, Mike Kaufman <mc...@gm...> wrote:
>
> for this code:
>
> clf()
> plot(arange(5),arange(5), 'y.', ms=30.0, mew=0, mec='r')
> draw()
> savefig('mew.pdf')
> savefig('mew.ps')
>
> The pdf and ps show a marker edge even though the gtkagg window doesn't
> (neither do the png or svg savefigures).
> The marker edge in the ps is black instead of red.
>
> I haven't done a git-bisect, but
> f1388ee3c3a5c72af00701e5a623545f0df2f426 from April 11 seems to have the
> pdf problem but the ps doesn't have a marker edge.
>
> M
>

Mike,

I was recently tracking down a somewhat similar problem a few days ago.  It
turned out not to have been related to mpl at all, but rather a bug in the
PDF viewer.  Which viewer are you using so that I can make sure that I
check something different?

Ben Root

for this code:

clf()
plot(arange(5),arange(5), 'y.', ms=30.0, mew=0, mec='r')
draw()
savefig('mew.pdf')
savefig('mew.ps')

The pdf and ps show a marker edge even though the gtkagg window doesn't 
(neither do the png or svg savefigures).
The marker edge in the ps is black instead of red.

I haven't done a git-bisect, but
f1388ee3c3a5c72af00701e5a623545f0df2f426 from April 11 seems to have the 
pdf problem but the ps doesn't have a marker edge.

M

For the 3rd contour example at
http://matplotlib.sourceforge.net/mpl_toolkits/mplot3d/tutorial.html , the
code (
http://matplotlib.sourceforge.net/mpl_examples/mplot3d/contour3d_demo3.py )
should be changed from ax.set_xlim(-40, 40)
to ax.set_xlim3d(-40, 40) for the code to work. Same for ylim and zlim.
Probably the syntax was just updated since that example was made. Of course
any other examples on that page which use xlim should also be fixed.

Best,
Chris
-- 
View this message in context: http://old.nabble.com/mplot3d-tutorial%2C-demo-code-needs-slight-fix-tp32952017p32952017.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Pull request at <https://github.com/matplotlib/matplotlib/pull/616>

Christoph


On 12/9/2011 12:11 PM, Christoph Gohlke wrote:
> Hello,
>
> while working on the scikits-image io plugin system, I noticed some
> issues with matplotlib's imread function. I have a patch for all these
> issues and will submit a PR but wanted to check on the list first.
>
>
> 1) imread does not properly detect the file type if an open file handle
> is used.
>
>>>> lena = pylab.imread(matplotlib.cbook.get_sample_data('lena.jpg'))
> Traceback (most recent call last):
>     File "<stdin>", line 1, in<module>
>     File "X:\Python27\lib\site-packages\matplotlib\pyplot.py", line 1740,
> in imread
>       return _imread(*args, **kwargs)
>     File "X:\Python27\lib\site-packages\matplotlib\image.py", line 1207,
> in imread
>       return handler(fname)
> RuntimeError: _image_module::readpng: file not recognized as a PNG file
>
>
> 2) imread does not properly convert uint16 images to uint8 as reported
> on the scikits-image ML
> <https://groups.google.com/forum/#!topic/scikits-image/O47tNU01kLA>.
>
>
> 3) Any non-PNG image loaded with imread is displayed upside-down in imshow:
>
>>>> imshow(imread("lena.jpg")); show()
>
> A solution is to pass `origin='lower'` to imshow for non-PNG images. But
> is there a reason for this asymmetry? Any image loaded with PIL is
> explicitly flipped upside-down at
> <https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/image.py#L1267>.
>
>
> Christoph
>
>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Ben,

Thanks for the reply. I definitely like your idea. Seems like we could
include some logic in axes.errorbar to look at the shapes of xerr and
yerr in a similar fashion to what I propose for axes.boxplots,
allowing the user to have custom lower and upper errors for each data
point (in a time series as I would use it).

I'll try to bang that out this weekend while this is still fresh.
-p


On Fri, Dec 9, 2011 at 1:29 PM, Benjamin Root <ben...@ou...> wrote:
> On Thu, Dec 8, 2011 at 10:45 AM, Paul Hobson <pmh...@gm...> wrote:
>>
>> Matplotlib gurus:
>>
>> I took at stab at the git work flow and incorporated my personal
>> modifications to the boxplot function. Github's diff can be found
>> here:
>> https://github.com/phobson/matplotlib/compare/master...manual_boxplots
>>
>> In summary, if your data is MxN, you can manually specify medians and
>> the confidence intervals around the medians using Nx1 and Nx2 arrays,
>> respectively. Alternatively, you can use lists or tuples and use Nones
>> if you want to specify those values only for some columns in your MxN
>> data set. In other words, with an Mx5 data array, you can specify
>> conf_intervals=[(ci1a,ci2a), (ci1b,ci2b), (ci1c,ci2c), None,
>> (ci1e,ci2e)]. Within the conf_intervals "array", the CIs can be listed
>> in any order as I use np.max() and np.min() to pull the upper and
>> lower values, respectively.
>>
>> The motivation behind this is that sometimes I need the confidence
>> levels to be different than 95%, and also that I compute those
>> confidence intervals with a bootstrapping routine that is more robust
>> than mpl-compatible one I submitted some time ago.
>>
>> I hope y'all find this to be a useful contribution. I'm an avid
>> matplotlib user. It really is a wonderful tool.
>>
>> Cheers,
>> paul h
>>
>
> Paul,
>
> Interesting.  I haven't had much time to really look over your changes, but
> I have been wondering if the errorbar() and boxplot() functions could be
> treated as two different ways to display similar information.  Therefore,
> perhaps their call signatures could be made more similar to each other.
> What do you think?
>
> Ben Root
>

On Thu, Dec 8, 2011 at 10:45 AM, Paul Hobson <pmh...@gm...> wrote:

> Matplotlib gurus:
>
> I took at stab at the git work flow and incorporated my personal
> modifications to the boxplot function. Github's diff can be found
> here:
> https://github.com/phobson/matplotlib/compare/master...manual_boxplots
>
> In summary, if your data is MxN, you can manually specify medians and
> the confidence intervals around the medians using Nx1 and Nx2 arrays,
> respectively. Alternatively, you can use lists or tuples and use Nones
> if you want to specify those values only for some columns in your MxN
> data set. In other words, with an Mx5 data array, you can specify
> conf_intervals=[(ci1a,ci2a), (ci1b,ci2b), (ci1c,ci2c), None,
> (ci1e,ci2e)]. Within the conf_intervals "array", the CIs can be listed
> in any order as I use np.max() and np.min() to pull the upper and
> lower values, respectively.
>
> The motivation behind this is that sometimes I need the confidence
> levels to be different than 95%, and also that I compute those
> confidence intervals with a bootstrapping routine that is more robust
> than mpl-compatible one I submitted some time ago.
>
> I hope y'all find this to be a useful contribution. I'm an avid
> matplotlib user. It really is a wonderful tool.
>
> Cheers,
> paul h
>
>
Paul,

Interesting.  I haven't had much time to really look over your changes, but
I have been wondering if the errorbar() and boxplot() functions could be
treated as two different ways to display similar information.  Therefore,
perhaps their call signatures could be made more similar to each other.
What do you think?

Ben Root

Hello,

while working on the scikits-image io plugin system, I noticed some 
issues with matplotlib's imread function. I have a patch for all these 
issues and will submit a PR but wanted to check on the list first.


1) imread does not properly detect the file type if an open file handle 
is used.

>>> lena = pylab.imread(matplotlib.cbook.get_sample_data('lena.jpg'))
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "X:\Python27\lib\site-packages\matplotlib\pyplot.py", line 1740, 
in imread
     return _imread(*args, **kwargs)
   File "X:\Python27\lib\site-packages\matplotlib\image.py", line 1207, 
in imread
     return handler(fname)
RuntimeError: _image_module::readpng: file not recognized as a PNG file


2) imread does not properly convert uint16 images to uint8 as reported 
on the scikits-image ML 
<https://groups.google.com/forum/#!topic/scikits-image/O47tNU01kLA>.


3) Any non-PNG image loaded with imread is displayed upside-down in imshow:

>>> imshow(imread("lena.jpg")); show()

A solution is to pass `origin='lower'` to imshow for non-PNG images. But 
is there a reason for this asymmetry? Any image loaded with PIL is 
explicitly flipped upside-down at 
<https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/image.py#L1267>.


Christoph

Matplotlib gurus:

I took at stab at the git work flow and incorporated my personal
modifications to the boxplot function. Github's diff can be found
here:
https://github.com/phobson/matplotlib/compare/master...manual_boxplots

In summary, if your data is MxN, you can manually specify medians and
the confidence intervals around the medians using Nx1 and Nx2 arrays,
respectively. Alternatively, you can use lists or tuples and use Nones
if you want to specify those values only for some columns in your MxN
data set. In other words, with an Mx5 data array, you can specify
conf_intervals=[(ci1a,ci2a), (ci1b,ci2b), (ci1c,ci2c), None,
(ci1e,ci2e)]. Within the conf_intervals "array", the CIs can be listed
in any order as I use np.max() and np.min() to pull the upper and
lower values, respectively.

The motivation behind this is that sometimes I need the confidence
levels to be different than 95%, and also that I compute those
confidence intervals with a bootstrapping routine that is more robust
than mpl-compatible one I submitted some time ago.

I hope y'all find this to be a useful contribution. I'm an avid
matplotlib user. It really is a wonderful tool.

Cheers,
paul h

On 12/7/11 10:27 PM, Chris Barker wrote:
> On 12/5/11 9:49 PM, Jason Grout wrote:
>> Has anyone ever worked on a backend that generates javascript code for
>> one of the javascript plotters out there (like jsxgraph or flot)?
>> Alternatively, I suppose we could generate an svg or html5 plot and then
>> accompany it with the javascript code to trace the function, etc.
>
> Someone has worked on a html5 back-end, It was jsut discussed a bit on
> the thread "Using the Agg renderer by itself"
>
> Here's a cut and paste:
>
> On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
>   >
>   >  Ben is referring to mplh5canvas, available at
>   >  http://code.google.com/p/mplh5canvas/. The main advantage of this
>   >  approach is interactive zooming of plots within the browser. If this is
>   >  not important to you, it will probably be faster to generate static PNGs
>   >  or SVGs.
>   >
>   >  The HTML5 backend should be easy to try out, as it is a pure Python
>   >  package with no onerous dependencies.
>   >

Michael Droettboom played with this a little at the Sage Days in March, 
IIRC, and I seem to think he also whipped up an interactive demo using 
svg plots.  Michael, do you remember what your conclusions were?

Thanks,

Jason

On 12/5/11 9:49 PM, Jason Grout wrote:
> Has anyone ever worked on a backend that generates javascript code for
> one of the javascript plotters out there (like jsxgraph or flot)?
> Alternatively, I suppose we could generate an svg or html5 plot and then
> accompany it with the javascript code to trace the function, etc.

Someone has worked on a html5 back-end, It was jsut discussed a bit on 
the thread "Using the Agg renderer by itself"

Here's a cut and paste:

On 11/27/11 12:33 PM, Ludwig Schwardt wrote:
 >
 > Ben is referring to mplh5canvas, available at
 > http://code.google.com/p/mplh5canvas/. The main advantage of this
 > approach is interactive zooming of plots within the browser. If this is
 > not important to you, it will probably be faster to generate static PNGs
 > or SVGs.
 >
 > The HTML5 backend should be easy to try out, as it is a pure Python
 > package with no onerous dependencies.
 >

-Chris







-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

On Wed, Dec 7, 2011 at 8:56 AM, Michael Droettboom <md...@st...> wrote:

>  On 12/06/2011 10:10 PM, Benjamin Root wrote:
>
>
>
> On Tuesday, December 6, 2011, Michael Droettboom <md...@st...> wrote:
> > Yesterday I managed to accidentally move the v1.1.x branch pointer to
> > point to master.  I have since moved it back, but you may need to rebase
> > if you have any active branches based on the (wrong) v1.1.x branch.  The
> > following should suffice:
> >
> >    git fetch upstream
> >    git rebase upstream/v1.1.x
> >
> > Mike
> >
>
> I am getting a whole bunch of conflict errors.  I wonder if it is because
> I rebased already when v1.1.x was pointed to master?  Are we sure that
> v1.1.x is ok?  If so, I could just delete my copy and refetch it from
> upstream?
>
> It's quite possible to get conflict errors if you rebased on v1.1.x when
> it was the same as master and are now going back.  I'm really sorry for the
> inconvenience this mistake caused.
>
> But it should be possible to reapply your new commits on top of v1.1.x
> without too much trouble.  Feel free to contact me off list and maybe we
> can get to the bottom of what's going on for you.
>
> Cheers,
> Mike
>

As a note, it appears that doing "git rebase upstream/v1.1.x -s ours"
produces the correct result.  Although, I think it might have set my push
remote to point to the matplotlib repo and not my own github repo, but I
might be wrong on that.

Ben Root

On 12/06/2011 10:10 PM, Benjamin Root wrote:
>
>
> On Tuesday, December 6, 2011, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
> > Yesterday I managed to accidentally move the v1.1.x branch pointer to
> > point to master.  I have since moved it back, but you may need to rebase
> > if you have any active branches based on the (wrong) v1.1.x branch.  The
> > following should suffice:
> >
> >    git fetch upstream
> >    git rebase upstream/v1.1.x
> >
> > Mike
> >
>
> I am getting a whole bunch of conflict errors.  I wonder if it is 
> because I rebased already when v1.1.x was pointed to master?  Are we 
> sure that v1.1.x is ok?  If so, I could just delete my copy and 
> refetch it from upstream?
It's quite possible to get conflict errors if you rebased on v1.1.x when 
it was the same as master and are now going back.  I'm really sorry for 
the inconvenience this mistake caused.

But it should be possible to reapply your new commits on top of v1.1.x 
without too much trouble.  Feel free to contact me off list and maybe we 
can get to the bottom of what's going on for you.

Cheers,
Mike

On Tuesday, December 6, 2011, Michael Droettboom <md...@st...> wrote:
> Yesterday I managed to accidentally move the v1.1.x branch pointer to
> point to master.  I have since moved it back, but you may need to rebase
> if you have any active branches based on the (wrong) v1.1.x branch.  The
> following should suffice:
>
>    git fetch upstream
>    git rebase upstream/v1.1.x
>
> Mike
>

I am getting a whole bunch of conflict errors.  I wonder if it is because I
rebased already when v1.1.x was pointed to master?  Are we sure that v1.1.x
is ok?  If so, I could just delete my copy and refetch it from upstream?

Ben Root

I'm not sure if this is the right place to report this, but the link
to Python(x, y) on
http://matplotlib.sourceforge.net/users/installing.html points to a
page that no longer exists.

--
Jim Hunziker

Yesterday I managed to accidentally move the v1.1.x branch pointer to 
point to master.  I have since moved it back, but you may need to rebase 
if you have any active branches based on the (wrong) v1.1.x branch.  The 
following should suffice:

    git fetch upstream
    git rebase upstream/v1.1.x

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Dan Drake on the Sage mailing list pointed out that google now has the 
ability to plot graphs:

https://www.google.com/search?q=sin(x)%2C+cos(x)

A nice javascript thing is generated and has automatic tracing, zooming, 
and panning turned on.  Of course, those are things we'd all love in the 
Sage project for our matplotlib-based graphics :).

Has anyone ever worked on a backend that generates javascript code for 
one of the javascript plotters out there (like jsxgraph or flot)? 
Alternatively, I suppose we could generate an svg or html5 plot and then 
accompany it with the javascript code to trace the function, etc.  Has 
anyone experimented with writing a javascript "viewer" for graphics, 
having some of the same features that the standard graphics window that 
pops up under qt, wx, gtk, etc.?

I think this would be interesting to work on next summer if I have extra 
time.

Thanks,

Jason

There seems to be a bug in the "transform" argument for CircleCollection,
EllipseCollection, and RegularPolyCollection. These classes override any
transform passed on instantiation and uses the IdentityTransform instead.

Take, for example, the init method CircleCollection:

#~~~
    def __init__(self, sizes, **kwargs):
        """
        *sizes*
            Gives the area of the circle in points^2

        %(Collection)s
        """
        Collection.__init__(self,**kwargs)
        self._sizes = sizes
        self.set_transform(transforms.IdentityTransform())
        self._paths = [mpath.Path.unit_circle()]
#~~~

If "transform" is passed as a kwarg, it gets updated by the call to
``Collection.__init__`` (this update is done in Artist, which is a parent
class of Collection). But a couple lines after that, the transform is
manually reset to the IdentityTransform. Is this a bug?

As it stands, setting the transform kwarg does nothing (and doesn't
complain), so I have to call the set_transform method after creating the
collection (not a big deal, but it's confusing that the first option
doesn't work).

A couple of notes:
* Artist already defaults to setting Artist._transform (and hence
Collection._transform) to the IdentityTransform.
* Nevertheless, the set_transform line above is *not* a do-nothing line:
not only does set_transform set the _transform attribute, it also sets the
_transformSet attribute.

A few solutions:
* Replace the set_transform line with ``self._transformSet = True``.
(preserves current behavior, without overriding a user-prescribed transform)
* Replace transform passed to self.set_transform with self.get_transform.
(same behavior as above.)
* Just remove the set_transform line. This changes the behavior since
self._transformSet is left False, but I'm not sure what the correct
behavior is.

-Tony