matplotlib-devel Mailing List for matplotlib (Page 3)

On Fri, Oct 7, 2011 at 21:55, Fernando Perez <fpe...@gm...> wrote:
> On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben...@ou...> wrote:
>> That's valid. I guess I am just wondering if there is a decent error
>> message to the user explaining that the test could not proceed.
>
> Rig the test runner to properly skip them instead of failing? The
> test data should be considered a dependency for those tests, and
> absent the dependency, the users simply get less tests, but not a ton
> of failures.
>
> Not saying this should be done *now*,
+1
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Mac binaries for Python 2.6 and 32-bit Python 2.7 are now uploaded.
-- Russell
On Oct 6, 2011, at 8:18 AM, John Hunter wrote:
> On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jd...@gm...> wrote:
> ...
> Actually, if you can just upload the binaries directly to
> 
> https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/
> 
> that will save a step...

Oops. Sorry about that.
1.1.0 built fine under Python 2.7 and passes all tests (except one known skip).
I'll build 2.6 next and then upload both.
-- Russell
On Oct 7, 2011, at 12:11 PM, Benjamin Root wrote:
> This build you are doing is v1.0.1, which is the old version. Did you grab the wrong source, or did we upload the wrong stuff?

On Thu, Oct 6, 2011 at 11:03 AM, Benjamin Root <ben...@ou...> wrote:
> That's valid. I guess I am just wondering if there is a decent error
> message to the user explaining that the test could not proceed.
Rig the test runner to properly skip them instead of failing? The
test data should be considered a dependency for those tests, and
absent the dependency, the users simply get less tests, but not a ton
of failures.
Not saying this should be done *now*, but I think in general having
users be able to run the test suite in their environments is useful,
even if parts are skipped for some reason. You never know when that
will uncover true failures...
That's the approach we take in ipython: we have a lot of tests that
depend on various tools/environment/os, that simply get skipped. In
fact, there is no way to run the *entire* ipython test suite in one
go, since there are mutually exclusive tests (like things that only
run on OSX or Windows). So inevitably, every test run is *always*
partial. Once you think about it that way, then this is just one more
dependency to be handled just like any other.
Cheers,
f

On Fri, Oct 7, 2011 at 1:50 PM, Russell E. Owen <ro...@uw...> wrote:
> I'm running into an error building the Mac binary:
>
> d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$
> bdist_mpkg
> basedirlist is: ['/usr/local']
> =========================================================================
> ===
> BUILDING MATPLOTLIB
> matplotlib: 1.0.1
> python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011,
> 14:13:39)
> [GCC 4.0.1 (Apple Inc. build 5493)]
> platform: darwin
>
> REQUIRED DEPENDENCIES
> numpy: 1.6.1
> freetype2: found, but unknown version (no pkg-config)
>
> OPTIONAL BACKEND DEPENDENCIES
> libpng: found, but unknown version (no pkg-config)
> Traceback (most recent call last):
> File
> "/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line
> 8, in <module>
> load_entry_point('bdist-mpkg==0.4.4', 'console_scripts',
> 'bdist_mpkg')()
> File
> "build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line
> 27, in main
> File "setup.py", line 162, in <module>
> if check_for_tk() or (options['build_tkagg'] is True):
> File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line
> 832, in check_for_tk
> (Tkinter.__version__.split()[-2], Tkinter.TkVersion,
> Tkinter.TclVersion))
> IndexError: list index out of range
>
> I have ActiveState Tk installed. Tkinter reports the following values:
> Tkinter.__version__ = "$Revision$"
> Tkinter.TkVersion = "8.4"
> Tkinter.TclVersion = "8.4"
>
> I assume I can get past this by hacking up setupext.py; I'm willing to
> do that, but I'm wondering if it makes more sense to fix the bug. How
> many other users are going to be bit by this?
>
> 1.0.1rc1 built with no problems, but I see that setupext.py had some
> revisions since then.
>
> -- Russell
>
> P.S. I have no idea why freetype2 and libpng install without pkg-config;
> I install them in in /usr/local in the usual way. However, those
> warnings have been present for a long time and it never seems to cause
> any trouble.
>
>
This build you are doing is v1.0.1, which is the old version. Did you grab
the wrong source, or did we upload the wrong stuff?
Ben Root

I'm running into an error building the Mac binary:
d-69-91-185-129:/Archives/PythonPackages/matplotlib-1.0.1 rowen$ 
bdist_mpkg
basedirlist is: ['/usr/local']
=========================================================================
===
BUILDING MATPLOTLIB
 matplotlib: 1.0.1
 python: 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 
14:13:39)
 [GCC 4.0.1 (Apple Inc. build 5493)]
 platform: darwin
REQUIRED DEPENDENCIES
 numpy: 1.6.1
 freetype2: found, but unknown version (no pkg-config)
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
Traceback (most recent call last):
 File 
"/Library/Frameworks/Python.framework/Versions/2.7/bin/bdist_mpkg", line 
8, in <module>
 load_entry_point('bdist-mpkg==0.4.4', 'console_scripts', 
'bdist_mpkg')()
 File 
"build/bdist.macosx-10.3-fat/egg/bdist_mpkg/script_bdist_mpkg.py", line 
27, in main
 File "setup.py", line 162, in <module>
 if check_for_tk() or (options['build_tkagg'] is True):
 File "/Archives/PythonPackages/matplotlib-1.0.1/setupext.py", line 
832, in check_for_tk
 (Tkinter.__version__.split()[-2], Tkinter.TkVersion, 
Tkinter.TclVersion))
IndexError: list index out of range
I have ActiveState Tk installed. Tkinter reports the following values:
Tkinter.__version__ = "$Revision$"
Tkinter.TkVersion = "8.4"
Tkinter.TclVersion = "8.4"
I assume I can get past this by hacking up setupext.py; I'm willing to 
do that, but I'm wondering if it makes more sense to fix the bug. How 
many other users are going to be bit by this?
1.0.1rc1 built with no problems, but I see that setupext.py had some 
revisions since then.
-- Russell
P.S. I have no idea why freetype2 and libpng install without pkg-config; 
I install them in in /usr/local in the usual way. However, those 
warnings have been present for a long time and it never seems to cause 
any trouble.

On 10/6/2011 10:58 AM, Christoph Gohlke wrote:
>
>
> On 10/6/2011 10:42 AM, Benjamin Root wrote:
>>
>>
>> On Thursday, October 6, 2011, John Hunter<jd...@gm...
>> <mailto:jd...@gm...>> wrote:
>>> On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke<cg...@uc...
>> <mailto:cg...@uc...>> wrote:
>>>
>>>> Is it really intended to include ~36 MB of tests/baseline_images in the
>>>> binary distributions for end users?
>>>
>>> I'm OK with excluding the test images from the binaries. Does anyone
>> disagree?
>>
>> What happens if someone tries to test without having the baseline
>> images? I guess it hasn't been an issue before.
>
> The baseline images were included in previous binary distributions but
> they were much smaller (~10 MB uncompressed). Mpl 1.1 includes ~19.5 MB
> new test_delaunay images.
>
> The mpl 1.1 installers with baseline images are around 30 MB, vs. ~4.2
> MB without.
>
> There's a switch in setup.py:
>
> if 0:
> # TODO: exclude these when making release?
> baseline_images = glob.glob(os.path.join('lib','matplotlib','tests',
> 'baseline_images','*','*'))
>
>>
>>>
>>>> Do you need eggs (not tested; without pytz and dateutil)?
>>>
>>> I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
>>
>> Have we shipped eggs before?
>
> Yes, on request for mpl 1.0.1
> <https://sourceforge.net/mailarchive/message.php?msg_id=25760379>.
>
> Christoph
>
I am ready to upload installers without the baseline images. How about a 
separate installer for matplotlib.tests?
# setup_tests.py
from distutils.core import setup
for line in open('lib/matplotlib/__init__.py').readlines():
 if (line.startswith('__version__')):
 exec(line.strip())
setup(name="matplotlib-tests",
 version=__version__,
 description="Tests for matplotlib",
 author="John D. Hunter",
 author_email="jd...@gm...",
 url="http://matplotlib.sourceforge.net",
 packages = ['matplotlib.tests'],
 package_dir = {'': 'lib'},
 package_data = {'matplotlib.tests':['baseline_images/*/*']},
 platforms='any'
 )

On Thu, Oct 6, 2011 at 12:55 PM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 6, 2011 at 12:42 PM, Benjamin Root <ben...@ou...> wrote:
>
> > What happens if someone tries to test without having the baseline images?
> I
> > guess it hasn't been an issue before.
>
> Tests will fail. But the tests are already pretty dependent on things
> like freetype version so it might be more trouble than it is worth to
> try and support them in a generic user environment.
>
That's valid. I guess I am just wondering if there is a decent error
message to the user explaining that the test could not proceed.
>
> >>> Do you need eggs (not tested; without pytz and dateutil)?
> >>
> >> I'm OK w/ not shipping eggs. Someone will probably ask for them,
> though.
> >
> > Have we shipped eggs before?
>
> Yep,
>
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1
>
> But they have been the source of much pain and annoyance, especially on
> OSX.
>
True. Perhaps having fewer installation options available at the download
page would be better/clearer. Maybe leave egg distribution to pip and
easy_install?
Ben Root

On 10/6/2011 10:42 AM, Benjamin Root wrote:
>
>
> On Thursday, October 6, 2011, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>> On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cg...@uc...
> <mailto:cg...@uc...>> wrote:
>>
>> > Is it really intended to include ~36 MB of tests/baseline_images in the
>> > binary distributions for end users?
>>
>> I'm OK with excluding the test images from the binaries. Does anyone
> disagree?
>
> What happens if someone tries to test without having the baseline
> images? I guess it hasn't been an issue before.
The baseline images were included in previous binary distributions but 
they were much smaller (~10 MB uncompressed). Mpl 1.1 includes ~19.5 MB 
new test_delaunay images.
The mpl 1.1 installers with baseline images are around 30 MB, vs. ~4.2 
MB without.
There's a switch in setup.py:
if 0:
 # TODO: exclude these when making release?
 baseline_images = glob.glob(os.path.join('lib','matplotlib','tests',
 'baseline_images','*','*'))
>
>>
>> > Do you need eggs (not tested; without pytz and dateutil)?
>>
>> I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
>
> Have we shipped eggs before?
Yes, on request for mpl 1.0.1 
<https://sourceforge.net/mailarchive/message.php?msg_id=25760379>.
Christoph

On Thu, Oct 6, 2011 at 12:42 PM, Benjamin Root <ben...@ou...> wrote:
> What happens if someone tries to test without having the baseline images? I
> guess it hasn't been an issue before.
Tests will fail. But the tests are already pretty dependent on things
like freetype version so it might be more trouble than it is worth to
try and support them in a generic user environment.
>>> Do you need eggs (not tested; without pytz and dateutil)?
>>
>> I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
>
> Have we shipped eggs before?
Yep,
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.0.1
But they have been the source of much pain and annoyance, especially on OSX.

On Thursday, October 6, 2011, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cg...@uc...> wrote:
>
>> Is it really intended to include ~36 MB of tests/baseline_images in the
>> binary distributions for end users?
>
> I'm OK with excluding the test images from the binaries. Does anyone
disagree?
What happens if someone tries to test without having the baseline images? I
guess it hasn't been an issue before.
>
>> Do you need eggs (not tested; without pytz and dateutil)?
>
> I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
Have we shipped eggs before?

On Thu, Oct 6, 2011 at 11:43 AM, Christoph Gohlke <cg...@uc...> wrote:
> Is it really intended to include ~36 MB of tests/baseline_images in the
> binary distributions for end users?
I'm OK with excluding the test images from the binaries. Does anyone disagree?
> Do you need eggs (not tested; without pytz and dateutil)?
I'm OK w/ not shipping eggs. Someone will probably ask for them, though.
JDH

On Thu, Oct 6, 2011 at 18:09, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 6, 2011 at 11:04 AM, Sandro Tosi <mo...@de...> wrote:
>> On Thu, Oct 6, 2011 at 16:57, John Hunter <jd...@gm...> wrote:
>>> Great -- they tarballs for the mpl src and sample_data are at
>>>
>>> https://github.com/matplotlib/matplotlib/archives/master
>>
>> I got an access denied for sample_data (I'm logged in as 'sandrotosi'
>> on github) while I can get without problem mpl-1.1.0.tar.gz .
>
>
> Strange, I am seeing that too, even after deleting and re-uploading.
> Can you try from the sf page.
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/
>
> I'm going to delete the file from the github download page.
All fine from SF.
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 10/6/2011 7:57 AM, John Hunter wrote:
> On Thu, Oct 6, 2011 at 9:48 AM, Michael Droettboom<md...@st...> wrote:
>> On 10/06/2011 10:46 AM, John Hunter wrote:
>>>
>>> On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jd...@gm...> wrote:
>>>>
>>>> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<md...@st...>
>>>> wrote:
>>>>
>>>>> Pretty simple. I have a pull request here:
>>>>>
>>>>> https://github.com/matplotlib/matplotlib/pull/509
>>>>
>>>> I confirmed the qt bugs Eric and Michael were working on and tested
>>>> the fixes, so i merged and closed these two. The only remaining issue
>>>> I am aware of is Sandro's map issue, and he said earlier in this
>>>> thread that he can use the map function rather than the pool, so I
>>>> think we are good to go today. Speak now if I am missing something!
>>>
>>> OK, and now I see that Michael removed multi-processing entirely in #507
>>
>> Yeah -- it only really saves around 30seconds anyway. I thought it best to
>> have it work reliably -- we can investigate the cause of Sandro's failure
>> (which I'm not able to reproduce) later -- no need for it to hold up the
>> release.
>
> Great -- they tarballs for the mpl src and sample_data are at
>
> https://github.com/matplotlib/matplotlib/archives/master
>
> if Sandro would like to start with the debian packaging. Russell and
> Christoph, if you could point me to some binary builds I'll upload
> these to the sf site along with the tarballs and do the ANN.
>
> Thanks all,
> JDH
>
>
Is it really intended to include ~36 MB of tests/baseline_images in the 
binary distributions for end users?
Do you need eggs (not tested; without pytz and dateutil)?
Christoph

On Thu, Oct 6, 2011 at 11:04 AM, Sandro Tosi <mo...@de...> wrote:
> On Thu, Oct 6, 2011 at 16:57, John Hunter <jd...@gm...> wrote:
>> Great -- they tarballs for the mpl src and sample_data are at
>>
>> https://github.com/matplotlib/matplotlib/archives/master
>
> I got an access denied for sample_data (I'm logged in as 'sandrotosi'
> on github) while I can get without problem mpl-1.1.0.tar.gz .
Strange, I am seeing that too, even after deleting and re-uploading.
Can you try from the sf page.
https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.0/
I'm going to delete the file from the github download page.
JDH

On Thu, Oct 6, 2011 at 16:57, John Hunter <jd...@gm...> wrote:
> Great -- they tarballs for the mpl src and sample_data are at
>
> https://github.com/matplotlib/matplotlib/archives/master
I got an access denied for sample_data (I'm logged in as 'sandrotosi'
on github) while I can get without problem mpl-1.1.0.tar.gz .
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Thu, Oct 6, 2011 at 9:57 AM, John Hunter <jd...@gm...> wrote:
> Great -- they tarballs for the mpl src and sample_data are at
>
> https://github.com/matplotlib/matplotlib/archives/master
>
> if Sandro would like to start with the debian packaging. Russell and
> Christoph, if you could point me to some binary builds I'll upload
> these to the sf site along with the tarballs and do the ANN.
Actually, if you can just upload the binaries directly to
https://sourceforge.net/projects/matplotlib/upload/matplotlib/matplotlib-1.1.0/
that will save a step. Christoph, if you send me you sf ID I'll make
sure you have upload permissions. Russell, you should already be good
to go.
JDH

On Thu, Oct 6, 2011 at 9:48 AM, Michael Droettboom <md...@st...> wrote:
> On 10/06/2011 10:46 AM, John Hunter wrote:
>>
>> On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jd...@gm...> wrote:
>>>
>>> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<md...@st...>
>>> wrote:
>>>
>>>> Pretty simple. I have a pull request here:
>>>>
>>>> https://github.com/matplotlib/matplotlib/pull/509
>>>
>>> I confirmed the qt bugs Eric and Michael were working on and tested
>>> the fixes, so i merged and closed these two. The only remaining issue
>>> I am aware of is Sandro's map issue, and he said earlier in this
>>> thread that he can use the map function rather than the pool, so I
>>> think we are good to go today. Speak now if I am missing something!
>>
>> OK, and now I see that Michael removed multi-processing entirely in #507
>
> Yeah -- it only really saves around 30seconds anyway. I thought it best to
> have it work reliably -- we can investigate the cause of Sandro's failure
> (which I'm not able to reproduce) later -- no need for it to hold up the
> release.
Great -- they tarballs for the mpl src and sample_data are at
https://github.com/matplotlib/matplotlib/archives/master
if Sandro would like to start with the debian packaging. Russell and
Christoph, if you could point me to some binary builds I'll upload
these to the sf site along with the tarballs and do the ANN.
Thanks all,
JDH

On 10/06/2011 10:46 AM, John Hunter wrote:
> On Thu, Oct 6, 2011 at 9:44 AM, John Hunter<jd...@gm...> wrote:
>> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom<md...@st...> wrote:
>>
>>> Pretty simple. I have a pull request here:
>>>
>>> https://github.com/matplotlib/matplotlib/pull/509
>> I confirmed the qt bugs Eric and Michael were working on and tested
>> the fixes, so i merged and closed these two. The only remaining issue
>> I am aware of is Sandro's map issue, and he said earlier in this
>> thread that he can use the map function rather than the pool, so I
>> think we are good to go today. Speak now if I am missing something!
> OK, and now I see that Michael removed multi-processing entirely in #507
Yeah -- it only really saves around 30seconds anyway. I thought it best 
to have it work reliably -- we can investigate the cause of Sandro's 
failure (which I'm not able to reproduce) later -- no need for it to 
hold up the release.
Mike

On Thu, Oct 6, 2011 at 9:44 AM, John Hunter <jd...@gm...> wrote:
> On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <md...@st...> wrote:
>
>> Pretty simple. I have a pull request here:
>>
>> https://github.com/matplotlib/matplotlib/pull/509
>
> I confirmed the qt bugs Eric and Michael were working on and tested
> the fixes, so i merged and closed these two. The only remaining issue
> I am aware of is Sandro's map issue, and he said earlier in this
> thread that he can use the map function rather than the pool, so I
> think we are good to go today. Speak now if I am missing something!
OK, and now I see that Michael removed multi-processing entirely in #507

On Thu, Oct 6, 2011 at 9:17 AM, Michael Droettboom <md...@st...> wrote:
> Pretty simple. I have a pull request here:
>
> https://github.com/matplotlib/matplotlib/pull/509
I confirmed the qt bugs Eric and Michael were working on and tested
the fixes, so i merged and closed these two. The only remaining issue
I am aware of is Sandro's map issue, and he said earlier in this
thread that he can use the map function rather than the pool, so I
think we are good to go today. Speak now if I am missing something!

On 10/06/2011 09:33 AM, Michael Droettboom wrote:
> On 10/05/2011 05:17 PM, John Hunter wrote:
>> On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote:
>>
>>> Sorry to be holding things up after having nagged about getting a
>>> release out, but I just now marked #506 "release_critical". It looks
>>> like a pretty fundamental bug in blitting on qt4agg, and I think I
>>> introduced it back in January, right after 1.0.1. I can look more
>>> closely this evening; I am hoping it will be fairly simple and safe to fix.
>> Is this the issue Michael identified in this thread above pointing to:
>> "[matplotlib-devel] Typo in backend_qt4.py
>> (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
>> holding on that issue until I heard from him.
> I'm just getting to look at this now -- I'll report back once I have a
> sense of what the issues are.
Pretty simple. I have a pull request here:
https://github.com/matplotlib/matplotlib/pull/509
Mike

On 10/05/2011 05:17 PM, John Hunter wrote:
> On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote:
>
>> Sorry to be holding things up after having nagged about getting a
>> release out, but I just now marked #506 "release_critical". It looks
>> like a pretty fundamental bug in blitting on qt4agg, and I think I
>> introduced it back in January, right after 1.0.1. I can look more
>> closely this evening; I am hoping it will be fairly simple and safe to fix.
> Is this the issue Michael identified in this thread above pointing to:
> "[matplotlib-devel] Typo in backend_qt4.py
> (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
> holding on that issue until I heard from him.
I'm just getting to look at this now -- I'll report back once I have a 
sense of what the issues are.
Mike

On 10/05/2011 11:17 AM, John Hunter wrote:
> On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing<ef...@ha...> wrote:
>
>> Sorry to be holding things up after having nagged about getting a
>> release out, but I just now marked #506 "release_critical". It looks
>> like a pretty fundamental bug in blitting on qt4agg, and I think I
>> introduced it back in January, right after 1.0.1. I can look more
>> closely this evening; I am hoping it will be fairly simple and safe to fix.
>
> Is this the issue Michael identified in this thread above pointing to:
> "[matplotlib-devel] Typo in backend_qt4.py
> (matplotlib-1.1.0-rc1-py2.7-python.org-macosx10.3.dmg)?" I was
> holding on that issue until I heard from him.
>
> JDH
#508 solves #506
The backend_qt4.py problem--the line property editor is broken--remains.
Eric

Dear Lists,
I tried to draw a white block with alpha-channel gradient on top of black.
The result appears to be non-linear, and I think it is problematic.
image = ones((255, 255, 4), dtype='u1')
image[:, :, 0:3] = 255
image[:, :, 3] = arange(0, 255)[:, newaxis]
gca().set_axis_bgcolor('k')
imshow(image)
The color of the pixel with alpha = 128 is about (30, 30, 30).
We can confirm this with
cla()
image[:, :, 3] = 128
imshow(image)
On Inkscape, a white block with alpha = 128 on top of a black box gives a
final color of r,g,b=128, 128, 128.
I did a rough fit and apparently matplotlib is calculating the final pixel
brightness with (notice the original pixel is 0)
r = cr * (alpha / 255.) ** 3 , (same for g and b)
shouldn't it be r = cr * alpha / 255?
This affects matplotlib-1.0.1 and a not so recent copy of the git
master(ba4043a35d4c2).
Regards,
Yu