matplotlib-devel Mailing List for matplotlib (Page 10)

Ah -- I didn't look at Agg 2.5 at all because of the licensing issues.  
Isn't this a no-go for us because it's GPL'd?

Cheers,
Mike

John Hunter wrote:
> On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:
>
>   
>> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
>> map, and here we need to at least interpolate between the three points of a
>> triangle.  It's not impossible, as it's easy enough to make a custom shader,
>> it's just that the gradient code won't help us.
>>     
>
> I checked in with the antigrain mailing list, as was pointed to
> examples/gouraud.cpp.  This looks like what we want, no?
>
> wget http://www.antigrain.com/agg-2.5.tar.gz
> tar xvfz agg-2.5.tar.gz
> cd agg-2.5
> make
> cd examples/X11/
> make gouraud
> ./gouraud
>   
>
> ------------------------------------------------------------------------
>

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Aug 6, 2009 at 1:53 PM, Michael Droettboom<md...@st...> wrote:

> Even with this, the gradient infrastructure in Agg assumes a one-dimensional
> map, and here we need to at least interpolate between the three points of a
> triangle.  It's not impossible, as it's easy enough to make a custom shader,
> it's just that the gradient code won't help us.

I checked in with the antigrain mailing list, as was pointed to
examples/gouraud.cpp.  This looks like what we want, no?

wget http://www.antigrain.com/agg-2.5.tar.gz
tar xvfz agg-2.5.tar.gz
cd agg-2.5
make
cd examples/X11/
make gouraud
./gouraud

On Thu, Aug 6, 2009 at 11:31 PM, Ryan Wagner<rw...@vn...> wrote:
>>Does your workaround work for all supported backends, and with alpha
>>less than 1?  If so, what is it?
>
> I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!

I agree with Eric that lw=0 should mean draw no line at all.  In
postscript, linewidth=0 means "draw the thinnest line you can" but
early on we overrode this behavior to make the postscript backend
consistent with other mpl backends, so that linewidth=0 means draw no
line at all.  I think 3D should be consistent with this.  But setting
the edgecolors=facecolors should be fine too -- either of these or
both can be tested to see what gives the best behavior at the edges.

JDH

Jae-Joon Lee wrote:
> My understanding is that MOVETO in the middle of the path serve as a
> CLOSEPOLY when the path is filled. So, I don't think it actually
> matters how holes are connected each other. And as you can see, the
> largest hole is actually composed of three different polygons that
> overlaps, and the funny pattern is due to this overlaps.
> 
> The attached is my attempt to solve this problem. "remove_cuts"
> removes the cuts in a way that a hole becomes a single closed polygon,
> although I'm not sure if the code is rigorous enough. It seems to work
> okay for your sample data. It assumes that cuts are always vertical
> lines but this assumption can be dropped if we do bookkepping of all
> the path segments.
> I hope the code turns out to be work okay in general.
> 
> Ideally, it would be better if something similar would be done inside
> the contouring routine.

JJ,

Thank you.  In fact, earlier today I wrote a python class that handles 
the reorganization of the paths, and it seems to work fine--but it is 
much too slow for complicated contour plots.  Therefore I started on a C 
implementation inside cntr.c, directly generating the verts and codes 
that will be input to Path.  I think I have the main structure in place, 
but finishing and debugging will take some time. I hope to be able to 
commit it in a few days.

Eric

> 
> -JJ
> 
> 
> 
> On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing<ef...@ha...> wrote:
>> Mike,
>>
>> When I eliminate the cuts from filled contour paths, I do find pathological
>> cases where the filling works correctly with the cuts in place, but not
>> without them.  Attached are a data file and a script to plot it,
>> illustrating the problem.  Is this due to a known limitation of filled
>> paths?  In the example, the top two holes are connected to the lower hole,
>> instead of being connected directly to the outer boundary of the filled
>> region.  Is this illegal?  If so, I think we are stuck, because rearranging
>> the paths that cntr makes to eliminate this type of case would likely be
>> very difficult.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>> trial. Simplify your report design, integration and deployment - and focus
>> on
>> what you do best, core application coding. Discover what's new with
>> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>>
>> ------------------------------------------------------------------------
>>

My understanding is that MOVETO in the middle of the path serve as a
CLOSEPOLY when the path is filled. So, I don't think it actually
matters how holes are connected each other. And as you can see, the
largest hole is actually composed of three different polygons that
overlaps, and the funny pattern is due to this overlaps.

The attached is my attempt to solve this problem. "remove_cuts"
removes the cuts in a way that a hole becomes a single closed polygon,
although I'm not sure if the code is rigorous enough. It seems to work
okay for your sample data. It assumes that cuts are always vertical
lines but this assumption can be dropped if we do bookkepping of all
the path segments.
I hope the code turns out to be work okay in general.

Ideally, it would be better if something similar would be done inside
the contouring routine.

-JJ



On Thu, Aug 6, 2009 at 1:58 PM, Eric Firing<ef...@ha...> wrote:
> Mike,
>
> When I eliminate the cuts from filled contour paths, I do find pathological
> cases where the filling works correctly with the cuts in place, but not
> without them.  Attached are a data file and a script to plot it,
> illustrating the problem.  Is this due to a known limitation of filled
> paths?  In the example, the top two holes are connected to the lower hole,
> instead of being connected directly to the outer boundary of the filled
> region.  Is this illegal?  If so, I think we are stuck, because rearranging
> the paths that cntr makes to eliminate this type of case would likely be
> very difficult.
>
> Eric
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

> On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rw...@vn...> wrote:
>> When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
>>
>> http://static.ryanjwagner.com/mpl_patches/lw0.png
>>
>> I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
>>

>Does your workaround work for all supported backends, and with alpha
>less than 1?  If so, what is it?

I believe it will... it is to set the edgecolors (RGBA) of the polygons to that of the facecolors. I will certainly test it on all backends and with several test cases before submitting anything, but it looks promising so far!

>> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
>>
>> Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
>
> Perhaps leaving it as it is today for lw=0, but having your behavior
> be the result for lw=None?  I can see people wanting the very fine
> grid that lw=0 gives today, and lw=None to me seems to be very
> explicitly saying 'no lines'.

>Except that in typical mpl usage, None means use a default.
>For colors, 'none' (a string) means no color, so a line should not be
>drawn.  Elsewhere in mpl, lw=0 also means "don't draw it at all", so it
>seems right to me that it should do the same for 3-D.

Seems like we need more discussion about this... anyone else want to chime in? I do like Fernando's idea if only to not break backwards compatability...

>Eric

>
> Just an idea...
>
> Cheers,
>
> f
>
> ps - Congrats to all on the release!  You've all done an absolutely
> terriffic job, and the benefits are already becoming obvious with
> these new ideas and contributions.  We'll have to celebrate at scipy
> :)
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Fernando Perez wrote:
> On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rw...@vn...> wrote:
>> When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
>>
>> http://static.ryanjwagner.com/mpl_patches/lw0.png
>>
>> I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
>>

Does your workaround work for all supported backends, and with alpha 
less than 1?  If so, what is it?

>> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
>>
>> Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?
> 
> Perhaps leaving it as it is today for lw=0, but having your behavior
> be the result for lw=None?  I can see people wanting the very fine
> grid that lw=0 gives today, and lw=None to me seems to be very
> explicitly saying 'no lines'.

Except that in typical mpl usage, None means use a default.
For colors, 'none' (a string) means no color, so a line should not be 
drawn.  Elsewhere in mpl, lw=0 also means "don't draw it at all", so it 
seems right to me that it should do the same for 3-D.

Eric

> 
> Just an idea...
> 
> Cheers,
> 
> f
> 
> ps - Congrats to all on the release!  You've all done an absolutely
> terriffic job, and the benefits are already becoming obvious with
> these new ideas and contributions.  We'll have to celebrate at scipy
> :)
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, Aug 6, 2009 at 4:11 PM, Ryan Wagner<rw...@vn...> wrote:
> When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:
>
> http://static.ryanjwagner.com/mpl_patches/lw0.png
>
> I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:
>
> http://static.ryanjwagner.com/mpl_patches/lw0_fix.png
>
> Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?

Perhaps leaving it as it is today for lw=0, but having your behavior
be the result for lw=None?  I can see people wanting the very fine
grid that lw=0 gives today, and lw=None to me seems to be very
explicitly saying 'no lines'.

Just an idea...

Cheers,

f

ps - Congrats to all on the release!  You've all done an absolutely
terriffic job, and the benefits are already becoming obvious with
these new ideas and contributions.  We'll have to celebrate at scipy
:)

Hi Mike and John,
   I've got a question about the functionality about axes3d.plot_surface:
When I set the linewidths to 0 (in the patch I'm working on) I get an image looking like this:

http://static.ryanjwagner.com/mpl_patches/lw0.png

I don't think this looks correct to me, as I can still see the grid. I have a workaround in place so if linewidth=0 then the image looks like this:

http://static.ryanjwagner.com/mpl_patches/lw0_fix.png

Would you agree that this should be the expected functionality or should I leave this alone, or should it be a new keyword?


WRT to the previous conversation about the gradients, I have been wishing for that for a while myself, but I understand the difficulty in doing the interpolations. In my own work I end up interpolating the data much finer and it looks better since the polygons are so small you can't notice the single colored polys:

http://static.ryanjwagner.com/mpl_patches/animation.gif

But I think this looks even better now that I'm able to do it without the visible wiremesh.

-Ryan

> I think this happens in all mpl graphs, you just don't see it.  The
> axis limits are set to -2..2, and the sine is draw from -2..2.  The
> linewidth extends beyond 2, so it is clipped by the axes clipping to
> the bounding rectangle.  Normally you don't see this, because visually
> it is under the surrounding axes black edge.


Yes, I saw that it looks like it happens under the axes clipping.



> You can either set the
> ylimits wider:
>
  ax.set_ylim(-2.1, 2.1)
>

But would this also make the spine have the larger limits?  Basically, I
want know if the spines can be used to create Tufte-style range-frames.  Am
I correct in thinking that these spines provide that?  Or is there another
way to get a range-frame?


> or turn clipping off
>
>  ax.plot(x,y, clip_on=False)
>

This looks hopeful and I will give it a shot.

Cheers,

Brian

On Thu, Aug 6, 2009 at 2:03 PM, John Hunter <jd...@gm...> wrote:

> On Thu, Aug 6, 2009 at 1:59 PM, Ryan May<rm...@gm...> wrote:
> > On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote:
> >>
> >> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
> >> >
> >> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...>
> >> > wrote:
> >> >>
> >> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look
> like
> >> >> the
> >> >> rest other function documentation in pyplot.py file.
> >> >>
> >> >> In [10]: color
> >> >> colorbar      colorbar_doc  colormaps     colors
> >> >
> >> > Good catch.  Fixed in 7406.
> >>
> >> Just reading this, it looks like you missed the import
> >> matplotlib.colorbar part, no?  Or am I missing something?
> >
> > On my machine, the import didn't seem to be necessary.
> matplotlib.colorbar
> > is available just with:
> >
> >     import matplotlib
>
> Strange...
>
>  j> python
>  Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
>  [GCC 3.4.1] on sunos5
>  Type "help", "copyright", "credits" or "license" for more information.
>  >>> import matplotlib
>  >>> matplotlib.colorbar
>  Traceback (most recent call last):
>    File "<stdin>", line 1, in ?
>  AttributeError: 'module' object has no attribute 'colorbar'
>  >>> matplotlib.__version__
>  '1.0.svn'
>

Stranger still (or it is to me):

Python 2.6.2 (r262:71600, Aug  3 2009, 10:34:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import matplotlib
>>> matplotlib.colorbar
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'colorbar'
>>> from matplotlib import pyplot
>>> matplotlib.colorbar
<module 'matplotlib.colorbar' from
'/home/rmay/.local/lib/python2.6/site-packages/matplotlib/colorbar.pyc'>


>
> > Would it be better to explicitly import matplotlib.colorbar anyways?
>
> Yes
>

Clearly.

>> When possible, could you make bugfixes to the branch and merge to the
>> trunk?  I know this is a bit of a hassle, but we often live on a
>> release branch for several bug fix release cycles, so it is nice to
>> put the simple fixes there
>>
>> http://matplotlib.sourceforge.net/devel/coding_guide.html
>
> Yeah, my bad.  I just remembered after committing to trunk and was working
> on checking out the new branch and applying there when you made your fix.
> So what n ow?

Ahh, now the pain begins.  I believe the easiest path is to put the
> change in the branch, svn commit, go over to the trunk, svnmerge,
> resolve any conflicts and commit.  Now wasn't that easy?


I remember doing this before now.  I don't think there will be any problems
with making the changes outside of svnmerge.  The alternative is to change
trunk back and use svnmerge.  I don't mind doing either.  Got a preference
on which way to handle colorbar_doc?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

On Thu, Aug 6, 2009 at 1:59 PM, Ryan May<rm...@gm...> wrote:
> On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote:
>>
>> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
>> >
>> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...>
>> > wrote:
>> >>
>> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like
>> >> the
>> >> rest other function documentation in pyplot.py file.
>> >>
>> >> In [10]: color
>> >> colorbar      colorbar_doc  colormaps     colors
>> >
>> > Good catch.  Fixed in 7406.
>>
>> Just reading this, it looks like you missed the import
>> matplotlib.colorbar part, no?  Or am I missing something?
>
> On my machine, the import didn't seem to be necessary.  matplotlib.colorbar
> is available just with:
>
>     import matplotlib

Strange...

  j> python
  Python 2.4.5 (#4, Apr 12 2008, 09:09:16)
  [GCC 3.4.1] on sunos5
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import matplotlib
  >>> matplotlib.colorbar
  Traceback (most recent call last):
    File "<stdin>", line 1, in ?
  AttributeError: 'module' object has no attribute 'colorbar'
  >>> matplotlib.__version__
  '1.0.svn'


> Would it be better to explicitly import matplotlib.colorbar anyways?

Yes

>> When possible, could you make bugfixes to the branch and merge to the
>> trunk?  I know this is a bit of a hassle, but we often live on a
>> release branch for several bug fix release cycles, so it is nice to
>> put the simple fixes there
>>
>> http://matplotlib.sourceforge.net/devel/coding_guide.html
>
> Yeah, my bad.  I just remembered after committing to trunk and was working
> on checking out the new branch and applying there when you made your fix.
> So what n ow?

Ahh, now the pain begins.  I believe the easiest path is to put the
change in the branch, svn commit, go over to the trunk, svnmerge,
resolve any conflicts and commit.  Now wasn't that easy?

JDH

On Thu, Aug 6, 2009 at 1:55 PM, John Hunter <jd...@gm...> wrote:

> On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
> >
> > On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...>
> wrote:
> >>
> >> Shouldn't colorbar_doc name be hidden from users? It doesn't look like
> the
> >> rest other function documentation in pyplot.py file.
> >>
> >> In [10]: color
> >> colorbar      colorbar_doc  colormaps     colors
> >
> > Good catch.  Fixed in 7406.
>
> Just reading this, it looks like you missed the import
> matplotlib.colorbar part, no?  Or am I missing something?


On my machine, the import didn't seem to be necessary.  matplotlib.colorbar
is available just with:

    import matplotlib

Would it be better to explicitly import matplotlib.colorbar anyways?


> When possible, could you make bugfixes to the branch and merge to the
> trunk?  I know this is a bit of a hassle, but we often live on a
> release branch for several bug fix release cycles, so it is nice to
> put the simple fixes there
>
> http://matplotlib.sourceforge.net/devel/coding_guide.html
>

Yeah, my bad.  I just remembered after committing to trunk and was working
on checking out the new branch and applying there when you made your fix.
So what n ow?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

On Thu, Aug 6, 2009 at 1:50 PM, Ryan May<rm...@gm...> wrote:
>
> On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...> wrote:
>>
>> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
>> rest other function documentation in pyplot.py file.
>>
>> In [10]: color
>> colorbar      colorbar_doc  colormaps     colors
>
> Good catch.  Fixed in 7406.

Just reading this, it looks like you missed the import
matplotlib.colorbar part, no?  Or am I missing something?

When possible, could you make bugfixes to the branch and merge to the
trunk?  I know this is a bit of a hassle, but we often live on a
release branch for several bug fix release cycles, so it is nice to
put the simple fixes there

http://matplotlib.sourceforge.net/devel/coding_guide.html

JDH

John Hunter wrote:
> On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom<md...@st...> wrote:
>   
>> I looked into this a while ago wrt 2D quad meshes, and it didn't look like
>> there was anything built-in to do something like that.  All the gradients
>> are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
>> of colors).  There's nothing to do a 4-way blend like this.  So it would
>> have to be from scratch, at least for the colored part -- we can still use
>> Agg to render the quad shapes themselves.
>>     
>
> What about for other backends (PS, PDF, SVG)?  If there was support in
> the gradient spec for these, it might be worth it to try and write a
> custom gradient function in agg, as suggested by Maxim at the end of
> this tutorial:
>
> http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html
>   
Even with this, the gradient infrastructure in Agg assumes a 
one-dimensional map, and here we need to at least interpolate between 
the three points of a triangle.  It's not impossible, as it's easy 
enough to make a custom shader, it's just that the gradient code won't 
help us.

A possible workaround is suggested by this paper:

   http://www.svgopen.org/2005/papers/Converting3DFaceToSVG/index.html

That is, rather than doing a single Gourad triangle interpolation, just 
overlap three linear gradient patches with alpha blending.  At the very 
least it presents a way to support this in SVG which doesn't currently 
have Gourad interpolation.

PDF and PS support Gourad triangles directly, though supporting it looks 
-- um -- "fun".

Cheers,
Mike


-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever<gok...@gm...> wrote:
> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
> rest other function documentation in pyplot.py file.
>
> In [10]: color
> colorbar      colorbar_doc  colormaps     colors
>
> at rev 7405.

We are not very good about using the __all__ designation in our
modules.  I will change this to

  from matplotlib.colorbar import colorbar_doc as _colorbar_doc

in pyplot so it doesn't show up in normal tab completions, etc.

JDH

On Thu, Aug 6, 2009 at 1:38 PM, Gökhan Sever <gok...@gm...> wrote:

> Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
> rest other function documentation in pyplot.py file.
>
> In [10]: color
> colorbar      colorbar_doc  colormaps     colors


Good catch.  Fixed in 7406.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, OK, United States

Shouldn't colorbar_doc name be hidden from users? It doesn't look like the
rest other function documentation in pyplot.py file.

In [10]: color
colorbar      colorbar_doc  colormaps     colors

at rev 7405.

In [10]: colorbar_doc
Out[10]: "\n\nAdd a colorbar to a plot.\n\nFunction signatures for the
:mod:`~matplotlib.pyplot` interface; all\nbut the first are also method
signatures for the\n:meth:`~matplotlib.figure.Figure.colorbar` method::\n\n
colorbar(**kwargs)\n  colorbar(mappable, **kwargs)\n  colorbar(mappable,
cax=cax, **kwargs)\n  colorbar(mappable, ax=ax, **kwargs)\n\narguments:\n\n
*mappable*\n    the :class:`~matplotlib.image.Image`,\n
:class:`~matplotlib.contour.ContourSet`, etc. to\n    which the colorbar
applies; this argument is mandatory for the\n
:meth:`~matplotlib.figure.Figure.colorbar` method but optional for the\n
:func:`~matplotlib.pyplot.colorbar` function, which sets the\n    default to
the current image.\n\nkeyword arguments:\n\n  *cax*\n    None | axes object
into which the colorbar will be drawn\n  *ax*\n    None | parent axes object
from which space for a new\n    colorbar axes will be stolen\n\n\nAdditional
keyword arguments are of two kinds:\n\n  axes properties:\n\n\n
============= ====================================================\n
Property      Description\n    =============
====================================================\n    *orientation*
vertical or horizontal\n    *fraction*    0.15; fraction of original axes to
use for colorbar\n    *pad*         0.05 if vertical, 0.15 if horizontal;
fraction\n                  of original axes between colorbar and new image
axes\n    *shrink*      1.0; fraction by which to shrink the colorbar\n
*aspect*      20; ratio of long to short dimensions\n    =============
====================================================\n\n\n  colorbar
properties:\n\n\n    ===========
====================================================\n    Property
Description\n    ===========
====================================================\n    *extend*      [
'neither' | 'both' | 'min' | 'max' ]\n                  If not 'neither',
make pointed end(s) for out-of-\n                  range values.  These are
set for a given colormap\n                  using the colormap set_under and
set_over methods.\n    *spacing*     [ 'uniform' | 'proportional'
]\n                  Uniform spacing gives each discrete color the
same\n                  space; proportional makes the space proportional
to\n                  the data interval.\n    *ticks*       [ None | list of
ticks | Locator object ]\n                  If None, ticks are determined
automatically from the\n                  input.\n    *format*      [ None |
format string | Formatter object ]\n                  If None,
the\n                  :class:`~matplotlib.ticker.ScalarFormatter` is
used.\n                  If a format string is given, e.g. '%.3f', that
is\n                  used. An alternative\n
:class:`~matplotlib.ticker.Formatter` object may be\n                  given
instead.\n    *drawedges*   [ False | True ] If true, draw lines at
color\n                  boundaries.\n    ===========
====================================================\n\n    The following
will probably be useful only in the context of\n    indexed colors (that is,
when the mappable has norm=NoNorm()),\n    or other unusual
circumstances.\n\n    ============
===================================================\n    Property
Description\n    ============
===================================================\n    *boundaries*   None
or a sequence\n    *values*       None or a sequence which must be of length
1 less\n                   than the sequence of *boundaries*. For each
region\n                   delimited by adjacent entries in *boundaries*,
the\n                   color mapped to the corresponding value in
values\n                   will be used.\n    ============
===================================================\n\n\n\nIf *mappable* is
a :class:`~matplotlib.contours.ContourSet`, its *extend*\nkwarg is included
automatically.\n\nNote that the *shrink* kwarg provides a simple way to keep
a vertical\ncolorbar, for example, from being taller than the axes of the
mappable\nto which the colorbar is attached; but it is a manual method
requiring\nsome trial and error. If the colorbar is too tall (or a
horizontal\ncolorbar is too wide) use a smaller value of *shrink*.\n\nFor
more precise control, you can manually specify the positions of\nthe axes
objects in which the mappable and the colorbar are drawn.  In\nthis case, do
not use any of the axes properties kwargs.\n\nreturns:\n
:class:`~matplotlib.colorbar.Colorbar` instance; see also its base
class,\n    :class:`~matplotlib.colorbar.ColorbarBase`.  Call the\n
:meth:`~matplotlib.colorbar.ColorbarBase.set_label` method\n    to label the
colorbar.\n\n"



-- 
Gökhan

On Thu, Aug 6, 2009 at 1:06 PM, Michael Droettboom<md...@st...> wrote:
> I looked into this a while ago wrt 2D quad meshes, and it didn't look like
> there was anything built-in to do something like that.  All the gradients
> are 1-dimensional (i.e. between two colors, or a 1-dimensional lookup table
> of colors).  There's nothing to do a 4-way blend like this.  So it would
> have to be from scratch, at least for the colored part -- we can still use
> Agg to render the quad shapes themselves.

What about for other backends (PS, PDF, SVG)?  If there was support in
the gradient spec for these, it might be worth it to try and write a
custom gradient function in agg, as suggested by Maxim at the end of
this tutorial:

http://www.antigrain.com/tips/gradients_tutorial/gradients_tutorial.agdoc.html

JDH

On Thu, Aug 6, 2009 at 1:01 PM, Brian Granger<ell...@gm...> wrote:
> Hi,
>
> Congrats on the latest matplotlib release.  Looks like there are some
> *really* impressive new things in there.  I was just looking at the spines
> docs:
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html
>
> And I noticed that on spines that are range limited (to the data) in the y
> direction, the blueish line of the graph is actually cut off near the
> limit.  It is not obvious, but one you see it, you notice it in all the
> examples (look at the peaks and troughs of the sin curve).
>
> Is this a known issue or can this be prevented?

I think this happens in all mpl graphs, you just don't see it.  The
axis limits are set to -2..2, and the sine is draw from -2..2.  The
linewidth extends beyond 2, so it is clipped by the axes clipping to
the bounding rectangle.  Normally you don't see this, because visually
it is under the surrounding axes black edge.  You can either set the
ylimits wider:

  ax.set_ylim(-2.1, 2.1)

or turn clipping off

  ax.plot(x,y, clip_on=False)

JDH

I looked into this a while ago wrt 2D quad meshes, and it didn't look 
like there was anything built-in to do something like that.  All the 
gradients are 1-dimensional (i.e. between two colors, or a 1-dimensional 
lookup table of colors).  There's nothing to do a 4-way blend like 
this.  So it would have to be from scratch, at least for the colored 
part -- we can still use Agg to render the quad shapes themselves.

Mike

John Hunter wrote:
> On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner<rw...@vn...> wrote:
>   
>> Hi,
>>   I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own
>>     
>
> The other thing that would be really nice is to have smooth
> interpolation along each face.  Michael, do you have a sense how hard
> it would be in agg (and other backends) to do a linear gradient
> interpolation over a quadrilateral with one RGBA at each vertex?
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,

Congrats on the latest matplotlib release.  Looks like there are some
*really* impressive new things in there.  I was just looking at the spines
docs:

http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html

And I noticed that on spines that are range limited (to the data) in the y
direction, the blueish line of the graph is actually cut off near the
limit.  It is not obvious, but one you see it, you notice it in all the
examples (look at the peaks and troughs of the sin curve).

Is this a known issue or can this be prevented?

Cheers,

Brian

Mike,

When I eliminate the cuts from filled contour paths, I do find 
pathological cases where the filling works correctly with the cuts in 
place, but not without them.  Attached are a data file and a script to 
plot it, illustrating the problem.  Is this due to a known limitation of 
filled paths?  In the example, the top two holes are connected to the 
lower hole, instead of being connected directly to the outer boundary of 
the filled region.  Is this illegal?  If so, I think we are stuck, 
because rearranging the paths that cntr makes to eliminate this type of 
case would likely be very difficult.

Eric

I've added this to the sourceforge bug tracker, ID 2832896.

Mike


On Aug 5, 2009, at 3:32 PM, Michael Fitzgerald wrote:

>
> Hi all,
>
> I've come across an apparent bug in imshow when outputting to PDF  
> and EPS files.  (I haven't tested other vector formats.)  It  
> manifests as a small scaling error between the raster image and the  
> axes coordinates.
>
> I have attached a test script to illustrate the problem.  The  
> (correct) PNG output file shows a green 'X' at the common point  
> between four pixels near the center of the raster image.  The  
> extent is chosen such that the coordinates refer to pixel centers.   
> The PDF and EPS output files show a misalignment between the X and  
> the pixel boundaries -- zoom in to see it clearly.  Also, the  
> topmost row and rightmost column appear truncated.
>
> I am using svn r7395.
>
> Thanks for the attention,
> Mike
>
> <test_image_offset.py>

On Thu, Aug 6, 2009 at 11:51 AM, Ryan Wagner<rw...@vn...> wrote:
> Hi,
>   I'd like to propose adding a SHADES keyword to the mplot3D routines where you can supply your own

The other thing that would be really nice is to have smooth
interpolation along each face.  Michael, do you have a sense how hard
it would be in agg (and other backends) to do a linear gradient
interpolation over a quadrilateral with one RGBA at each vertex?