Re: [matplotlib-devel] Is this a bug in LineCollection's handling of alpha values?
On Fri, Jun 5, 2009 at 9:56 PM, Fernando Perez wrote:
> Hopefully the code below is illustrative and commented enough to
> clarify my question (also attached if you prefer to download it than
> to copy/paste).
Hey Fernando -- thanks for the report and test case.
I committed a change to svn which fixes this -- I'd like one of the
color gurus (Eric?) to take a look at this because the color handling
code is fairly complex as it handles a lot of different cases. The
problem here was that the ColorConverter.to_rgba_array was applying
the alpha even though the input array was rgba already. I special
case this and do not convert when the input is already an Nx4 array.
Are there any cases I am missing? See the inline comment below:
def to_rgba_array(self, c, alpha=None):
"""
Returns a numpy array of *RGBA* tuples.
Accepts a single mpl color spec or a sequence of specs.
Special case to handle "no color": if *c* is "none" (case-insensitive),
then an empty array will be returned. Same for an empty list.
"""
try:
if c.lower() == 'none':
return np.zeros((0,4), dtype=np.float_)
except AttributeError:
pass
if len(c) == 0:
return np.zeros((0,4), dtype=np.float_)
try:
result = np.array([self.to_rgba(c, alpha)], dtype=np.float_)
except ValueError:
if isinstance(c, np.ndarray):
if c.ndim != 2 and c.dtype.kind not in 'SU':
raise ValueError("Color array must be two-dimensional")
if len(c.shape)==2 and c.shape[-1]==4:
# looks like rgba already, nothing to be done; do
# we want to apply alpha here if
# (c[:,3]==1).all() ?
return c
result = np.zeros((len(c), 4))
for i, cc in enumerate(c):
result[i] = self.to_rgba(cc, alpha) # change in place
return np.asarray(result, np.float_)
JDH
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
2009/4/28 Dave Peterson :
> Darren Dale wrote:
>
> On Tue, Apr 28, 2009 at 12:19 PM, Pierre Raybaut
> wrote:
>>
>> 2009/4/28 John Hunter :
>> >
>> >
>> > On Tue, Apr 28, 2009 at 8:18 AM, Pierre Raybaut
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I would like to contribute to matplotlib with this enhancement for the
>> >> PyQt4 backend: the idea is to add a toolbar button to configure figure
>> >> options (axes, curves, ...).
>> >>
>> >> It's based on a tiny module called formlayout to generate PyQt4 form
>> >> dialog automatically.
>> >>
>> >> Some screenshots:
>> >> http://code.google.com/p/formlayout/
>> >>
>> >> So, if you're interested (all the following is GPL2):
>> >>
>> >> *matplotlib patch*
>> >>
>> >> In FigureManagerQT.__init__, added:
>> >> self.canvas.axes = self.canvas.figure.add_subplot(111)
>> >>
>> >> In NavigationToolbar2QT._init_toolbar, added:
>> >> a = self.addAction(self._icon("customize.png"), 'Customize',
>> >> self.edit_parameters)
>> >> a.setToolTip('Edit curves line and axes parameters')
>> >>
>> >> Added the following method in NavigationToolbar2QT:
>> >> def edit_parameters(self):
>> >> from figureoptions import figure_edit
>> >> figure_edit(self.canvas, self)
>> >>
>> >> *additionnal modules and data*
>> >>
>> >> formlayout.py (http://code.google.com/p/formlayout/)
>> >> figureoptions.py (http://code.google.com/p/PyQtShell/)
>> >> customize.png (http://code.google.com/p/PyQtShell/)
>> >
>> > Hi Pierre -- this looks very nice (the last link is broken though , I
>> > get a
>> > 404 error). We would be happy to include this in matplotlib or as a
>>
>> Here is the last link:
>> http://code.google.com/p/pyqtshell/
>>
>> > toolkit. To contribute it to to mpl, the license needs to be
>> > matplotlib
>> > compatible
>> > (http://matplotlib.sourceforge.net/devel/coding_guide.html#licenses) but
>> > we
>> > have more licensing flexibility in a toolkit, though we prefer to keep
>> > everything BSD compatible where possible. And of course you would need
>> > to
>> > agree to maintain it :-) but I think many users would appreciate a GUI
>> > plot
>> > configuration dialog.
>>
>> I was not aware of this license restriction in matplotlib... I fully
>> understand the motivation, of course, but still: I wrote all this on
>> my free time which means no PyQt4 commercial license, so it can't be
>> anything but GPL. Sorry...
>
> I think you have overlooked a subtlety of PyQt4's license. The author of
> PyQt4 wrote on the enthought-dev mailing list:
>
> "PyQt is GPL but has exceptions that allow it to be used with BSD code -
> hence it's Ok for TraitsBackendQt to be BSD.
>
> However, the exception imposes additional conditions which, to all intents
> and purposes, infects the code with the GPL. To be fair to people that
> should be made clear in any text.
>
> It's still a good idea for TraitsBackendQt to use a BSD license because it
> allows commercial (ie. non-GPL) users to use it without problems."
>
> Darren
>
> I think it might be worth contacting the PyQt folks (Phil Thompson) about
> this. I think there might be some differences here because Phil was the
> author of TraitsBackendQt and thus his efforts didn't quite fall under the
> "develop under a free license, your results needs to be GPL" clause Qt/PyQt
> have in their licensing.
>
> -- Dave
>
>
Hi all,
Dave, you are absolutely right.
Last week-end, I found myself surfing on PyQt's website and I told to
myself: what about re-reading the license? (always a pleasure) And
surprisingly, I found out that anyone using the GPL version of PyQt
can release source code under a very permissive license (like MIT or
BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not
part of the distributed package (otherwise the whole package has to be
licensed under GPL) - and with other little restrictions. It was a
surprise because I've read here and there a lot of things on PyQt
license and the general idea was "if you write PyQt code without the
commercial license, your code *must* be licensed under GPL" - I can
tell now that it's not true (to be absolutely certain about it, I even
asked to Phil Thompson to confirm this, and he did).
So, I switched all the code I was referring to in my original e-mail
to MIT license.
I guess now it could be integrated to matplotlib Qt4 backend?
formlayout (generate option dialogs):
http://code.google.com/p/formlayout/
pydee (IDE which integrates matplotlib and the option dialog):
http://code.google.com/p/pydee/
Meanwhile, thanks to the brand new Google-code Mercurial support, you
may browse the source code if you like:
http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py
Cheers,
Pierre
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
Hi, formlayout will definitely a very nice addition to matplotlib Qt4 backended plotting windows. It reminds me Traits UI's configure.traits() method. PyQt4 programming is still a mystery to me, and have chosen to learn Traits instead. I am also curious to know what happened to pydee - IPython integration plans? I should also mention, I have started a weekly Python meeting in our department. I highly recommended to Windows users to start with Python(X,Y). I will see the results next week :) Gökhan Hi all, > > Dave, you are absolutely right. > > Last week-end, I found myself surfing on PyQt's website and I told to > myself: what about re-reading the license? (always a pleasure) And > surprisingly, I found out that anyone using the GPL version of PyQt > can release source code under a very permissive license (like MIT or > BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not > part of the distributed package (otherwise the whole package has to be > licensed under GPL) - and with other little restrictions. It was a > surprise because I've read here and there a lot of things on PyQt > license and the general idea was "if you write PyQt code without the > commercial license, your code *must* be licensed under GPL" - I can > tell now that it's not true (to be absolutely certain about it, I even > asked to Phil Thompson to confirm this, and he did). > > So, I switched all the code I was referring to in my original e-mail > to MIT license. > I guess now it could be integrated to matplotlib Qt4 backend? > > formlayout (generate option dialogs): > http://code.google.com/p/formlayout/ > > pydee (IDE which integrates matplotlib and the option dialog): > http://code.google.com/p/pydee/ > Meanwhile, thanks to the brand new Google-code Mercurial support, you > may browse the source code if you like: > > http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py > > Cheers, > Pierre > -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Enhancement to matplotlib's PyQt4 backend
Gökhan SEVER a écrit : > Hi, > > formlayout will definitely a very nice addition to matplotlib Qt4 > backended plotting windows. It reminds me Traits UI's > configure.traits() method. > > PyQt4 programming is still a mystery to me, and have chosen to learn > Traits instead. > > I am also curious to know what happened to pydee - IPython integration > plans? I changed its priority but the IPython integration in pydee is still planned for this summer. To be honest, I didn't have the time to work on this for a long time now (actually since the IPython PyQt4 frontend demo I've coded in April). In the meantime, I concentrated on cleaning the code, fixing a lot of bugs, improving performances (Workspace mainly) and adding new features: console in a separate process (the "external console": running scripts, debugging, interacting, opening a Python interpreter... with code-completion, calltips, ...), files/directories explorer, class browser, fast code analysis (pyflakes), find in files (next release)... > > I should also mention, I have started a weekly Python meeting in our > department. I highly recommended to Windows users to start with > Python(X,Y). Of course, I agree that is certainly the best thing to do ;-) Pierre > I will see the results next week :) > > Gökhan > > Hi all, > > Dave, you are absolutely right. > > Last week-end, I found myself surfing on PyQt's website and I told to > myself: what about re-reading the license? (always a pleasure) And > surprisingly, I found out that anyone using the GPL version of PyQt > can release source code under a very permissive license (like MIT or > BSD) thanks to the PyQt-GPL Exception, as long as PyQt itself is not > part of the distributed package (otherwise the whole package has to be > licensed under GPL) - and with other little restrictions. It was a > surprise because I've read here and there a lot of things on PyQt > license and the general idea was "if you write PyQt code without the > commercial license, your code *must* be licensed under GPL" - I can > tell now that it's not true (to be absolutely certain about it, I even > asked to Phil Thompson to confirm this, and he did). > > So, I switched all the code I was referring to in my original e-mail > to MIT license. > I guess now it could be integrated to matplotlib Qt4 backend? > > formlayout (generate option dialogs): > http://code.google.com/p/formlayout/ > > pydee (IDE which integrates matplotlib and the option dialog): > http://code.google.com/p/pydee/ > Meanwhile, thanks to the brand new Google-code Mercurial support, you > may browse the source code if you like: > > http://code.google.com/p/pydee/source/browse/pydeelib/widgets/figureoptions.py > > Cheers, > Pierre > -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Is this a bug in LineCollection's handling of alpha values?
Hey John, On Sat, Jun 6, 2009 at 4:40 AM, John Hunter wrote: > Hey Fernando -- thanks for the report and test case. > > I committed a change to svn which fixes this Awesome, many thanks! This is really great, the Berkeley neuroscience team continues to be impressed by how fast bugs get fixed in the open source python projects (we had a similar one for numpy a few days ago). The comment I just got was: "Wow, people like fixing bugs?" :) Cheers, f -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
