matplotlib-devel Mailing List for matplotlib (Page 472)

>>>>> "Fernando" == Fernando Perez <fpe...@gm...> writes:

    Fernando> Sure, your call.  Safety above convenience is a good
    Fernando> overall mantra.

There is a hybrid approach, but it gets away from the neat and tidy
approach suggested by Eric.  If any of the args in the tuple are
greater than one, we could assume it is 0..255, else assume 0..1.  But
I think consistency may trump convenience here.

JDH 

On 5/21/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Fernando" =3D=3D Fernando Perez <fpe...@gm...> writes:
>
>     Fernando> (R,G,B).float_tuple -> floats in the 0...1 range
>     Fernando> (R,G,B).int_tuple -> floats in the 0..255 range.
>
> My worry here is that it is pretty common to do something like
>
>   red =3D 1,0,0
>
> which in your system would be interpreted as a int tuple and hence in
> the 0..255 range.  It may be easier for people to divide by 255.0 when
> they have vals in the 0..255 range than it is for them to remember to
> use ints and float consistently.

Sure, your call.  Safety above convenience is a good overall mantra.

Cheers,

f

>>>>> "Fernando" == Fernando Perez <fpe...@gm...> writes:

    Fernando> (R,G,B).float_tuple -> floats in the 0...1 range
    Fernando> (R,G,B).int_tuple -> floats in the 0..255 range.

My worry here is that it is pretty common to do something like

  red = 1,0,0

which in your system would be interpreted as a int tuple and hence in
the 0..255 range.  It may be easier for people to divide by 255.0 when
they have vals in the 0..255 range than it is for them to remember to
use ints and float consistently.

JDH

On 5/21/06, Eric Firing <ef...@ha...> wrote:
> Darren Dale wrote:
> > On Sunday 21 May 2006 15:26, John Hunter wrote:
> >
> >>>>>>>"Eric" =3D=3D Eric Firing <ef...@ha...> writes:
> >>
> >>    Eric> Suggestion: we say, "A color can be specified as a string in
> >>    Eric> any of the following formats: standard color abbreviations,
> >>    Eric> html names, hex, or a floating point number between 0 and 1.
> >>    Eric> Or it can be given as a sequence of three numbers specifying
> >>    Eric> R,G,B on a scale from 0 to 1."  Perfectly consistent and
> >>    Eric> understandable, and clear in the code: "if
> >>    Eric> is_string_like(c): convert it, else: pass it on as RGB.
> >>    Eric> This consistency then makes it easy to distinguish between,
> >>    Eric> and transparently handle, the case of a single color versus
> >>    Eric> a sequence of colors.
> >>
> >>OK, you sold me.  I hadn't thought it through to see it was either a
> >>string, RGB/A.  I like the simplicity of this.  So I'm +1 for your
> >>suggestion with a deprecation period where we check for a scalar

As a minor comment, for the sake of completeness wouldn't it be nice to all=
ow

(R,G,B).float_tuple -> floats in the 0...1 range
(R,G,B).int_tuple -> floats  in the 0..255 range.

?

It's extremely common to see 0..255 specifications for colors.

Cheers,

f

Darren Dale wrote:
> On Sunday 21 May 2006 15:26, John Hunter wrote:
> 
>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>
>>    Eric> Suggestion: we say, "A color can be specified as a string in
>>    Eric> any of the following formats: standard color abbreviations,
>>    Eric> html names, hex, or a floating point number between 0 and 1.
>>    Eric> Or it can be given as a sequence of three numbers specifying
>>    Eric> R,G,B on a scale from 0 to 1."  Perfectly consistent and
>>    Eric> understandable, and clear in the code: "if
>>    Eric> is_string_like(c): convert it, else: pass it on as RGB.
>>    Eric> This consistency then makes it easy to distinguish between,
>>    Eric> and transparently handle, the case of a single color versus
>>    Eric> a sequence of colors.
>>
>>OK, you sold me.  I hadn't thought it through to see it was either a
>>string, RGB/A.  I like the simplicity of this.  So I'm +1 for your
>>suggestion with a deprecation period where we check for a scalar
> 
> 
> For what its worth, I'll also drop my objection.

Thanks. I will proceed.

Eric

On Sunday 21 May 2006 15:26, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
>     Eric> Suggestion: we say, "A color can be specified as a string in
>     Eric> any of the following formats: standard color abbreviations,
>     Eric> html names, hex, or a floating point number between 0 and 1.
>     Eric> Or it can be given as a sequence of three numbers specifying
>     Eric> R,G,B on a scale from 0 to 1."  Perfectly consistent and
>     Eric> understandable, and clear in the code: "if
>     Eric> is_string_like(c): convert it, else: pass it on as RGB.
>     Eric> This consistency then makes it easy to distinguish between,
>     Eric> and transparently handle, the case of a single color versus
>     Eric> a sequence of colors.
>
> OK, you sold me.  I hadn't thought it through to see it was either a
> string, RGB/A.  I like the simplicity of this.  So I'm +1 for your
> suggestion with a deprecation period where we check for a scalar

For what its worth, I'll also drop my objection.

Darren

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Suggestion: we say, "A color can be specified as a string in
    Eric> any of the following formats: standard color abbreviations,
    Eric> html names, hex, or a floating point number between 0 and 1.
    Eric> Or it can be given as a sequence of three numbers specifying
    Eric> R,G,B on a scale from 0 to 1."  Perfectly consistent and
    Eric> understandable, and clear in the code: "if
    Eric> is_string_like(c): convert it, else: pass it on as RGB.
    Eric> This consistency then makes it easy to distinguish between,
    Eric> and transparently handle, the case of a single color versus
    Eric> a sequence of colors.

OK, you sold me.  I hadn't thought it through to see it was either a
string, RGB/A.  I like the simplicity of this.  So I'm +1 for your
suggestion with a deprecation period where we check for a scalar

I just looked in cbook and we did indeed have an is_scalar function
but it looked broken so I replaced it with

def is_scalar(obj):
    try: obj+1
    except TypeError: return False
    else: return True


As for looks_like_color, I never use it (in fact was not aware of it
til you mentioned it).  I think a function "is_colorlike" is a
potentially useful function, but as you say it is best implemented
with duck typing, something like

def is_colorlike(x):
    try: colorConverter.to_rgba(x)
    except: return False
    else: return True

JDH
  

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, I think all the ambiguity that you mention below comes
>     Eric> from one source: the use of a single float to indicate a
>     Eric> greyscale.  Do we really need this? It is not supported by
>     Eric> colors.looks_like_color().  It could be replaced by a string
>     Eric> representation of the float (e.g., '0.75') or by a more
>     Eric> specific string, such as 'g0.75' or 'grey0.75'.  I think
>     Eric> this would be a big net gain for mpl.  We lose a lot of
>     Eric> flexibility, convenience, and consistency by allowing the
>     Eric> float-is-grey form.
> 
> this is a bug in looks_like_color -- ColorConverter, for example,
> supports it.

I suspect that all support of this form does occur via ColorConverter; 
it is interesting that the looks_like_color bug has not caused 
objections.  looks_like_color is used in only two places: Axes.quiver, 
which therefore does not support the present float-as-grayscale form, 
and Collection._get_color.  The consequence is that the collection rc 
settings also do not support float-as-grayscale, but nobody has noticed, 
or if they have, they have not been greatly bothered.

I also suspect that we should not have looks_like_color at all--it 
probably makes more sense to simply try to convert the object, and catch 
an exception if it is not convertable.  If the object does look like a 
color, then chances are one wants to convert it anyway, so why go 
through most of the logic twice.  (For compatibility, looks_like_color 
could simply do this--try to convert, return True on success and False 
on failure.)

> 
> What flexibility do we lose by supporting grayscale as float? As long
> as we have a policy of how we resolve ambiguity, I think we're OK.

Maybe OK, but not good. It is much better to avoid ambiguity entirely 
than to have to implement and explain an ambiguity resolution policy, 
when avoiding the ambiguity entails no loss in flexibility.

Present situation: we have to say something like, "(0.3, 0.4, 0.2) is a 
single RGB, but (0.3, 0.4) is a pair of greyscales".  That's ugly and 
inconsistent, both from the users' standpoint and in terms of what it 
requires in the code.

Suggestion: we say, "A color can be specified as a string in any of the 
following formats: standard color abbreviations, html names, hex, or a 
floating point number between 0 and 1.  Or it can be given as a sequence 
of three numbers specifying R,G,B on a scale from 0 to 1."  Perfectly 
consistent and understandable, and clear in the code: "if 
is_string_like(c): convert it, else: pass it on as RGB.  This 
consistency then makes it easy to distinguish between, and transparently 
handle, the case of a single color versus a sequence of colors.

(I posed everything in terms of RGB rather than RGBA, but the idea is 
the same.)

> Eg, ef we have a four-tuple of floats in a case where it could mean
> four grays or one RGB, we can choose to resolve it one way or the
> other.  I think this is a corner case and wouldn't come up to often.

But when it does come up, sometimes the disambiguation will not do what 
the user expected.  It is a fundamentally bad design, and it will bite 
people as long as it stays in place.

> As long as we have a way of disambiguating, eg adopting your 'g0.75'
> or 0.75' as a valid string, we retain flexibility and compatibility.

My proposal retains flexibility and increases simplicity and consistency 
by sacrificing the compatibility.  I think this is a case where it is 
worth it to do so.

> 
> I also use the float-as-grayscale not too infrequently....

But maybe with a long deprecation period, you wouldn't terribly mind 
occasionally changing (0.2, 0.3) to ('0.2', '0.3')?  (I know, it is easy 
for me because I am not the one who has to deal with it.)

Eric

>>>>> "Darren" == Darren Dale <dd...@co...> writes:

    Darren> slightly off-topic: Will mpl ever go 1.0? That's not meant
    Darren> to be flippant. I thought their was some pride in being
    Darren> beta.

I figured we would go to 1.0 when we run out of 0.88, 0.89, 0.90....

I think the API is pretty stable already, and suspect we won't be able
to guarantee much more stability after 1.0.  Think about pygtk -- it
changed like a madman from 1.6 to 1.99 to 2.2 to 2.4...  Sure, Numeric
was pretty stable after 10 years and 23 major releases, but then that
was broken with numarray and numpy.  I'm not sure that API stability
above and beyond what we are already providing exists that much in the
wild, so 1.0 is probably more of a psychological landmark than
anything else.  But maybe I'm just crazy.

I would like to fix the axis handling to be more flexible (eg, multiple
y axis lines per plot, detacable axis lines, etc) before 1.0.  

JDH

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, I think all the ambiguity that you mention below comes
    Eric> from one source: the use of a single float to indicate a
    Eric> greyscale.  Do we really need this? It is not supported by
    Eric> colors.looks_like_color().  It could be replaced by a string
    Eric> representation of the float (e.g., '0.75') or by a more
    Eric> specific string, such as 'g0.75' or 'grey0.75'.  I think
    Eric> this would be a big net gain for mpl.  We lose a lot of
    Eric> flexibility, convenience, and consistency by allowing the
    Eric> float-is-grey form.

this is a bug in looks_like_color -- ColorConverter, for example,
supports it.

What flexibility do we lose by supporting grayscale as float? As long
as we have a policy of how we resolve ambiguity, I think we're OK.
Eg, ef we have a four-tuple of floats in a case where it could mean
four grays or one RGB, we can choose to resolve it one way or the
other.  I think this is a corner case and wouldn't come up to often.
As long as we have a way of disambiguating, eg adopting your 'g0.75'
or 0.75' as a valid string, we retain flexibility and compatibility.

I also use the float-as-grayscale not too infrequently....

JDH

On Saturday 20 May 2006 15:47, Eric Firing wrote:
> Darren Dale wrote:
> > I have used floats to indicate color in many of my own scripts. I think
> > changing this would have a pretty big impact on the users.
> >
> > Darren
>
> Darren,
>
> Float as greyscale, right?

Yes, that's what I meant.

> Yes, I am concerned about breaking things, but maybe it is not too late
> to deprecate it, so that the transition could be made some time in the
> future.  I think it is worth considering this carefully now, while we
> are still pre-1.0.

slightly off-topic: Will mpl ever go 1.0? That's not meant to be flippant. I 
thought their was some pride in being beta.

> >>John,
> >>
> >>I think all the ambiguity that you mention below comes from one source:
> >>the use of a single float to indicate a greyscale.  Do we really need
> >>this? It is not supported by colors.looks_like_color().  It could be
> >>replaced by a string representation of the float (e.g., '0.75') or by a
> >>more specific string, such as 'g0.75' or 'grey0.75'.  I think this would
> >>be a big net gain for mpl.  We lose a lot of flexibility, convenience,
> >>and consistency by allowing the float-is-grey form.
> >>
> >>Eric
> >>
> >>John Hunter wrote:
> >>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> >>>
> >>>    Eric> John, Collections would be easier to use if they did not
> >>>    Eric> have the restriction (from the docstring):
> >>>
> >>>    Eric>      All color args to a collection are sequences of rgba
> >>>    Eric> tuples
> >>>
> >>>    Eric> It would be easy to remove this restriction; shall I do it,
> >>>    Eric> or is there a reason to leave the restriction in place?
> >>>    Eric> (The error message that results from violating the
> >>>    Eric> restriction is not helpful, and it would be as easy to
> >>>    Eric> remove the restriction as to improve the error handling.)
> >>>
> >>>I think it's fine to remove it, but note that you have to be careful
> >>>to avoid ambiguity.  How would you interpret
> >>>
> >>>  color = (0.25, 0.5, 0.75, 1.0)
> >>>
> >>>Is this one rgba color or 4 grayscales?
> >>>
> >>>Because mpl accepts lots of different types of args for colors, there
> >>>will probably be some ambiguous cases, thought these will be very rare
> >>>corner cases.  Just document what the behavior is, and everyone should
> >>>be happy.  I think you could do the same for the linewidths, etc.  Eg
> >>>if scalar, interpret as a single linewidth for all elements of the
> >>>collection?
> >>>
> >>>Or were you intending to preserve the requirement that one pass
> >>>sequences, but allow versatile color args in the sequence?
> >>>
> >>>JDH
> >>
> >>-------------------------------------------------------
> >>Using Tomcat but need to do more? Need to support web services, security?
> >>Get stuff done quickly with pre-integrated technology to make your job
> >>easier
> >>Download IBM WebSphere Application Server v.1.0.1 based on Apache
> >> Geronimo
> >> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> >> _______________________________________________
> >>Matplotlib-devel mailing list
> >>Mat...@li...
> >>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853

dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

Darren Dale wrote:
> I have used floats to indicate color in many of my own scripts. I think
> changing this would have a pretty big impact on the users.
> 
> Darren

Darren,

Float as greyscale, right?

Yes, I am concerned about breaking things, but maybe it is not too late 
to deprecate it, so that the transition could be made some time in the 
future.  I think it is worth considering this carefully now, while we 
are still pre-1.0.

Eric

> 
> 
>>John,
>>
>>I think all the ambiguity that you mention below comes from one source:
>>the use of a single float to indicate a greyscale.  Do we really need
>>this? It is not supported by colors.looks_like_color().  It could be
>>replaced by a string representation of the float (e.g., '0.75') or by a
>>more specific string, such as 'g0.75' or 'grey0.75'.  I think this would
>>be a big net gain for mpl.  We lose a lot of flexibility, convenience,
>>and consistency by allowing the float-is-grey form.
>>
>>Eric
>>
>>John Hunter wrote:
>>
>>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>>
>>>
>>>    Eric> John, Collections would be easier to use if they did not
>>>    Eric> have the restriction (from the docstring):
>>>
>>>    Eric>      All color args to a collection are sequences of rgba
>>>    Eric> tuples
>>>
>>>    Eric> It would be easy to remove this restriction; shall I do it,
>>>    Eric> or is there a reason to leave the restriction in place?
>>>    Eric> (The error message that results from violating the
>>>    Eric> restriction is not helpful, and it would be as easy to
>>>    Eric> remove the restriction as to improve the error handling.)
>>>
>>>I think it's fine to remove it, but note that you have to be careful
>>>to avoid ambiguity.  How would you interpret
>>>
>>>  color = (0.25, 0.5, 0.75, 1.0)
>>>
>>>Is this one rgba color or 4 grayscales?
>>>
>>>Because mpl accepts lots of different types of args for colors, there
>>>will probably be some ambiguous cases, thought these will be very rare
>>>corner cases.  Just document what the behavior is, and everyone should
>>>be happy.  I think you could do the same for the linewidths, etc.  Eg
>>>if scalar, interpret as a single linewidth for all elements of the
>>>collection?
>>>
>>>Or were you intending to preserve the requirement that one pass
>>>sequences, but allow versatile color args in the sequence?
>>>
>>>JDH
>>
>>
>>
>>-------------------------------------------------------
>>Using Tomcat but need to do more? Need to support web services, security?
>>Get stuff done quickly with pre-integrated technology to make your job
>>easier
>>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>>_______________________________________________
>>Matplotlib-devel mailing list
>>Mat...@li...
>>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
> 
> 
> 

I have used floats to indicate color in many of my own scripts. I think
changing this would have a pretty big impact on the users.

Darren

> John,
>
> I think all the ambiguity that you mention below comes from one source:
> the use of a single float to indicate a greyscale.  Do we really need
> this? It is not supported by colors.looks_like_color().  It could be
> replaced by a string representation of the float (e.g., '0.75') or by a
> more specific string, such as 'g0.75' or 'grey0.75'.  I think this would
> be a big net gain for mpl.  We lose a lot of flexibility, convenience,
> and consistency by allowing the float-is-grey form.
>
> Eric
>
> John Hunter wrote:
>>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
>>
>>
>>     Eric> John, Collections would be easier to use if they did not
>>     Eric> have the restriction (from the docstring):
>>
>>     Eric>      All color args to a collection are sequences of rgba
>>     Eric> tuples
>>
>>     Eric> It would be easy to remove this restriction; shall I do it,
>>     Eric> or is there a reason to leave the restriction in place?
>>     Eric> (The error message that results from violating the
>>     Eric> restriction is not helpful, and it would be as easy to
>>     Eric> remove the restriction as to improve the error handling.)
>>
>> I think it's fine to remove it, but note that you have to be careful
>> to avoid ambiguity.  How would you interpret
>>
>>   color = (0.25, 0.5, 0.75, 1.0)
>>
>> Is this one rgba color or 4 grayscales?
>>
>> Because mpl accepts lots of different types of args for colors, there
>> will probably be some ambiguous cases, thought these will be very rare
>> corner cases.  Just document what the behavior is, and everyone should
>> be happy.  I think you could do the same for the linewidths, etc.  Eg
>> if scalar, interpret as a single linewidth for all elements of the
>> collection?
>>
>> Or were you intending to preserve the requirement that one pass
>> sequences, but allow versatile color args in the sequence?
>>
>> JDH
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John,

I think all the ambiguity that you mention below comes from one source: 
the use of a single float to indicate a greyscale.  Do we really need 
this? It is not supported by colors.looks_like_color().  It could be 
replaced by a string representation of the float (e.g., '0.75') or by a 
more specific string, such as 'g0.75' or 'grey0.75'.  I think this would 
be a big net gain for mpl.  We lose a lot of flexibility, convenience, 
and consistency by allowing the float-is-grey form.

Eric

John Hunter wrote:
>>>>>>"Eric" == Eric Firing <ef...@ha...> writes:
> 
> 
>     Eric> John, Collections would be easier to use if they did not
>     Eric> have the restriction (from the docstring):
> 
>     Eric>      All color args to a collection are sequences of rgba
>     Eric> tuples
> 
>     Eric> It would be easy to remove this restriction; shall I do it,
>     Eric> or is there a reason to leave the restriction in place?
>     Eric> (The error message that results from violating the
>     Eric> restriction is not helpful, and it would be as easy to
>     Eric> remove the restriction as to improve the error handling.)
> 
> I think it's fine to remove it, but note that you have to be careful
> to avoid ambiguity.  How would you interpret
> 
>   color = (0.25, 0.5, 0.75, 1.0)
> 
> Is this one rgba color or 4 grayscales?  
> 
> Because mpl accepts lots of different types of args for colors, there
> will probably be some ambiguous cases, thought these will be very rare
> corner cases.  Just document what the behavior is, and everyone should
> be happy.  I think you could do the same for the linewidths, etc.  Eg
> if scalar, interpret as a single linewidth for all elements of the
> collection?
> 
> Or were you intending to preserve the requirement that one pass
> sequences, but allow versatile color args in the sequence?
> 
> JDH

>>>>> "Robert" == Robert Brown <br...@uc...> writes:

    Robert> Legend() works great when you're using plot, but when you
    Robert> use errorbar the auto-generated legend seems to include
    Robert> bar and/or cap lines for the error bars, making it
    Robert> unusable.

    Robert> I fixed this once a long time ago by making the legend
    Robert> command skip any lines without labels.  It was kind of a
    Robert> hack....

    Robert> Having installed the latest version on my new MacBook Pro,
    Robert> I found a better way to fix the problem too.  In the
    Robert> errorbar method of Axes I added label='_nolegend_' to the
    Robert> plotting commands.  If a developer would like to add it,
    Robert> here are my modified lines 1577-1580 and 1590-1593 of
    Robert> axes.py:

Done -- thanks!

svn revision 2401

JDH

Legend() works great when you're using plot, but when you use  
errorbar the auto-generated legend seems to include bar and/or cap  
lines for the error bars, making it unusable.

I fixed this once a long time ago by making the legend command skip  
any lines without labels.  It was kind of a hack....

Having installed the latest version on my new MacBook Pro, I found a  
better way to fix the problem too.  In the errorbar method of Axes I  
added label='_nolegend_' to the plotting commands.  If a developer  
would like to add it, here are my modified lines 1577-1580 and  
1590-1593 of axes.py:

             barlines.extend( self.hlines(y, x,  
left,label='_nolegend_') )
             barlines.extend( self.hlines(y, x,  
right,label='_nolegend_') )
             caplines.extend( self.plot(left, y, '|',  
ms=2*capsize,label='_nolegend_') )
             caplines.extend( self.plot(right, y, '|',  
ms=2*capsize,label='_nolegend_') )



             barlines.extend( self.vlines(x, y,  
upper,label='_nolegend_' ) )
             barlines.extend( self.vlines(x, y,  
lower,label='_nolegend_' ) )
             caplines.extend( self.plot(x, lower, '_',  
ms=2*capsize,label='_nolegend_') )
             caplines.extend( self.plot(x, upper, '_',  
ms=2*capsize,label='_nolegend_') )



---------------------------------------------------
Robb Brown
Biomedical Engineering
University of Calgary
Calgary, Alberta, Canada

>     Jordan> Here's a reference talking about the different coordinate
>     Jordan> systems accessible in matplotlib:
>
>     Jordan> http://www.scipy.org/Cookbook/Matplotlib/Transformations
>
>     Jordan> I think what we need is to set the coordinate transform to
>     Jordan> be in and absolute, instead of relative, coordinate
>     Jordan> system, or to build one ourselves.  But I don't know
>     Jordan> enough about matplotlib's internals to know if this is
>     Jordan> right.  Comments?
>
> This is probably what you want to do.  You want to define your arrow
> in something like points, then do a rotation, and then apply one of
> the transformation offsets to place your arrow at an x,y location.
> Note there is a bug in some version of matplotlib in the affine code
> which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
> and be pointing NW and measure 2 inches from base to tip.  The arrow
> size is independent of zoom and figure window size, which may or may
> not be desirable....
>   
Wow, that's service.  Yeah, that's almost exactly what we want... but 
you are right, it would be better if the arrow scaled with the figure 
size, but maintained it's aspect ratio.  I'll try to play around with 
your example and figure out how to make it work.  Thanks a lot.

Jordan

John Hunter wrote:
>     Jordan> I think what we need is to set the coordinate transform to
>     Jordan> be in and absolute, instead of relative, coordinate
>     Jordan> system,

> This is probably what you want to do.  You want to define your arrow
> in something like points, then do a rotation, and then apply one of
> the transformation offsets to place your arrow at an x,y location.

This sounds a lot like what a I did a while ago (following suggested 
code form JDH), and posted here. My intent is to clean it up so that it 
can get included in MPL, but I haven't had the chance. Meanwhile, here 
it is again. Use it as you will.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

>>>>> "Jordan" == Jordan Dawe <jdawe@u.washington.edu> writes:

    Jordan> Here's a reference talking about the different coordinate
    Jordan> systems accessible in matplotlib:

    Jordan> http://www.scipy.org/Cookbook/Matplotlib/Transformations

    Jordan> I think what we need is to set the coordinate transform to
    Jordan> be in and absolute, instead of relative, coordinate
    Jordan> system, or to build one ourselves.  But I don't know
    Jordan> enough about matplotlib's internals to know if this is
    Jordan> right.  Comments?

This is probably what you want to do.  You want to define your arrow
in something like points, then do a rotation, and then apply one of
the transformation offsets to place your arrow at an x,y location.
Note there is a bug in some version of matplotlib in the affine code
which is fixes in SVN -- this arrow should have it's base at 0.5, 0.5
and be pointing NW and measure 2 inches from base to tip.  The arrow
size is independent of zoom and figure window size, which may or may
not be desirable....

from matplotlib.transforms import Affine, Value, zero
from matplotlib.patches import Polygon
from pylab import figure, show, nx


fig = figure()
ax = fig.add_subplot(111, xlim=(0,1), ylim=(0,1), autoscale_on=False)

sx = 144/72.*fig.dpi.get()  # 2 inches
sy = 144/72.*fig.dpi.get()
theta = 45*nx.pi/180.

# arrow drawn in pixels
trans = Affine(
    Value(sx*nx.cos(theta)),
    Value(sx*nx.sin(theta)),
    Value(-sy*nx.sin(theta)),
    Value(sy*nx.cos(theta)),
    zero(),
    zero())

verts = [
    (-0.05,0.75),
    (0, 1.),
    (0.05,0.75),
    (0.05,0),
    (-0.05,0),
    ]

# offset in data coords
trans.set_offset((0.5, 0.5), ax.transData)
poly = Polygon(verts, transform=trans)

ax.add_patch(poly)
show()

Gary Ruben wrote:
> Hi Jordan,
> When I zoom, if the x and y zooms are not locked you will still get 
> the problem you mention with my modified arrows. They're still just 
> patches locked to the current x and y coordinates.
> I've attached my modified Arrow() in case you want to look at it. It 
> requires a change to quiver in axes.py too to add the arrowstyle 
> parameter and pass it through but you can just ignore that stuff and 
> remove the arrowstyle references if you want to try it out. The 
> changes just keep the arrow head length fixed and adjust the length of 
> the arrow shaft until it gets so short that it becomes necessary to 
> start scaling down the width in proportion with the length (I'm not 
> sure if that makes sense).
> Gary
That makes a lot of sense.  I've just been changing this line:

    arrow[:,1] *= width

to

    arrow[:,1] *= L*width

but this, of course, ends up with some weird looking arrows at the ends 
of the data range

The main problem with quiver as it currently exists is that, if say you 
plot:

quiver(ones([1,2]),ones([1,2]))

You end up with arrows that are twice as tall as they are wide, instead 
of 45 degree arrows.  This is definitely a bug, not a feature.

Here's a reference talking about the different coordinate systems 
accessible in matplotlib:

http://www.scipy.org/Cookbook/Matplotlib/Transformations

I think what we need is to set the coordinate transform to be in and 
absolute, instead of relative, coordinate system, or to build one 
ourselves.  But I don't know enough about matplotlib's internals to know 
if this is right.  Comments?

Jordan

Hi Jordan,
When I zoom, if the x and y zooms are not locked you will still get the 
problem you mention with my modified arrows. They're still just patches 
locked to the current x and y coordinates.
I've attached my modified Arrow() in case you want to look at it. It 
requires a change to quiver in axes.py too to add the arrowstyle 
parameter and pass it through but you can just ignore that stuff and 
remove the arrowstyle references if you want to try it out. The changes 
just keep the arrow head length fixed and adjust the length of the arrow 
shaft until it gets so short that it becomes necessary to start scaling 
down the width in proportion with the length (I'm not sure if that makes 
sense).
Gary

Jordan Dawe wrote:
<snip>
> Wow, serendipitously I'm working on exactly the same thing at the 
> moment.  Question: when you zoom, do you ensure that the x-direction in 
> your window is the same length as the y-direction?  My current theory on 
> this is the distorted arrows are the result of quiver measuring 
> everything in the x-y space of the plot, instead of in absolute terms.  
> Setting axis('equal') or axis('scaled') seems to improve the arrow 
> appearance...
> 
> Jordan

Hi John,
I'll have a look at this over the weekend.
 From the link and example you provided I'm not yet sure that subpixel 
rendering is the problem, but it could well be - What I'm getting is the 
vertices displaced away from the expected position by quite a way, but 
I'll see if the patch you made is at the Python level, in which case I 
can try it easily, or if at the C level, it may be time to try my Ubuntu 
installation out and finally learn to build from source.
thanks,
Gary

>>>>> "Gary" == Gary Ruben <gr...@bi...> writes:

    Gary> I've been rewriting the Arrow class in patches.py to improve
    Gary> the look of quiver plots and am getting generally good
    Gary> results. The problems with current quiver plots are that
    Gary> arrows representing very small values are scaled along their
    Gary> length but not in width and also that arrowheads are not of
    Gary> a constant size. I have addressed both of these problems and
    Gary> getting results much more like Matlab quiver plots
    Gary> now. However, now that I am scaling arrow patches down to
    Gary> very small sizes, I see weird shaped arrows at some zoom
    Gary> levels but when I zoom in close enough to see the shape
    Gary> properly they look nicely formed. Is there a known problem,
    Gary> perhaps with Agg doing some fancy truncation in order to
    Gary> achieve good speed, where patches are distorted if their
    Gary> vertices are very close together at a particular
    Gary> magnification? I can provide code and graphic examples if it
    Gary> would help.

My guess is that this has something to do with subpixel rendering, and
it has cropped up in a number of circumstances.  Unfortunately, I
don't know of an easy answer.  If you tell agg to draw a line from 0,0
to 1,1, the line will look different than a line from .5,.5 to 1.5,1.5

See
http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html#PAGE_LINE_ALIGNMENT

One way to confirm that this is your problem is to turn antialiasing
off

  patch.set_antialiased(False)

but I just noticed that the agg draw_polygon method does not respect
the aa setting, so I just committed changes to svn to fix this.  Do
you have access to svn?

With svn in the example below, the green polygon should look more
jaggy than the yellow one.  My guess is that this weirdness for small
arrows will go away with antialiasing off, but then you will have
crappy, aliased arrows.  Not sure what the right answer is...

from matplotlib.patches import RegularPolygon
from pylab import figure, show

p1 = RegularPolygon((1,1), 5, antialiased=True, facecolor='yellow', linewidth=5)
p2 = RegularPolygon((0,0), 5, antialiased=False, facecolor='green', linewidth=5, alpha=0.5)

fig = figure()
ax = fig.add_subplot(111, xlim=(-6,6), ylim=(-6,6), autoscale_on=False)
ax.add_patch(p1)
ax.add_patch(p2)
show()



JDH

Gary Ruben wrote:
> I've been rewriting the Arrow class in patches.py to improve the look 
> of quiver plots and am getting generally good results. The problems 
> with current quiver plots are that arrows representing very small 
> values are scaled along their length but not in width and also that 
> arrowheads are not of a constant size. I have addressed both of these 
> problems and getting results much more like Matlab quiver plots now. 
> However, now that I am scaling arrow patches down to very small sizes, 
> I see weird shaped arrows at some zoom levels but when I zoom in close 
> enough to see the shape properly they look nicely formed. Is there a 
> known problem, perhaps with Agg doing some fancy truncation in order 
> to achieve good speed, where patches are distorted if their vertices 
> are very close together at a particular magnification? I can provide 
> code and graphic examples if it would help.

Wow, serendipitously I'm working on exactly the same thing at the 
moment.  Question: when you zoom, do you ensure that the x-direction in 
your window is the same length as the y-direction?  My current theory on 
this is the distorted arrows are the result of quiver measuring 
everything in the x-y space of the plot, instead of in absolute terms.  
Setting axis('equal') or axis('scaled') seems to improve the arrow 
appearance...

Jordan

I've been rewriting the Arrow class in patches.py to improve the look of 
quiver plots and am getting generally good results. The problems with 
current quiver plots are that arrows representing very small values are 
scaled along their length but not in width and also that arrowheads are 
not of a constant size. I have addressed both of these problems and 
getting results much more like Matlab quiver plots now. However, now 
that I am scaling arrow patches down to very small sizes, I see weird 
shaped arrows at some zoom levels but when I zoom in close enough to see 
the shape properly they look nicely formed. Is there a known problem, 
perhaps with Agg doing some fancy truncation in order to achieve good 
speed, where patches are distorted if their vertices are very close 
together at a particular magnification? I can provide code and graphic 
examples if it would help.

Gary R.