Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On Tue, Oct 4, 2011 at 20:00, Michael Droettboom 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On 10/05/2011 03:38 AM, Sandro Tosi wrote: > On Tue, Oct 4, 2011 at 20:00, Michael Droettboom 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On Wednesday, October 5, 2011, John Hunter wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On 10/05/2011 11:17 AM, John Hunter wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Alpha channel in imshow, bug or gamma correction?
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
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] propose 1.1.0 release tomorrow
On 10/05/2011 11:17 AM, John Hunter wrote: > On Wed, Oct 5, 2011 at 1:49 PM, Eric Firing 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 -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
