[matplotlib-devel] Handle 'none' as color and edgecolor for bar()
Hi, Update to my recent email: perhaps it would make sense to handle the 'color' argument in the same way, allowing hollow bars. Combined patch below. Ben. --- ORIG-axes.py2010-07-06 15:43:35.0 +0100 +++ NEW-axes.py 2010-08-09 09:39:44.000256000 +0100 @@ -4575,15 +4575,17 @@ if len(linewidth) < nbars: linewidth *= nbars -if color is None: -color = [None] * nbars +if (color is None +or (is_string_like(color) and color.lower() == 'none')): +color = [color] * nbars else: color = list(mcolors.colorConverter.to_rgba_array(color)) 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: -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Fixing 'FIXME' in bar()
Hi,
While looking at axes.py for the color/edgecolor patch just sent, I
noticed the FIXME suggesting ValueError instead of assert. Is the below
the kind of thing?
Ben.
--- ORIG-axes.py2010-07-06 15:43:35.0 +0100
+++ NEW-axes.py 2010-08-09 09:43:30.000257000 +0100
@@ -4589,15 +4589,12 @@
if len(edgecolor) < nbars:
edgecolor *= nbars
-# FIXME: convert the following to proper input validation
-# raising ValueError; don't use assert for this.
-assert len(left)==nbars, "incompatible sizes: argument 'left'
must be length %d or scalar" % nbars
-assert len(height)==nbars, ("incompatible sizes: argument
'height' must be length %d or scalar" %
-nbars)
-assert len(width)==nbars, ("incompatible sizes: argument
'width' must be length %d or scalar" %
- nbars)
-assert len(bottom)==nbars, ("incompatible sizes: argument
'bottom' must be length %d or scalar" %
-nbars)
+for argname in ['left', 'height', 'width', 'bottom']:
+arg = locals()[argname]
+if len(arg) != nbars:
+raise ValueError("incompatible sizes:"
+ " argument '%s' must be length %d or scalar"
+ % (argname, nbars))
patches = []
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Handle 'none' as edgecolor for bar()
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.py2010-07-06 15:43:35.0 +0100 +++ NEW-axes.py 2010-08-09 09:16:51.04000 +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: -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Handle 'none' as edgecolor for bar()
On Mon, Aug 9, 2010 at 3:28 AM, Ben North 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.py2010-07-06 15:43:35.0 +0100 > +++ NEW-axes.py 2010-08-09 09:16:51.04000 +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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Handle 'none' as edgecolor for bar()
>> 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. -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Exploring
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
> 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.mcdoug...@warwick.ac.uk
>>
>>
>>
>> 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.mcdoug...@warwick.ac.uk
--
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
2010/8/6 Benjamin Root : > 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Colormap that prints nicely in black and white
On Mon, Aug 9, 2010 at 3:40 PM, Friedrich Romstedt < friedrichromst...@gmail.com> wrote: > 2010/8/6 Benjamin Root : > > 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
