matplotlib-devel Mailing List for matplotlib

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

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

John,

No, I had forgotten about that one--from that message it looks like 
there are two problems in backend_qt4 that are separate from the 
backend_qt4agg problem noted in #506.  I am only trying to deal with the 
latter.

Eric

On Wednesday, October 5, 2011, John Hunter <jd...@gm...> 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

On a separate note, I want to make sure I cut the rc1 correctly.  The notes
said to bump the version number in __unit__.py, but it was already at
v1.1.0.  Was I suppose to bump the version number *from* 1.1.0 in the master
branch, or *to* v1.1.0 in the v1.1.x branch?

Right now, it is 1.1.0 in both branches.

Thanks,
Ben Root

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

On 10/03/2011 02:54 AM, John Hunter wrote:
> We made some additional progress over the weekend closing pull
> requests and issues, and I think we are ready to release tomorrow if
> no one objects.  I want to hold off for a day to give people who do
> most of their work during the week a chance to close/finish/polish any
> lingering issues.

John,

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.

Eric

On 10/05/2011 03:38 AM, Sandro Tosi wrote:
> On Tue, Oct 4, 2011 at 20:00, Michael Droettboom<md...@st...>  wrote:
>> As for your bug, it seems there is a bug in how the plot_formats commandline
>> argument is parsed.  Could you please try this branch and let me know if it
>> resolves the issue?
>>
>> https://github.com/mdboom/matplotlib/tree/doc_build_fail
> Nope, sadly I can still replicate it. Anyhow, I don't know how you
> want to consider this blocking or not, I can live with the map()
> instead of pool.map() as Ben suggested.
I think we should probably take the multiprocessing out -- it's only 
purpose is to increase the speed of the build, but if it fails in some 
circumstances, it's not worth saving a few seconds.  I'd still like to 
address this properly in the future, so I'll file a bug.

Mike

On Tue, Oct 4, 2011 at 20:00, Michael Droettboom <md...@st...> wrote:
> As for your bug, it seems there is a bug in how the plot_formats commandline
> argument is parsed.  Could you please try this branch and let me know if it
> resolves the issue?
>
> https://github.com/mdboom/matplotlib/tree/doc_build_fail

Nope, sadly I can still replicate it. Anyhow, I don't know how you
want to consider this blocking or not, I can live with the map()
instead of pool.map() as Ben suggested.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi