matplotlib-devel Mailing List for matplotlib (Page 5)

I am tracing down a bug in hist() and I am trying to figure out what is it
about the 'stepfilled' mode that is different from the regular 'bar' mode.
Currently, the hist() code has a separate if branch for dealing with 'step'
and 'stepfilled', and that branch has a bunch of bugs.  The best that I can
figure is that it prevents lines from being drawn in between the bins.  If
that is the only difference, maybe we could somehow use the bar functions?

At the very least, I think this needs to be documented better to make it
clear why this oddball approach is happening.

Thanks,
Ben Root

On Wed, Aug 11, 2010 at 1:32 PM, Benjamin Root <ben...@ou...> wrote:
> Couldn't we just do what Google does and put a "Beta" label on everything?
>
> "Matplotlib Beta"
>
> Sounds almost like a planet or something...

That used to be my attitude.  Turns out there are a lot of legitimate
users who cannot (due to company IT policy) or will not use software
at 1.0 and below or in beta.  It's a nice crutch for developers to say
"hey it's in beta so don't count on us not pulling the API rug out
from under you".  We have historically been very cautious about
breaking API, and the code is mature and stable, so the version number
should reflect that in my view.

JDH

Sorry, forgot source code (you cannot run it, though).

Friedrich

On Wed, Aug 11, 2010 at 1:27 PM, John Hunter <jd...@gm...> wrote:

> On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing <ef...@ha...> wrote:
> > John et al.,
> >
> > Is this a reasonable time to put out 1.0.1?  There have been quite a few
> > bugfixes and other cleanups since 1.0.  Most likely the biggest problem
> with
> > 1.0 is my error in the tk show(), which you tripped over, and which
> prompted
> > the thread below.
>
> I've been meaning to ask you the same thing :-).  We probably need to
> have a go at the bug tracker before 1.0.1, but I am happy to do a
> bugfix release as soon as we are ready.
>
> Or perhaps we should be a little more aggressive on our numbering.
> Ie, bugfix releases could be 1.1.0 and 1.0.1, a micro release would be
> for installer fixes and the like.
>
> major numbers: significant new features, minor API breakage
> minor numbers: significant bugfixes and near guaranteed API compat
> micro: minor bugfixes, API compat
>
> I think 1.0 understates the maturity of the project so we may want to
> get to 2.0 in less than 10 years :-)
>
> JDH
>
>
Couldn't we just do what Google does and put a "Beta" label on everything?

"Matplotlib Beta"

Sounds almost like a planet or something...

Ben Root

http://www.youtube.com/watch?v=aa5eWT-J3v0

On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing <ef...@ha...> wrote:
> John et al.,
>
> Is this a reasonable time to put out 1.0.1?  There have been quite a few
> bugfixes and other cleanups since 1.0.  Most likely the biggest problem with
> 1.0 is my error in the tk show(), which you tripped over, and which prompted
> the thread below.

I've been meaning to ask you the same thing :-).  We probably need to
have a go at the bug tracker before 1.0.1, but I am happy to do a
bugfix release as soon as we are ready.

Or perhaps we should be a little more aggressive on our numbering.
Ie, bugfix releases could be 1.1.0 and 1.0.1, a micro release would be
for installer fixes and the like.

major numbers: significant new features, minor API breakage
minor numbers: significant bugfixes and near guaranteed API compat
micro: minor bugfixes, API compat

I think 1.0 understates the maturity of the project so we may want to
get to 2.0 in less than 10 years :-)

JDH

FWIW, I responded to a thread on the IPython list where someone else
was asking why show() was blocking execution on Windows 7.  I think he
was really experiencing the tk show() problem from mpl.  So, I think
this is causing issues with other users (in my opinion).

Ryan

On Wed, Aug 11, 2010 at 12:35 PM, Eric Firing <ef...@ha...> wrote:
> John et al.,
>
> Is this a reasonable time to put out 1.0.1?  There have been quite a few
> bugfixes and other cleanups since 1.0.  Most likely the biggest problem
> with 1.0 is my error in the tk show(), which you tripped over, and which
> prompted the thread below.
>
> Eric
>
> -------- Original Message --------
> Subject: Re: [Matplotlib-users] show() blocks script execution for
> TkAgg   from ipython -pylab
> Date: Wed, 11 Aug 2010 09:35:24 -0700
> From: Christoph Gohlke <cg...@uc...>
> To: mat...@li...
>
> Ryan: you could try matplotlib-1.0.0.svn.win32-py2.6.exe from
> http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib .It was built this
> morning from svn.
>
> Christoph
>
> On 8/11/2010 7:26 AM, Ryan Krauss wrote:
>> 0.99.3 is more or less fine, but there is an annoying exception window
>> that pops up if you close IPython with a plot window open (using the
>> TkAgg backend).  But in my mind this is less bothersome than having to
>> close all the plot windows every time I run a script (I tend to write
>> scripts that generate 5-10 plots at a minimum).
>>
>> If I could easily build an installer from svn, I would try it.  I
>> don't have any microsoft compilers installed on my windows computers.
>>
>> Thanks again,
>>
>> Ryan
>>
>> On Wed, Aug 11, 2010 at 9:09 AM, Ryan Krauss<rya...@gm...>  wrote:
>>> Thanks.
>>>
>>> I need to role out a python install for my students.  Classes start in
>>> a week and a half.  What should I do?  The installation for most of
>>> them needs to be fairly simple.
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>> On Wed, Aug 11, 2010 at 2:25 AM, Eric Firing<ef...@ha...>  wrote:
>>>> On 08/10/2010 05:43 PM, Ryan Krauss wrote:
>>>>> I just upgraded my windows machine to matplotlib 1.0.0 and a simple
>>>>> script such as
>>>>>
>>>>> from pylab import *
>>>>> from scipy import *
>>>>>
>>>>> t = arange(0,1,0.01)
>>>>> y = sin(2*pi*t)
>>>>>
>>>>> figure(1)
>>>>> clf()
>>>>> plot(t,y)
>>>>>
>>>>> show()
>>>>>
>>>>> Now halts execution when run from the ipython -pylab prompt.  The same
>>>>> commands typed at the commandline do not lead to show() halting
>>>>> execution.
>>>>>
>>>>> Is this expected behavior?
>>>>
>>>> This was fixed three weeks ago in svn, both the maintenance branch and
>>>> the trunk.  I made some changes in show() shortly before 1.0, trying to
>>>> get uniform and reasonable behavior in all backends, and I didn't quite
>>>> succeed.  I think I got it all straightened out--but only after the
>>>> release, unfortunately.  I hope it won't be too long before a 1.0.1
>>>> bugfix release can be made, but I am aware of no schedule.
>>>>
>>>> Eric
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ryan
>>>>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John et al.,

Is this a reasonable time to put out 1.0.1?  There have been quite a few 
bugfixes and other cleanups since 1.0.  Most likely the biggest problem 
with 1.0 is my error in the tk show(), which you tripped over, and which 
prompted the thread below.

Eric

-------- Original Message --------
Subject: Re: [Matplotlib-users] show() blocks script execution for 
TkAgg	from ipython -pylab
Date: Wed, 11 Aug 2010 09:35:24 -0700
From: Christoph Gohlke <cg...@uc...>
To: mat...@li...

Ryan: you could try matplotlib-1.0.0.svn.win32-py2.6.exe from
http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib .It was built this
morning from svn.

Christoph

On 8/11/2010 7:26 AM, Ryan Krauss wrote:
> 0.99.3 is more or less fine, but there is an annoying exception window
> that pops up if you close IPython with a plot window open (using the
> TkAgg backend).  But in my mind this is less bothersome than having to
> close all the plot windows every time I run a script (I tend to write
> scripts that generate 5-10 plots at a minimum).
>
> If I could easily build an installer from svn, I would try it.  I
> don't have any microsoft compilers installed on my windows computers.
>
> Thanks again,
>
> Ryan
>
> On Wed, Aug 11, 2010 at 9:09 AM, Ryan Krauss<rya...@gm...>  wrote:
>> Thanks.
>>
>> I need to role out a python install for my students.  Classes start in
>> a week and a half.  What should I do?  The installation for most of
>> them needs to be fairly simple.
>>
>> Thanks,
>>
>> Ryan
>>
>> On Wed, Aug 11, 2010 at 2:25 AM, Eric Firing<ef...@ha...>  wrote:
>>> On 08/10/2010 05:43 PM, Ryan Krauss wrote:
>>>> I just upgraded my windows machine to matplotlib 1.0.0 and a simple
>>>> script such as
>>>>
>>>> from pylab import *
>>>> from scipy import *
>>>>
>>>> t = arange(0,1,0.01)
>>>> y = sin(2*pi*t)
>>>>
>>>> figure(1)
>>>> clf()
>>>> plot(t,y)
>>>>
>>>> show()
>>>>
>>>> Now halts execution when run from the ipython -pylab prompt.  The same
>>>> commands typed at the commandline do not lead to show() halting
>>>> execution.
>>>>
>>>> Is this expected behavior?
>>>
>>> This was fixed three weeks ago in svn, both the maintenance branch and
>>> the trunk.  I made some changes in show() shortly before 1.0, trying to
>>> get uniform and reasonable behavior in all backends, and I didn't quite
>>> succeed.  I think I got it all straightened out--but only after the
>>> release, unfortunately.  I hope it won't be too long before a 1.0.1
>>> bugfix release can be made, but I am aware of no schedule.
>>>
>>> Eric
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ryan
>>>>

On Wed, Aug 11, 2010 at 11:47 AM, Friedrich Romstedt <
fri...@gm...> wrote:

> 2010/8/11 Eric Firing <ef...@ha...>:
> > Why make a whole new class instead of switching a behavior in an existing
> > class?
>
> To my understanding, making object having "behaviours" is usually not
> a good idea - I like different classes much more.  I believe this is
> just a matter of taste, both solutions will work.
>
> But when you think about Ben's last problem with global effects, this
> would not happen when using a different colormap instance.
>
> Btw, I think it's undesired to mix colour and b/w in a figure.  What
> is the use-case?  Making one figure in one paper at a time.  As soon
> as color is in, everything can be color.  Maybe we should decide here
> clearly by the best design proposal, and leave the use-case question
> alone.
>
>
My thinking here is that I really don't want to place unnecessary
restrictions upon how a user uses a feature.  Things should be a modular as
possible (which is why I was looking more for a convenience function than
anything else).

Why should we have to declare that a user will never need a B&W and color
figure?  Maybe a user wants to produce both B&W and color versions
simultaneously?  In my case in particular, it takes about 15 minutes to
generate one of my publication-quality images, but only a couple of minutes
to save it.  It would be beneficial to me to save both b&w and color
versions.  Another possible use-case would be someone who wants to take a
figure that might usually be colored but make a version of it in B&W with
color annotations for highlighting purposes.

The point is that I would like to give the users fine-grained control over
what they need, especially when the barrier to provide such control is
virtually non-existent.



> My thinking about moving it to the renderers is driven by the question
> where the functionality belongs to.  When we want to product b/w
> plots, this has initially nothing to do with colormaps.  It also
> applies to lines, scatterplots, images, whatever one can imagine.  So
> I thought it may be a good idea to apply b/w to the rendered objects
> in the end, i.e. LineCollections, QuadMeshs, and so on.
>
>
That would be a nice feature, too.  And it would also apply globally across
all elements within the figure.  I would not object to also having this
feature in addition to the ability to control my colormaps.


> >> Another option would be, to wrap the Colormap into a thin layer with
> >> __call__, but this appears way too clumsy and too hacky to me.  It's a
> >> clumsy way of deriving from the class.  Otherwise it's maybe also
> >> nice, because it's generic, for all Colormaps.  __getattr__ and
> >> __setattr__ (iirc) could be used to simulate the wrapped instance
> >> fully.
> >
> > I don't follow you on this--I don't understand at all.
>
> Well, personally I have abandoned this possibility, but just for
> completeness:
>
> class GrayWrapper:
>        def __init__(self, wrapped_colormap):
>                self._wrapped_colormap = wrapped_colormap
>
>        def __call__(self, value):
>                wrapped_colour = self._wrapped_colormap(value)
>                ...
>                return turned_into_gray
>
>
Interesting, but I still wonder if it is just better to have a function that
returns a grey version of the colormap. Although, one could extend this idea
(albeit probably not necessary) to include a variety of different colormap
transformations (brighten, darken, invert, etc.).


> > I don't understand why you would want to push this down into the
> renderers
> > instead of keeping it at a higher level.  And I don't know what you mean
> by
> > "getting rid of the alpha stuff".
>
> See above.  Here is an example for QuadMesh, it breaks down via
> QuadMesh.set_facecolors(),
> matplotlib.colors.colorConvert.to_rgba_array(),
> ColorConverter.to_rgba(), ColorConverter.to_rgb() (note the missing
> 'a'), and there it's in principle:
>
> >>> color = tuple(arg[:3])
> or some other conversion to a 3-tuple
> >>> return color
> and just before we could do the rgb->pseudogray conversion
>
.  So in my opinion this is the perfect place to do the color
> conversion.  I suppose all the other color conversions also break down
> to ColorConverter.
>
>
But, the alpha information is important.  The renderers need it.  I am not
seeing the rational for completely stripping it out.  I can see a rational
for being able to modify the alpha, but not for stripping it out.


> > Yes, there does seem to be a need for these sorts of switching
> operations.
> >  Getting back to the colormap question, our discussions have been based
> on
> > the assumption that an rgb_to_gray function is all that is needed.  But
> is
> > this true?  Or will users actually need completely different graymaps
> rather
> > than something resembling a black-and-white photo of a colormap?  If so,
> > then my suggested strategy is useless.
>
> No it's not it's just complementary.  What we want do here is the b/w
> photography.
>
>
Do we want to allow for users to specify their own LUMA conversion
coefficients?


> I'll just hack my matplotlib now to do the LUMA XXX conversion now
> always, and will see what it does ...
>
> Friedrich
>
>
Regards,
Ben Root

2010/8/11 Eric Firing <ef...@ha...>:
> Why make a whole new class instead of switching a behavior in an existing
> class?

To my understanding, making object having "behaviours" is usually not
a good idea - I like different classes much more.  I believe this is
just a matter of taste, both solutions will work.

But when you think about Ben's last problem with global effects, this
would not happen when using a different colormap instance.

Btw, I think it's undesired to mix colour and b/w in a figure.  What
is the use-case?  Making one figure in one paper at a time.  As soon
as color is in, everything can be color.  Maybe we should decide here
clearly by the best design proposal, and leave the use-case question
alone.

My thinking about moving it to the renderers is driven by the question
where the functionality belongs to.  When we want to product b/w
plots, this has initially nothing to do with colormaps.  It also
applies to lines, scatterplots, images, whatever one can imagine.  So
I thought it may be a good idea to apply b/w to the rendered objects
in the end, i.e. LineCollections, QuadMeshs, and so on.

>> Another option would be, to wrap the Colormap into a thin layer with
>> __call__, but this appears way too clumsy and too hacky to me.  It's a
>> clumsy way of deriving from the class.  Otherwise it's maybe also
>> nice, because it's generic, for all Colormaps.  __getattr__ and
>> __setattr__ (iirc) could be used to simulate the wrapped instance
>> fully.
>
> I don't follow you on this--I don't understand at all.

Well, personally I have abandoned this possibility, but just for completeness:

class GrayWrapper:
	def __init__(self, wrapped_colormap):
		self._wrapped_colormap = wrapped_colormap

	def __call__(self, value):
		wrapped_colour = self._wrapped_colormap(value)
		...
		return turned_into_gray

> I don't understand why you would want to push this down into the renderers
> instead of keeping it at a higher level.  And I don't know what you mean by
> "getting rid of the alpha stuff".

See above.  Here is an example for QuadMesh, it breaks down via
QuadMesh.set_facecolors(),
matplotlib.colors.colorConvert.to_rgba_array(),
ColorConverter.to_rgba(), ColorConverter.to_rgb() (note the missing
'a'), and there it's in principle:

>>> color = tuple(arg[:3])
or some other conversion to a 3-tuple
>>> return color
and just before we could do the rgb->pseudogray conversion

.  So in my opinion this is the perfect place to do the color
conversion.  I suppose all the other color conversions also break down
to ColorConverter.

> Yes, there does seem to be a need for these sorts of switching operations.
>  Getting back to the colormap question, our discussions have been based on
> the assumption that an rgb_to_gray function is all that is needed.  But is
> this true?  Or will users actually need completely different graymaps rather
> than something resembling a black-and-white photo of a colormap?  If so,
> then my suggested strategy is useless.

No it's not it's just complementary.  What we want do here is the b/w
photography.

I'll just hack my matplotlib now to do the LUMA XXX conversion now
always, and will see what it does ...

Friedrich

On Tue, Aug 10, 2010 at 7:39 PM, Benjamin Root <ben...@ou...> wrote:

> On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 08/10/2010 11:58 AM, Friedrich Romstedt wrote:
>> > 2010/8/10 Eric Firing<ef...@ha...>:
>> >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
>> >>> So I think it is probably best to code it into the Colormap object
>> >>> itself, so that each and ever derived class can define its own method
>> >>> of how to create a greyscale version.  What do you think about that?
>> >>
>> >> Good idea.  The base class could define a default to_grayscale() method
>> >> that would do the conversion near the very end of the Colormap.__call__
>> >> method if an as_gray attribute, also defined in the base class, is
>> True.
>> >>   No need for getters and setters--let it be a simple attribute.  This
>> >> is much simpler than generating a whole new colormap--instead, just set
>> >> an attribute to switch an existing colormap to gray or back to color.
>>  I
>> >> would leave the switch out of the __init__ args and kwargs.
>> >
>> >> If someone
>> >> wants grey, they can add one more line of code to set the attribute.
>> >
>> > Hmm, one would have to do it for every colormap used.  Also, it would
>> > be not so obvious if using the default colormap.
>> >
>> >> I
>> >> suspect only a small fraction of users will need this.
>> >
>> > I like this, it's a good idea enabling to not repeat all the stuff in
>> > the code.  But hey, wouldn't it be the same to just overload the
>> > __call__ method?
>> >
>> > class GrayColorbar(RgbColorbar):
>> >      """A colorbar returning grayscaled version."""
>> >
>> >      def __call__(self, value):
>> >          """Transforms RgbColorbar's value into grayscale, and returns
>> it.""""
>> >
>> >          rgb = BaseClass.__call__(self, value)
>> >          [do stuff]
>> >          return grayscale
>>
>> Why make a whole new class instead of switching a behavior in an
>> existing class?
>>
>> >
>> > Agreed, one has to this for all the classes, while your solution works
>> > generically in ColormapBase or whatever it's called.
>>
>> I think my solution (with slight modification) is also very compatible
>> with your suggestion below to have an rc param that switches between
>> color and gray.  If as_gray is None, use the rc value; otherwise, let it
>> act as described above.
>>
>> The typical use case is when one wants color initially, but then must
>> regenerate plots in black and white to reduce publication costs.  Your
>> rc suggestion facilitates such switching.
>>
>> >
>> > Another option would be, to wrap the Colormap into a thin layer with
>> > __call__, but this appears way too clumsy and too hacky to me.  It's a
>> > clumsy way of deriving from the class.  Otherwise it's maybe also
>> > nice, because it's generic, for all Colormaps.  __getattr__ and
>> > __setattr__ (iirc) could be used to simulate the wrapped instance
>> > fully.
>>
>> I don't follow you on this--I don't understand at all.
>>
>>
>> >
>> > Is there some layer dealing with colors in the renderers, where the
>> > conversion could also happen?  I'm asking because of displaying color
>> > images etc. and printing them as grayscale.  With this, we would get
>> > rid of the alpha stuff completely, too.
>>
>> I don't understand why you would want to push this down into the
>> renderers instead of keeping it at a higher level.  And I don't know
>> what you mean by "getting rid of the alpha stuff".
>>
>> >
>> > Maybe a general matplotlib.rc switch 'greyscale' would be possible.
>> > It would leave room for tons of improvement, e.g. automatically
>> > setting the color cycle to - -- -. etc., there was some monthes ago
>> > discussion about how to achieve that.  Another advantage: It's zero
>> > loc if set in the config file ;-)
>>
>> Yes, there does seem to be a need for these sorts of switching
>> operations.  Getting back to the colormap question, our discussions have
>> been based on the assumption that an rgb_to_gray function is all that is
>> needed.  But is this true?  Or will users actually need completely
>> different graymaps rather than something resembling a black-and-white
>> photo of a colormap?  If so, then my suggested strategy is useless.
>>
>> Eric
>>
>> >
>> > I think that would be a real neat new feature.
>> >
>> > I agree what's not needed is mixed greyscale and colour display in the
>> > same Figure.
>> >
>> > Bear with me if my ideas are always too radical.
>> >
>> > Friedrich
>>
>>
> I have to agree with Eric on this.  Maybe I am just not understanding
> Friedrich's thought process.
>
> If someone wants a specific greyscale colormapping, then they can make it
> themselves just like any other colormap.  However, it is as a matter of
> convenience and ease to say "hey, I have this colormap that I have been
> using in my code, but I need its greyscale equivalent".
>
> My idea is this.  It appears that all colormappings get a lookup table
> (self._lut) that contains rgba values.   We could also simultaneously
> maintain a second lookup table (initialized only when needed).  Therefore,
> one could take a colormap, switch on the greyscale attribute when desired
> (which would swap the two tables), and switch back over to the color-scale
> with the same amount of ease.
>
> It would be independent of any Colormap subclass because it would be in the
> base class.  My only concern is when do the various drawing elements
> actually use the colormap info?  If I create a b&w figure in one subplot,
> but also a colored figure in another subplot (for whatever reason) using the
> same colormap, would the figure show as expected at render-time?
>
> Thoughts, concerns, comments?
>
> Ben Root
>


Ok,

I have made some code that let's me easily switch between modes and works
quite nicely.  However, something I suspected would happen occurs.  If I
were to use the colormap and ever change the mode  before rendering, *all*
places where that colormap was used is colored according to the mode last
set before rendering.

This could be considered a bug or a feature, depending on one's viewpoint.
I suspect if one really needed independent colormaps, one could use deepcopy
before applying the alternate colormap to the axes.

I am including a patch to  this email for a looking over (be brutal).  Note,
it is hardly ready for inclusion as I am sure there are some other behaviors
I haven't thought of.

Below is a quick example of how to use the new feature.

Enjoy!
Ben Root


import numpy as np
import matplotlib.pyplot as plt
import matplotlib.cm as cm

X, Y = np.mgrid[-10:10, -10:10]
Z = np.abs(X * Y)

cmap = cm.get_cmap()
cmap.grey_mode = True

plt.pcolor(X, Y, Z, cmap=cmap)
plt.show()

On Tue, Aug 10, 2010 at 7:20 PM, Eric Firing <ef...@ha...> wrote:

> On 08/10/2010 11:58 AM, Friedrich Romstedt wrote:
> > 2010/8/10 Eric Firing<ef...@ha...>:
> >> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
> >>> So I think it is probably best to code it into the Colormap object
> >>> itself, so that each and ever derived class can define its own method
> >>> of how to create a greyscale version.  What do you think about that?
> >>
> >> Good idea.  The base class could define a default to_grayscale() method
> >> that would do the conversion near the very end of the Colormap.__call__
> >> method if an as_gray attribute, also defined in the base class, is True.
> >>   No need for getters and setters--let it be a simple attribute.  This
> >> is much simpler than generating a whole new colormap--instead, just set
> >> an attribute to switch an existing colormap to gray or back to color.  I
> >> would leave the switch out of the __init__ args and kwargs.
> >
> >> If someone
> >> wants grey, they can add one more line of code to set the attribute.
> >
> > Hmm, one would have to do it for every colormap used.  Also, it would
> > be not so obvious if using the default colormap.
> >
> >> I
> >> suspect only a small fraction of users will need this.
> >
> > I like this, it's a good idea enabling to not repeat all the stuff in
> > the code.  But hey, wouldn't it be the same to just overload the
> > __call__ method?
> >
> > class GrayColorbar(RgbColorbar):
> >      """A colorbar returning grayscaled version."""
> >
> >      def __call__(self, value):
> >          """Transforms RgbColorbar's value into grayscale, and returns
> it.""""
> >
> >          rgb = BaseClass.__call__(self, value)
> >          [do stuff]
> >          return grayscale
>
> Why make a whole new class instead of switching a behavior in an
> existing class?
>
> >
> > Agreed, one has to this for all the classes, while your solution works
> > generically in ColormapBase or whatever it's called.
>
> I think my solution (with slight modification) is also very compatible
> with your suggestion below to have an rc param that switches between
> color and gray.  If as_gray is None, use the rc value; otherwise, let it
> act as described above.
>
> The typical use case is when one wants color initially, but then must
> regenerate plots in black and white to reduce publication costs.  Your
> rc suggestion facilitates such switching.
>
> >
> > Another option would be, to wrap the Colormap into a thin layer with
> > __call__, but this appears way too clumsy and too hacky to me.  It's a
> > clumsy way of deriving from the class.  Otherwise it's maybe also
> > nice, because it's generic, for all Colormaps.  __getattr__ and
> > __setattr__ (iirc) could be used to simulate the wrapped instance
> > fully.
>
> I don't follow you on this--I don't understand at all.
>
>
> >
> > Is there some layer dealing with colors in the renderers, where the
> > conversion could also happen?  I'm asking because of displaying color
> > images etc. and printing them as grayscale.  With this, we would get
> > rid of the alpha stuff completely, too.
>
> I don't understand why you would want to push this down into the
> renderers instead of keeping it at a higher level.  And I don't know
> what you mean by "getting rid of the alpha stuff".
>
> >
> > Maybe a general matplotlib.rc switch 'greyscale' would be possible.
> > It would leave room for tons of improvement, e.g. automatically
> > setting the color cycle to - -- -. etc., there was some monthes ago
> > discussion about how to achieve that.  Another advantage: It's zero
> > loc if set in the config file ;-)
>
> Yes, there does seem to be a need for these sorts of switching
> operations.  Getting back to the colormap question, our discussions have
> been based on the assumption that an rgb_to_gray function is all that is
> needed.  But is this true?  Or will users actually need completely
> different graymaps rather than something resembling a black-and-white
> photo of a colormap?  If so, then my suggested strategy is useless.
>
> Eric
>
> >
> > I think that would be a real neat new feature.
> >
> > I agree what's not needed is mixed greyscale and colour display in the
> > same Figure.
> >
> > Bear with me if my ideas are always too radical.
> >
> > Friedrich
>
>
I have to agree with Eric on this.  Maybe I am just not understanding
Friedrich's thought process.

If someone wants a specific greyscale colormapping, then they can make it
themselves just like any other colormap.  However, it is as a matter of
convenience and ease to say "hey, I have this colormap that I have been
using in my code, but I need its greyscale equivalent".

My idea is this.  It appears that all colormappings get a lookup table
(self._lut) that contains rgba values.   We could also simultaneously
maintain a second lookup table (initialized only when needed).  Therefore,
one could take a colormap, switch on the greyscale attribute when desired
(which would swap the two tables), and switch back over to the color-scale
with the same amount of ease.

It would be independent of any Colormap subclass because it would be in the
base class.  My only concern is when do the various drawing elements
actually use the colormap info?  If I create a b&w figure in one subplot,
but also a colored figure in another subplot (for whatever reason) using the
same colormap, would the figure show as expected at render-time?

Thoughts, concerns, comments?

Ben Root

On 08/10/2010 11:58 AM, Friedrich Romstedt wrote:
> 2010/8/10 Eric Firing<ef...@ha...>:
>> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
>>> So I think it is probably best to code it into the Colormap object
>>> itself, so that each and ever derived class can define its own method
>>> of how to create a greyscale version.  What do you think about that?
>>
>> Good idea.  The base class could define a default to_grayscale() method
>> that would do the conversion near the very end of the Colormap.__call__
>> method if an as_gray attribute, also defined in the base class, is True.
>>   No need for getters and setters--let it be a simple attribute.  This
>> is much simpler than generating a whole new colormap--instead, just set
>> an attribute to switch an existing colormap to gray or back to color.  I
>> would leave the switch out of the __init__ args and kwargs.
>
>> If someone
>> wants grey, they can add one more line of code to set the attribute.
>
> Hmm, one would have to do it for every colormap used.  Also, it would
> be not so obvious if using the default colormap.
>
>> I
>> suspect only a small fraction of users will need this.
>
> I like this, it's a good idea enabling to not repeat all the stuff in
> the code.  But hey, wouldn't it be the same to just overload the
> __call__ method?
>
> class GrayColorbar(RgbColorbar):
>      """A colorbar returning grayscaled version."""
>
>      def __call__(self, value):
>          """Transforms RgbColorbar's value into grayscale, and returns it.""""
>
>          rgb = BaseClass.__call__(self, value)
>          [do stuff]
>          return grayscale

Why make a whole new class instead of switching a behavior in an 
existing class?

>
> Agreed, one has to this for all the classes, while your solution works
> generically in ColormapBase or whatever it's called.

I think my solution (with slight modification) is also very compatible 
with your suggestion below to have an rc param that switches between 
color and gray.  If as_gray is None, use the rc value; otherwise, let it 
act as described above.

The typical use case is when one wants color initially, but then must 
regenerate plots in black and white to reduce publication costs.  Your 
rc suggestion facilitates such switching.

>
> Another option would be, to wrap the Colormap into a thin layer with
> __call__, but this appears way too clumsy and too hacky to me.  It's a
> clumsy way of deriving from the class.  Otherwise it's maybe also
> nice, because it's generic, for all Colormaps.  __getattr__ and
> __setattr__ (iirc) could be used to simulate the wrapped instance
> fully.

I don't follow you on this--I don't understand at all.


>
> Is there some layer dealing with colors in the renderers, where the
> conversion could also happen?  I'm asking because of displaying color
> images etc. and printing them as grayscale.  With this, we would get
> rid of the alpha stuff completely, too.

I don't understand why you would want to push this down into the 
renderers instead of keeping it at a higher level.  And I don't know 
what you mean by "getting rid of the alpha stuff".

>
> Maybe a general matplotlib.rc switch 'greyscale' would be possible.
> It would leave room for tons of improvement, e.g. automatically
> setting the color cycle to - -- -. etc., there was some monthes ago
> discussion about how to achieve that.  Another advantage: It's zero
> loc if set in the config file ;-)

Yes, there does seem to be a need for these sorts of switching 
operations.  Getting back to the colormap question, our discussions have 
been based on the assumption that an rgb_to_gray function is all that is 
needed.  But is this true?  Or will users actually need completely 
different graymaps rather than something resembling a black-and-white 
photo of a colormap?  If so, then my suggested strategy is useless.

Eric

>
> I think that would be a real neat new feature.
>
> I agree what's not needed is mixed greyscale and colour display in the
> same Figure.
>
> Bear with me if my ideas are always too radical.
>
> Friedrich

Hi Friedrich,

>> for the latter: when building matplotlib against a fink-installed python
>> compiled in 64bit mode
>> I found the check for a framework-installed Python (rev 8365) fails, and
>> matplotlib fails to load,
>> because the MacOS module is not available in 64bit.
> 
> Hmm, do you claim that MacOS is in general not available in x86_64?

I intended to, since the fink porting description for Python under OS X 10.6 states so, 
and I was also mislead by the statement "not available in 64-bit mode" in 
http://docs.python.org/library/macos.html , but the latter, I realised, applied just to 
individual functions (in this case, the last one in the list). 
You are right, in principle MacOS.WMAvailable() should still be available (;-) on x86_64. 

> Just my 2 cents:
> 
> pb-d-128-141-26-145:~ Friedrich$ python-32
> Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
> [GCC 4.2.1 (Apple Inc. build 5659)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import MacOS
>>>> ^D
> pb-d-128-141-26-145:~ Friedrich$ python-64
> Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
> [GCC 4.2.1 (Apple Inc. build 5659)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import MacOS
>>>> ^D
> 
> This is a self-compiled python.org Python 2.6.5 residing in
> /Library/Frameworks/Python.framwork:
> ./configure --enable-framework --with-universal-archs=intel
> --enable-universalsdk=/
> with
> MACOSX_DEPLOYMENT_TARGET=10.4
> GCC=gcc-4.2
> 
> Please bear with me, but how does framework/not-framework interfere
> with the build of the MacOS module?
>> (assuming Python is not a framework installation if it lacks the MacOS
>> module).
> 
> Are there more implications?  I always thought framework build just
> means to put it in /Library/Framworks/Python.framework.

Good question - all I can tell at this point is that in fink, python is not built as a framework, 
merely with 
./configure --enable-shared
and on Snow Leopard this fails:

miranda:2843> /sw/bin/python2.6
Python 2.6.5 (r265:79063, Jul 19 2010, 02:30:51) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import MacOS
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: No module named MacOS

miranda:2844> /usr/bin/python                                                                                                  
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Traceback (most recent call last):
  File "/Users/derek/.pythonrc", line 22, in <module>
    readline.read_history_file(historyPath)
IOError: [Errno 2] No such file or directory
>>> import MacOS
>>> MacOS.WMAvailable()
True
>>> ^D

There is no patch that would have explicitly removed the module in the fink install, 
so all I can think of is that not enabling framework and/or SDK build is responsible. 
I did not find any hint in the Mac build documentation towards this, though. 

If this is a fink-related problem only, of course we'd just need to apply the patch I've 
created to the fink package. But matplotlib will probably have to deal with it whenever 
it is going to be python3-ready.

Cheers,
							Derek
--
-------------------------------------------------------------------------
Derek Homeier                         Institut für Astrophysik Göttingen    
Georg-August-Universität              Phone:             +49 551 39-7980
Friedrich-Hund-Platz 1                Fax:               +49 551 39-5043 
D-37077 Göttingen, Germany            Feet:                     E.04.104
Web:                   http://www.astro.physik.uni-goettingen.de/~derek/
-------------------------------------------------------------------------

2010/8/10 Eric Firing <ef...@ha...>:
> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
>> So I think it is probably best to code it into the Colormap object
>> itself, so that each and ever derived class can define its own method
>> of how to create a greyscale version.  What do you think about that?
>
> Good idea.  The base class could define a default to_grayscale() method
> that would do the conversion near the very end of the Colormap.__call__
> method if an as_gray attribute, also defined in the base class, is True.
>  No need for getters and setters--let it be a simple attribute.  This
> is much simpler than generating a whole new colormap--instead, just set
> an attribute to switch an existing colormap to gray or back to color.  I
> would leave the switch out of the __init__ args and kwargs.

> If someone
> wants grey, they can add one more line of code to set the attribute.

Hmm, one would have to do it for every colormap used.  Also, it would
be not so obvious if using the default colormap.

> I
> suspect only a small fraction of users will need this.

I like this, it's a good idea enabling to not repeat all the stuff in
the code.  But hey, wouldn't it be the same to just overload the
__call__ method?

class GrayColorbar(RgbColorbar):
    """A colorbar returning grayscaled version."""

    def __call__(self, value):
        """Transforms RgbColorbar's value into grayscale, and returns it.""""

        rgb = BaseClass.__call__(self, value)
        [do stuff]
        return grayscale

Agreed, one has to this for all the classes, while your solution works
generically in ColormapBase or whatever it's called.

Another option would be, to wrap the Colormap into a thin layer with
__call__, but this appears way too clumsy and too hacky to me.  It's a
clumsy way of deriving from the class.  Otherwise it's maybe also
nice, because it's generic, for all Colormaps.  __getattr__ and
__setattr__ (iirc) could be used to simulate the wrapped instance
fully.

Is there some layer dealing with colors in the renderers, where the
conversion could also happen?  I'm asking because of displaying color
images etc. and printing them as grayscale.  With this, we would get
rid of the alpha stuff completely, too.

Maybe a general matplotlib.rc switch 'greyscale' would be possible.
It would leave room for tons of improvement, e.g. automatically
setting the color cycle to - -- -. etc., there was some monthes ago
discussion about how to achieve that.  Another advantage: It's zero
loc if set in the config file ;-)

I think that would be a real neat new feature.

I agree what's not needed is mixed greyscale and colour display in the
same Figure.

Bear with me if my ideas are always too radical.

Friedrich

On Tue, Aug 10, 2010 at 4:21 PM, Eric Firing <ef...@ha...> wrote:

> On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
> > Ah, the list config got me ... (resending to list)
> >
> > 2010/8/10 Benjamin Root<ben...@ou...>:
> >> I am working on a function that can take a Colormap object and return a
> >> grayscale form of it.  Ideally, I would like to return the same type of
> >> Colormap that was provided, but I am wondering if this is necessary.  I
> >> supposed it is sufficient to just create a LinearSegmentedColormap from
> the
> >> self._lut data?
> >>
> >> The problem I see with that approach is that there is still possibly
> some
> >> information loss, particularly with the alpha part of the rgba data.
> >> LinearSegmentedColormap has a .from_list() function, but it uses only
> the
> >> rgb part of the rgba array and does not take alpha data.
> >>
> >> Is the inability of setting alpha a problem?  Or maybe I should use
> >> deepcopy() instead?
> >
> > If you mean me, I really don't know, but I think it is always better
> > to do things
> > properly than to publish something done with the attitute "just
> > working" ....
> >
> > So I think it is probably best to code it into the Colormap object
> > itself, so that each and ever derived class can define its own method
> > of how to create a greyscale version.  What do you think about that?
>
> Good idea.  The base class could define a default to_grayscale() method
> that would do the conversion near the very end of the Colormap.__call__
> method if an as_gray attribute, also defined in the base class, is True.
>  No need for getters and setters--let it be a simple attribute.  This
> is much simpler than generating a whole new colormap--instead, just set
> an attribute to switch an existing colormap to gray or back to color.  I
> would leave the switch out of the __init__ args and kwargs.  If someone
> wants grey, they can add one more line of code to set the attribute.  I
> suspect only a small fraction of users will need this.
>
> If people really are going to want to fiddle with the conversion
> function, then the scheme above could easily be extended by allowing the
> as_gray attribute to be a callable; if it is a callable, then
> to_grayscale() would use it instead of the default function.
>
> Eric
>
> >
> > Friedrich
> >
>
>
Interesting ideas, I will try that out tonight.

Ben Root

2010/8/10 Derek Homeier <de...@as...>:
> Hi again, cc'ing the matplotlib list this time,
>
> for the latter: when building matplotlib against a fink-installed python
> compiled in 64bit mode
> I found the check for a framework-installed Python (rev 8365) fails, and
> matplotlib fails to load,
> because the MacOS module is not available in 64bit.

Hmm, do you claim that MacOS is in general not available in x86_64?
Just my 2 cents:

pb-d-128-141-26-145:~ Friedrich$ python-32
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import MacOS
>>> ^D
pb-d-128-141-26-145:~ Friedrich$ python-64
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import MacOS
>>> ^D

This is a self-compiled python.org Python 2.6.5 residing in
/Library/Frameworks/Python.framwork:
./configure --enable-framework --with-universal-archs=intel
--enable-universalsdk=/
with
MACOSX_DEPLOYMENT_TARGET=10.4
GCC=gcc-4.2

Please bear with me, but how does framework/not-framework interfere
with the build of the MacOS module?
> (assuming Python is not a framework installation if it lacks the MacOS
> module).

Are there more implications?  I always thought framework build just
means to put it in /Library/Framworks/Python.framework.

Friedrich

On 08/10/2010 10:27 AM, Friedrich Romstedt wrote:
> Ah, the list config got me ... (resending to list)
>
> 2010/8/10 Benjamin Root<ben...@ou...>:
>> I am working on a function that can take a Colormap object and return a
>> grayscale form of it.  Ideally, I would like to return the same type of
>> Colormap that was provided, but I am wondering if this is necessary.  I
>> supposed it is sufficient to just create a LinearSegmentedColormap from the
>> self._lut data?
>>
>> The problem I see with that approach is that there is still possibly some
>> information loss, particularly with the alpha part of the rgba data.
>> LinearSegmentedColormap has a .from_list() function, but it uses only the
>> rgb part of the rgba array and does not take alpha data.
>>
>> Is the inability of setting alpha a problem?  Or maybe I should use
>> deepcopy() instead?
>
> If you mean me, I really don't know, but I think it is always better
> to do things
> properly than to publish something done with the attitute "just
> working" ....
>
> So I think it is probably best to code it into the Colormap object
> itself, so that each and ever derived class can define its own method
> of how to create a greyscale version.  What do you think about that?

Good idea.  The base class could define a default to_grayscale() method 
that would do the conversion near the very end of the Colormap.__call__ 
method if an as_gray attribute, also defined in the base class, is True. 
  No need for getters and setters--let it be a simple attribute.  This 
is much simpler than generating a whole new colormap--instead, just set 
an attribute to switch an existing colormap to gray or back to color.  I 
would leave the switch out of the __init__ args and kwargs.  If someone 
wants grey, they can add one more line of code to set the attribute.  I 
suspect only a small fraction of users will need this.

If people really are going to want to fiddle with the conversion 
function, then the scheme above could easily be extended by allowing the 
as_gray attribute to be a callable; if it is a callable, then 
to_grayscale() would use it instead of the default function.

Eric

>
> Friedrich
>

Ah, the list config got me ... (resending to list)

2010/8/10 Benjamin Root <ben...@ou...>:
> I am working on a function that can take a Colormap object and return a
> grayscale form of it.  Ideally, I would like to return the same type of
> Colormap that was provided, but I am wondering if this is necessary.  I
> supposed it is sufficient to just create a LinearSegmentedColormap from the
> self._lut data?
>
> The problem I see with that approach is that there is still possibly some
> information loss, particularly with the alpha part of the rgba data.
> LinearSegmentedColormap has a .from_list() function, but it uses only the
> rgb part of the rgba array and does not take alpha data.
>
> Is the inability of setting alpha a problem?  Or maybe I should use
> deepcopy() instead?

If you mean me, I really don't know, but I think it is always better
to do things
properly than to publish something done with the attitute "just
working" ....

So I think it is probably best to code it into the Colormap object
itself, so that each and ever derived class can define its own method
of how to create a greyscale version.  What do you think about that?

Friedrich

Hi again, cc'ing the matplotlib list this time,

for the latter: when building matplotlib against a fink-installed  
python compiled in 64bit mode
I found the check for a framework-installed Python (rev 8365) fails,  
and matplotlib fails to load,
because the MacOS module is not available in 64bit. Actually Apple  
seems to have made it
still available in their system Python, but it's likely to be a  
general problem on 64bit OS X installations,
and will be for python3 as well.

>>
>> I believe I have fixed the patch file issue that came from an  
>> accidental edit of
>> the patch file (off by 1 space character).  For the issues below,  
>> can you give
>> me some examples that show the behavior that is broken now, but  
>> fixed into your
>> updated patch?  I haven't used matplotlib in a long time.
>
>
> thanks, the fixed patch in unstable compiles and runs now.
> Sorry for the late reply; I found that the issue that my extra patch  
> addressed
> actually only seems to exist for x86_64 on Snow Leopard.
> It is in fact not directly related to python being built as a  
> framework, but the
> "import MacOS" used to check for the framework version fails, since  
> the
> MacOS module is not available in 64bit. Or so the python docs state,  
> but Apple
> seems to have retrofitted it somehow into their system python, so my  
> test for
> "import MacOS" worked with /usr/bin/python even on Snow Leopard.
>
> So the test for MacOS.WMAvailable() that my patch removed can  
> obviously stay
> there for 32bit installations, and it would probably be better to  
> just catch the
> import error on 64bit systems. I'll try to work something out along  
> those lines,
> and probably send it upstream to the matplotlib folks as well, since  
> this should
> be a general problem on 64bit systems; and also the MacOS module is  
> going
> to be removed altogether in python3.x. I'll keep you posted.
>
I've put the import inside the check now and have it print the warning  
in both cases
(assuming Python is not a framework installation if it lacks the MacOS  
module).
I don't know if there might be an alternative way to check for the  
framework property
for later, and I just picked an error to raise that seemed sensible -  
feel free to change
that as necessary.

Cheers,
							Derek

On Mon, Aug 9, 2010 at 3:40 PM, Friedrich Romstedt <
fri...@gm...> wrote:

> 2010/8/6 Benjamin Root <ben...@ou...>:
> > Actually, I have been looking at a somewhat related problem.  It might be
> a
> > useful feature in matplotlib.color to provide a function that can take a
> > colormap and produce a grayscale version of it.  In my limited amount of
> > research, I have found that one could convert the rgb values into hsv or
> hsl
> > and use the "value" or "lightness" respectively for the grayscale value.
> I
> > forget which one was aesthetically better, though.
>
> http://www.pythonware.com/library/pil/handbook/image.htm :
>
> "When from a colour image to black and white, the library uses the
> ITU-R 601-2 luma transform:
>
>    L = R * 299/1000 + G * 587/1000 + B * 114/1000
> "
>
> That should also be easy to implement.
>
> Friedrich
>

I am working on a function that can take a Colormap object and return a
grayscale form of it.  Ideally, I would like to return the same type of
Colormap that was provided, but I am wondering if this is necessary.  I
supposed it is sufficient to just create a LinearSegmentedColormap from the
self._lut data?

The problem I see with that approach is that there is still possibly some
information loss, particularly with the alpha part of the rgba data.
LinearSegmentedColormap has a .from_list() function, but it uses only the
rgb part of the rgba array and does not take alpha data.

Is the inability of setting alpha a problem?  Or maybe I should use
deepcopy() instead?

Thanks,
Ben Root

2010/8/6 Benjamin Root <ben...@ou...>:
> Actually, I have been looking at a somewhat related problem.  It might be a
> useful feature in matplotlib.color to provide a function that can take a
> colormap and produce a grayscale version of it.  In my limited amount of
> research, I have found that one could convert the rgb values into hsv or hsl
> and use the "value" or "lightness" respectively for the grayscale value.  I
> forget which one was aesthetically better, though.

http://www.pythonware.com/library/pil/handbook/image.htm :

"When from a colour image to black and white, the library uses the
ITU-R 601-2 luma transform:

    L = R * 299/1000 + G * 587/1000 + B * 114/1000
"

That should also be easy to implement.

Friedrich

On Jul 30, 2010, at 8:04 PM, Jae-Joon Lee wrote:

> I don't think this is just an issue of "bbox_inches" option. For
> example, if you create an axes of rect=[0,0,1,1] and save the figure
> (w/o bbox_inches option), you will see a similar behavior.
> Also, I believe that the result depends on the backends.
> 
> I think this kind of issue is quite difficult to resolve and I doubt
> if this will be solved anytime soon.
> Any contribution will be very much appreciated.
> 
> Regards,
> 
> -JJ

I think this clipping issue is caused by a figure size that's one pixel larger than the actual canvas. Here's the example that Jae-Joon suggested:

>>> import matplotlib.pyplot as plt
>>> 
>>> fig = plt.figure(figsize=(8, 6), dpi=100)
>>> plt.axes([0, 0, 1, 1])
>>> print fig.transFigure.transform((0, 0))
>>> print fig.transFigure.transform((1, 1))
>>> plt.savefig('clipped_right_and_bottom_edge')

The saved figure is 800x600 pixels, and the right and bottom edge are clipped. Also, notice that the figure coordinate (0, 0) gets transformed to (0, 0) in pixel space (display space?), while the figure coordinate (1, 1) gets transformed to (800, 600) in pixel space. But, a figure that includes a point at (0, 0) and (800, 600) would have to be at least 801x601 in size.

The strange part is that the origin of the figure space is the bottom-left, but the image gets clipped at the bottom and right edges. I would have expected the bottom-and-left edges *or* the top-and-right edges to be clipped.

Best,
-Tony


> 
> 
> On Sat, Jul 31, 2010 at 5:48 AM, Damon McDougall
> <D.M...@wa...> wrote:
>> Aha! Even without the text, i.e. setting label1On = False for all the major ticks, the behaviour I see is that with bbox_inches = 'tight' and pad_inches = 0.0 I get the saved figure which includes the black border line for the bottom and left edges, but not the top and right edges. This may have something to do with it. Maybe it's an issue with the bounding box not being 'inclusive' and leaving out the end points?
>> 
>> Regards,
>> -- Damon
>> 
>> --------------------------
>> Damon McDougall
>> Mathematics Institute
>> University of Warwick
>> Coventry
>> CV4 7AL
>> d.m...@wa...
>> 
>> 
>> 
>> On 30 Jul 2010, at 20:33, Eric Firing wrote:
>> 
>>> On 07/30/2010 06:32 AM, Damon McDougall wrote:
>>>> Hmm, it seems as though tick labels get clipped on the top and on the right when passing bbox_inches='tight' and pad_inches=0.0. I wouldn't expect this behaviour. Is there perhaps a bug in Bbox.union that's causing this?
>>>> 
>>> 
>>> Not likely.  Much more likely is a problem in calculating the rendered
>>> size of the text.
>>> 
>>> Eric
>>> 
>>>> Regards,
>>>> -- Damon
>>>> 
>>>> --------------------------
>>>> Damon McDougall
>>>> Mathematics Institute
>>>> University of Warwick
>>>> Coventry
>>>> CV4 7AL
>>>> d.m...@wa...

>> I tried to use "edgecolor = 'none'" in a call to bar(), hoping to get no
>> border to the bars, but instead got no bars at all.
>
> Just to note, the documentation does specify a difference between None and
> 'none'.  None means to use the rcdefaults and 'none' means no color at all.
> Is bar() just simply not properly handling the 'none' case?

That's right, yes.  Currently, bar() does not handle the string 'none'
properly; it results in an empty graph.  E.g.:

   bar([1, 2, 3], [12, 13, 14], edgecolor = None)

behaves correctly, giving a bar chart with black-edged blue bars.

   bar([1, 2, 3], [12, 13, 14], edgecolor = 'none')

gives no graph at all.  After the patch, the second call gives the right
result, a bar-chart with border-less blue bars.  Same kind of thing with
the kwarg 'color' instead of 'edgecolor', which is also fixed in my
second recent email.

Hope this clarifies things.  Thanks,

Ben.

On Mon, Aug 9, 2010 at 3:28 AM, Ben North <be...@re...> wrote:

> Hi,
>
> I tried to use "edgecolor = 'none'" in a call to bar(), hoping to get no
> border to the bars, but instead got no bars at all.  The patch below
> (against 1.0.0) seems to fix this; it adds a check for 'none' to the
> existing check for None as a special case of the edgecolor argument.
>
> Thanks,
>
> Ben.
>
>
>
>
> --- ORIG-axes.py        2010-07-06 15:43:35.000000000 +0100
> +++ NEW-axes.py 2010-08-09 09:16:51.000004000 +0100
> @@ -4582,8 +4582,9 @@
>             if len(color) < nbars:
>                 color *= nbars
>
> -        if edgecolor is None:
> -            edgecolor = [None] * nbars
> +        if (edgecolor is None
> +            or (is_string_like(edgecolor) and edgecolor.lower() ==
> 'none')):
> +            edgecolor = [edgecolor] * nbars
>         else:
>             edgecolor =
> list(mcolors.colorConverter.to_rgba_array(edgecolor))
>             if len(edgecolor) < nbars:
>
>
Just to note, the documentation does specify a difference between None and
'none'.  None means to use the rcdefaults and 'none' means no color at all.
Is bar() just simply not properly handling the 'none' case?

Ben Root