matplotlib-users Mailing List for matplotlib (Page 4)

2011年10月20日 Benjamin Root <ben...@ou...>:
> I have been doing some thinking about this problem and how it could relate
> to issues I have encountered in my work on mplot3d. The key problem I
> encounter there is that shading of the colors needs to be performed based on
> perspective (rotation of the scene and such).
>
> In many ways, this is a similar problem to wanting b&w versions of graphs.
>
> The problem I have had in addressing this is that there are two primary ways
> to specify color in mpl. First, you can specify it directly with strings or
> rgb(a) tuples. Second, you can specify it through a ScalarMappable (eg,
> colormap). This makes for two very different code paths to account for, and
> it can often be difficult to detect which path is needed.
You are facing the OO design of Mpl. I believe they cannot be solved
in mpl, only remedied partially. This is the reason why I don't want
to get entangled with mpl.
> So, what if we unify everything under ScalarMappable? The use case of
> directly specifying the color could be envisioned as the color spec being
> the data applied to an "identity colormap".
No, this would hinder further differentiation. You just gave the
example: Shading. "Uniting", i.e. seeing everything as a
ScalarMappable, would make it impossible without further "unification"
to take two parameters into account: Height + Viewing angle. But the
problem exists, as I said it stems from the Oo approach.
> Then, we extend ScalarMappable such that a chain of transforms could be
> performed on the rgba array. I envision this to be very similar to how the
> projections framework operates. We can then have a set of stock transforms
> that users could select at will (such as color to b&w).
Exactly. But this is a functional approach. Isn't it?
> We can use the lessons and successes of the projections framework to guide
> our design here.
I strongly believe, although I don't know the projections framework,
that is has functional ideas strongly expressed in the way it works.
Is that true?
I just had a walk and tapped in my thoughts into my notebook device
while walking, this is some way of meditation. So here they come (The
postscripta are now-thoughts):
1. There are two different ways of specifying a colour: Either a
thing is simply red or you need something that spits out a colour when
the specification is given. Uniting both under the
spit-out-with-specification constraint hinders further
differentiation. P.S.: In fact, it would be better if the "red" spits
out a colour when called with *nothing*. But hey, this is functional.
2. In fact I believe the Oo approach does not work well for frame
generation (and plotting is a frame generation). This is why I coded
moviemaker using functional paradigm. It just didn't work out the Oo
way - just because you needed a new class for each type of plotting
directive; you have to pass everything through. The functional
approach solved my headaches - Classes are too rigid for plotting.
3. I don't want to "pollute" my mind with the Oo ideas of mpl; rather
I would like to learn to avoid the mistakes made here.
4. Your idea is a functional one.
5. In functional programming, each object (i.e. each function) has
one entry point, in Python this is implemented by the __call__()
method.
-
I can give further details but it doesn't matter here, since we're
talking to give mpl grayscale and filter properties, right. I will
try to dig out my old private ideas I sent you some monthes ago - I
believe I already found the solution for our matter here. (i.e.
avoiding rcParams and stuff.)
I believe the one and only solution would, if thought thru completely,
unveil that we need functional approach to get better results. In
matplotlib, each type of structure is an object of a class, which is
not callable mostly, and this means, you have to formulate each
alteration explicitly. It's not easy in this frame of thinking to get
the flexibility we in fact want - this might be the reason why mpl is
so monolithic with all its different kind of Artist objects ... with
the counterparts in the Renderer objects and so on.
It's hard to keep a common style when differentiating things in
plotting using the Oo approach.
This is just what we see in fact. We feel that things are somehow
united and should work better together and be more exchangable, but
they aren't, because it has never been formulated in terms of code, of
a common base class Function, as I would do it (and did it in
moviemaker). Addendum: It has been attempted with the Artist class,
with the .render() method. I cannot judge how well it worked out, but
to my understanding, it didn't foster plug-in architecture much. ADD:
I think this is because .render() happens on high-level, so it's not
attractive for data-munging objects. The functional approach is
attractive there.
This can be understood as some advertisement for plotlayers, but
believe me, I have coded not a single line of it so far. There exists
moviemaker3, though, and that one works fine. What's missing are
things like polygons and fast drawing routines for scaled pixmaps.
I'll not go into details here.
For me it's hard to stay focussed on mpl here.
I will try to dig out that emails.
Friedrich

Thanks for looking into this deeper.
Agg requires image buffers to be premultiplied, as described in the 
third bullet point here. (It's not exactly clear, to say the least, but 
that's what I take it to mean, and also from reading the code).
http://www.antigrain.com/news/release_notes/v22.agdoc.html
The bug is that in _image.cpp the input buffers are not declared as 
premultiplied in _image.cpp. Arguably it is a bug that agg doesn't 
reject filtering unmultiplied images, since the note states that the 
assumption is that they are premultiplied by the time they get to the 
filters.
I have attached a patch that fixes this. Would you mind testing it and 
let me know how it works for you?
On 10/20/2011 10:29 PM, Daniel Hyams wrote:
> I've looked all over the place through both the Python and C code, and
> I don't see any premultiplication of alphas at any stage before the
> pixels are passed off to agg, and neither can I find any place where
> the alphas are "unmultiplied" on the way back from agg to the backend
> for rendering.
matplotlib's support for alpha blending of images is basically by 
accident, so it's not surprising the details aren't right.
I think it is a bug that after reading images in we don't premultiply 
them before sending them to Agg. That bug has existed for a long time 
in matplotlib because no one is really using alpha images a great deal. 
(Masked images, yes, but that implies alpha is strictly 0 or 255 and 
thus these issues don't come into play.)
Unmultiplying is not always necessary. Many of the GUI backends also 
expect premultiplied alpha (Qt for example). However, there is 
certainly a bug in writing PNG files (where the file format specifies 
unmultiplied).
> It's very possible that I missed it, but I would have to miss it in
> two places (premultiply and the unmultiply). It looks to me like the
> output from agg ends up getting passed on directly to the renderer,
> which as far as I know, just uses straight alpha. The WxAgg renderer,
> for example, just creates a wx.Bitmap out of the pixels and blits it.
> Which means that any image going through agg's filters will not be
> correct if it has any pixels with alpha != 0 or != 255.
>
> [Using PIL images because they are simple to talk about...but the PIL
> image could alternatively be an image.py image]
>
> As far as I can tell, the image pixels current go through a pipeline
> like the following:
>
> [1] PIL Image -> _image image -> agg operations -> modified and/or
> resized _image image -> renderer
>
> If agg expects premultiplied alpha, the procedure should look something like:
>
> [2] PIL Image -> _image image -> premultiply alphas ->agg options ->
> unmultiply alphas -> modified and/or resized _image image -> renderer
>
> I personally don't like pipeline [2] because picture detail is lost in
> the "unmultiply alphas" stage. Better to use straight alpha all the
> way through.
I think what needed is:
[3] PIL Image (or _png.cpp) -> premultiply alphas -> _image image -> agg options ->
-> modified and/or resized _image image -> renderer -> (unmultiply alphas)? -> GUI library
That is -- all image data should be kept premultiplied internally in all 
buffers for efficiency and because this is what Agg is designed for.
Can you explain what you mean by "picture detail is lost in the 
unmultiply alphas stage". There is the usual problem that by 
premultiplying you lose any color data where alpha = 0 (and you lose 
resolution everywhere else, but not resolution you can actually see 
after compositing).
> So long as matplotlib is using only a subset of agg algorithms that
> work no matter whether the alphas are premultiplied or not, I would
> think that the most reasonable route was the one that I took; to
> always pass straight alphas (sticking with pipeline [1]), and modify
> the agg source slightly to fit matplotlib's approach (i.e., remove the
> clipping there).
I'd be really wary of modifying agg like this. Those things become hard 
to maintain. I think this instead a bug in matplotlib and should be 
fixed there.
I've put an issue in the issue tracker here:
https://github.com/matplotlib/matplotlib/issues/545
Cheers,
Mike
> I hope that I'm not way off base (I have a sneaking feeling that I am
> :O ), and hope this helps. I've verified on both Linux and Windows
> that removing the alpha-clip lines from agg_span_image_filter_rgba.h,
> rebuilding matplotlib, and replacing _image.so/_image.pyd and
> _backend_agg.so/_backend_agg.pyd does the trick (along with passing
> straight alphas). So far, I've seen no ill effects on any of my
> plots, but I'm also not in a position to run the pixel-by-pixel
> comparison matplotlib tests.
>
>
> On Wed, Oct 19, 2011 at 7:26 PM, Daniel Hyams<dh...@gm...> wrote:
>> There has to be something else in play here. I'll try to keep this
>> short, but the summary is this: I can get the transparency to look
>> right, but only if 1) I put "straight" alpha in image, not
>> premultiplied, and 2) I hack agg to remove specificially every
>> instance of the lines of code that you refer to above.
>>
>> Why this is, I don't know. Hopefully I'm still misusing something.
>> However, it behaves as if the clipping of alpha in the agg library is
>> corrupting the alpha channel. I also submit that I could have broken
>> some other transparency capabilities of matplotlib, because I don't
>> know what other routines use what I hacked....I did check a few
>> transparent polygons and such though, and everything seemed to be
>> fine.
>>
>> I know that the agg library has been around for quite a long time, so
>> that also means that such a basic bug is unlikely.
>>
>> I've reattached the (slightly modified) script that reproduces the
>> problem, along with a sample image that it uses. The only change to
>> the script is right at the top, where a different image is read, a
>> quick statement is placed to add an alpha channel if there is not
>> already one, and I'm attempting to use premultiplied alphas. I've
>> also attached a screenshot of the output. Notice that in this case,
>> both "transparent" images look wrong.
>>
>> Now, if I 1) hack agg to remove the alpha clipping, and 2) modify the
>> one line in the attached python script so that I use straight alpha,
>> everything looks right. Specifically, I removed every instance of the
>> code below from xxxx, rebuilt all of the matplotlib .so's, and
>> specifically replaced _image.so and _backend_agg.so in my matplotlib
>> distribution.
>>
>> if(fg[order_type::A]> base_mask) fg[order_type::A]
>> = base_mask;
>> if(fg[order_type::R]> fg[order_type::A])
>> fg[order_type::R] = fg[order_type::A];
>> if(fg[order_type::G]> fg[order_type::A])
>> fg[order_type::G] = fg[order_type::A];
>> if(fg[order_type::B]> fg[order_type::A])
>> fg[order_type::B] = fg[order_type::A];
>>
>>
>>
>>
>> On Wed, Oct 19, 2011 at 2:34 PM, Daniel Hyams<dh...@gm...> wrote:
>>> Ah, thanks so much Michael! That explanation helps a great deal; I
>>> was always considering things in "straight alpha" format, not even
>>> knowing that there was alternative.
>>>
>>> I'll play with this tonight; I don't see any problem getting the thing
>>> working, though, now that I know what agg expects to see...
>>>
>>> And yes, alpha support in the image class would be very helpful ;)
>>>
>>> On Wed, Oct 19, 2011 at 2:16 PM, Michael Droettboom<md...@st...> wrote:
>>>> You are right that Agg is doing the resizing here. Agg expects
>>>> premultiplied alpha. See [1] for information about what that means.
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Alpha_compositing
>>>>
>>>> After Agg interpolates the pixel values, to prevent oversaturation it
>>>> truncates all values to be less than alpha (which makes sense if everything
>>>> is assumed to be premultiplied alpha). Arguably, the bug here is that
>>>> nearest neighbor (which doesn't have to do any blending) doesn't perform the
>>>> truncation step -- then both would look "wrong".
>>>>
>>>> It happens in this code snippet in span_image_filter_rgba: (base_mask is
>>>> 255)
>>>>
>>>> if(fg[order_type::A]> base_mask) fg[order_type::A]
>>>> = base_mask;
>>>> if(fg[order_type::R]> fg[order_type::A]) fg[order_type::R]
>>>> = fg[order_type::A];
>>>> if(fg[order_type::G]> fg[order_type::A]) fg[order_type::G]
>>>> = fg[order_type::A];
>>>> if(fg[order_type::B]> fg[order_type::A]) fg[order_type::B]
>>>> = fg[order_type::A];
>>>>
>>>> So, the solution to make a partially transparent image is to not do:
>>>>
>>>> pix[:,:,3] = 127
>>>>
>>>> but instead, do
>>>>
>>>> pix *= 0.5
>>>>
>>>> Of course, the real fix here is to support alpha blending properly in the
>>>> image class, then the user wouldn't have to deal with such details. A bug
>>>> should probably be filed in the matplotlib issue tracker for this.
>>>>
>>>> Mike
>>>>
>>>> On 10/19/2011 12:23 PM, Daniel Hyams wrote:
>>>>
>>>> [Sorry, I keep getting tripped up with HTML mail....resent in ascii,
>>>> and resaved one of the attachment png's to make it smaller.]
>>>>
>>>>
>>>> Example script attached (PIL required). Basically, if I impose a
>>>> specific value into an image's alpha channel and use any interpolation
>>>> scheme other than 'nearest', there appears gray all where the figure
>>>> didn't have any color to begin with. I've also attached a screenshot
>>>> of the output of the script on my machine.
>>>>
>>>> Hopefully I'm doing something wrongly?
>>>>
>>>> I chased the problem and managed to hack in a solution that fixes the
>>>> problem, but it's extremely inefficient...basically, in matplotlib's
>>>> image.py, routine BboxImage.make_image, you can create two images
>>>> there....one with no alpha channel (call it imRGB) and one with (call
>>>> it imRGBA). Go through all of the routine, doing exactly the same
>>>> things to both of the images *except* for the interpolation, which is
>>>> set to 'nearest' for imRGBA. Then, rip the colors out of imRGB, the
>>>> alpha channel off of imRGBA, and put them together....go through all
>>>> of the routine again with this composited image, and it works. I
>>>> know...I told you it was bad ;)
>>>>
>>>> The problem seems to be in the "resize" call in that routine...resize,
>>>> which calls into C code, does not appear to handle things correctly
>>>> when the alpha is anything other than 255's across the board. It
>>>> might be a problem in the agg routines, but hopefully it is just maybe
>>>> a misuse of the agg routines.
>>>>
>>>> The behavior seems to be backend independent as far as I could test (I
>>>> tried with wxagg and tk backends). I am using mpl 1.0.0 on Windows if
>>>> it matters.
>>>>
>>>>
>>>> --
>>>> Daniel Hyams
>>>> dh...@gm...
>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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-d2d-oct
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> The demand for IT networking professionals continues to grow, and the
>>>> demand for specialized networking skills is growing even more rapidly.
>>>> Take a complimentary Learning@Ciosco Self-Assessment and learn
>>>> about Cisco certifications, training, and career opportunities.
>>>> http://p.sf.net/sfu/cisco-dev2dev
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Daniel Hyams
>>> dh...@gm...
>>
>>
>> --
>> Daniel Hyams
>> dh...@gm...
>>
>
>

Dear list,
I am making a 3d plot of a set of functions one after the other.
Actually I do this interactively, but what matter should only be that
I plot, clear the axis, plot again and so on.
I want to display a colorbar for each of those plots. The first thing
I tried was calling
 fig.colorbar(surf, shrink=0.5, aspect=10)
each time. This produced a new colorbar each time I called it. So
thats not working, but thats ok.
My question is now, how do I update the colorbar? I tried several methods:
 #self.cbShape.update_bruteforce(surf)
 self.cbShape.update_normal(surf)
 self.cbShape.changed()
 self.cbShape.update_ticks()
but none of them updated the colorbar. So the plot clearly used colors
from [0, 0.2] but the colorbar always stays at [0, 0.05] (which are
the values from the first time I drew).
How to correctly update the colorbar?
-Holger

Indeed, with that link, I was able to make it work.
Thanks a lot,
Holger
On Thu, Oct 20, 2011 at 11:30, Jean-Louis Durrieu <jea...@du...> wrote:
> Hi Holger,
>
> On Oct 20, 2011, at 11:21 AM, Holger Brandsmeier wrote:
>> I would like to have two subplots in a figure one below each other (so
>> arranged in a 2x1 matrix). I want the upper subplot to have a very
>> small height compared to the lower one, say 10 times smaller than the
>> other one.
>>
>> How can I do that with matplotlib? I didn't find that with subplot()
>> command. I also found the add_subplot() function with many parameters,
>> but I didn't see which of those parameter would help me.
>
> Is this what you need?
> http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#scatter-hist-py-with-axesdivider
>
> Best regards,
>
> Jean-Louis
>
>>
>> Thanks for any advice,
>> Holger
>>
>> --
>> Holger Brandsmeier, SAM, ETH Zürich
>> http://www.sam.math.ethz.ch/people/bholger
>>
>> ------------------------------------------------------------------------------
>> The demand for IT networking professionals continues to grow, and the
>> demand for specialized networking skills is growing even more rapidly.
>> Take a complimentary Learning@Ciosco Self-Assessment and learn
>> about Cisco certifications, training, and career opportunities.
>> http://p.sf.net/sfu/cisco-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
>
-- 
Holger Brandsmeier, SAM, ETH Zürich
http://www.sam.math.ethz.ch/people/bholger

On 10/20/2011 05:17 PM, John Gu wrote:
> Thanks. Is there a place where these sorts of issues can be submitted
> for review / fixes? I'm totally willing to take a look at possible
> solutions if someone points me in the right direction. Thanks.
John,
Development takes place via github, so you can submit issues, clone and 
make pull requests, etc.:
https://github.com/matplotlib/matplotlib
Eric

Thanks. Is there a place where these sorts of issues can be submitted for
review / fixes? I'm totally willing to take a look at possible solutions if
someone points me in the right direction. Thanks.
On Thu, Oct 20, 2011 at 10:52 PM, Eric Firing <ef...@ha...> wrote:
> On 10/20/2011 03:47 PM, John Gu wrote:
> > Hello,
> >
> > I'm using version 1.0.1 of matplotlib on a linux machine. uname -a
> > returns the following: Linux jgulinux 2.6.35.14-95.fc14.x86_64 #1 SMP
> > Tue Aug 16 21:01:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux.
> >
> > [jgu@jgulinux ~/.matplotlib]$ cat matplotlibrc
> > backend : TkAgg
> > interactive : True
> >
> > Program that reproduces the problem (run in ipython):
> >
> > x = arange(1000)
> > y = x
> >
> > f = figure(1)
> > for ia in xrange(5):
> > for ib in xrange(5):
> > ax = subplot(5,5,ia*5+ib+1, navigate=True)
> > ax.plot(x,y)
> >
> > If we now tried to interactively navigate through any single subplot of
> > the figure, it is extremely slow. Not sure if this is a configuration
> > error on my side?
>
> No, and it is not backend-dependent, either. And it does not even
> require that all of the plots have data--it is the same if only the last
> subplot has data. A little experimentation indicates that all the ticks
> and tick labels on the other subplots are slowing down the interaction
> with the one subplot being navigated.
>
> ax.tick_params(labelbottom=False, labelleft=False)
> ax.tick_params(left=False, right=False, top=False, bottom=False)
>
> Insert the above to turn off ticks and tick labels, and it speeds up
> nicely. That's not a solution, I realize.
>
> I knew that slowness in the tick and tick label generation was a major
> bottleneck in subplot creation, but I did not realize that it had such
> an effect on interactive manipulation of a single subplot.
>
> Eric
>
> >
> > John
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Cisco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 10/20/2011 03:47 PM, John Gu wrote:
> Hello,
>
> I'm using version 1.0.1 of matplotlib on a linux machine. uname -a
> returns the following: Linux jgulinux 2.6.35.14-95.fc14.x86_64 #1 SMP
> Tue Aug 16 21:01:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux.
>
> [jgu@jgulinux ~/.matplotlib]$ cat matplotlibrc
> backend : TkAgg
> interactive : True
>
> Program that reproduces the problem (run in ipython):
>
> x = arange(1000)
> y = x
>
> f = figure(1)
> for ia in xrange(5):
> for ib in xrange(5):
> ax = subplot(5,5,ia*5+ib+1, navigate=True)
> ax.plot(x,y)
>
> If we now tried to interactively navigate through any single subplot of
> the figure, it is extremely slow. Not sure if this is a configuration
> error on my side?
No, and it is not backend-dependent, either. And it does not even 
require that all of the plots have data--it is the same if only the last 
subplot has data. A little experimentation indicates that all the ticks 
and tick labels on the other subplots are slowing down the interaction 
with the one subplot being navigated.
 ax.tick_params(labelbottom=False, labelleft=False)
 ax.tick_params(left=False, right=False, top=False, bottom=False)
Insert the above to turn off ticks and tick labels, and it speeds up 
nicely. That's not a solution, I realize.
I knew that slowness in the tick and tick label generation was a major 
bottleneck in subplot creation, but I did not realize that it had such 
an effect on interactive manipulation of a single subplot.
Eric
>
> John

I've looked all over the place through both the Python and C code, and
I don't see any premultiplication of alphas at any stage before the
pixels are passed off to agg, and neither can I find any place where
the alphas are "unmultiplied" on the way back from agg to the backend
for rendering.
It's very possible that I missed it, but I would have to miss it in
two places (premultiply and the unmultiply). It looks to me like the
output from agg ends up getting passed on directly to the renderer,
which as far as I know, just uses straight alpha. The WxAgg renderer,
for example, just creates a wx.Bitmap out of the pixels and blits it.
Which means that any image going through agg's filters will not be
correct if it has any pixels with alpha != 0 or != 255.
[Using PIL images because they are simple to talk about...but the PIL
image could alternatively be an image.py image]
As far as I can tell, the image pixels current go through a pipeline
like the following:
[1] PIL Image -> _image image -> agg operations -> modified and/or
resized _image image -> renderer
If agg expects premultiplied alpha, the procedure should look something like:
[2] PIL Image -> _image image -> premultiply alphas ->agg options ->
unmultiply alphas -> modified and/or resized _image image -> renderer
I personally don't like pipeline [2] because picture detail is lost in
the "unmultiply alphas" stage. Better to use straight alpha all the
way through.
So long as matplotlib is using only a subset of agg algorithms that
work no matter whether the alphas are premultiplied or not, I would
think that the most reasonable route was the one that I took; to
always pass straight alphas (sticking with pipeline [1]), and modify
the agg source slightly to fit matplotlib's approach (i.e., remove the
clipping there).
I hope that I'm not way off base (I have a sneaking feeling that I am
:O ), and hope this helps. I've verified on both Linux and Windows
that removing the alpha-clip lines from agg_span_image_filter_rgba.h,
rebuilding matplotlib, and replacing _image.so/_image.pyd and
_backend_agg.so/_backend_agg.pyd does the trick (along with passing
straight alphas). So far, I've seen no ill effects on any of my
plots, but I'm also not in a position to run the pixel-by-pixel
comparison matplotlib tests.
On Wed, Oct 19, 2011 at 7:26 PM, Daniel Hyams <dh...@gm...> wrote:
> There has to be something else in play here. I'll try to keep this
> short, but the summary is this: I can get the transparency to look
> right, but only if 1) I put "straight" alpha in image, not
> premultiplied, and 2) I hack agg to remove specificially every
> instance of the lines of code that you refer to above.
>
> Why this is, I don't know. Hopefully I'm still misusing something.
> However, it behaves as if the clipping of alpha in the agg library is
> corrupting the alpha channel. I also submit that I could have broken
> some other transparency capabilities of matplotlib, because I don't
> know what other routines use what I hacked....I did check a few
> transparent polygons and such though, and everything seemed to be
> fine.
>
> I know that the agg library has been around for quite a long time, so
> that also means that such a basic bug is unlikely.
>
> I've reattached the (slightly modified) script that reproduces the
> problem, along with a sample image that it uses. The only change to
> the script is right at the top, where a different image is read, a
> quick statement is placed to add an alpha channel if there is not
> already one, and I'm attempting to use premultiplied alphas. I've
> also attached a screenshot of the output. Notice that in this case,
> both "transparent" images look wrong.
>
> Now, if I 1) hack agg to remove the alpha clipping, and 2) modify the
> one line in the attached python script so that I use straight alpha,
> everything looks right. Specifically, I removed every instance of the
> code below from xxxx, rebuilt all of the matplotlib .so's, and
> specifically replaced _image.so and _backend_agg.so in my matplotlib
> distribution.
>
>      if(fg[order_type::A] > base_mask)     fg[order_type::A]
> = base_mask;
>        if(fg[order_type::R] > fg[order_type::A])
> fg[order_type::R] = fg[order_type::A];
>        if(fg[order_type::G] > fg[order_type::A])
> fg[order_type::G] = fg[order_type::A];
>        if(fg[order_type::B] > fg[order_type::A])
> fg[order_type::B] = fg[order_type::A];
>
>
>
>
> On Wed, Oct 19, 2011 at 2:34 PM, Daniel Hyams <dh...@gm...> wrote:
>>
>> Ah, thanks so much Michael! That explanation helps a great deal; I
>> was always considering things in "straight alpha" format, not even
>> knowing that there was alternative.
>>
>> I'll play with this tonight; I don't see any problem getting the thing
>> working, though, now that I know what agg expects to see...
>>
>> And yes, alpha support in the image class would be very helpful ;)
>>
>> On Wed, Oct 19, 2011 at 2:16 PM, Michael Droettboom <md...@st...> wrote:
>> > You are right that Agg is doing the resizing here. Agg expects
>> > premultiplied alpha. See [1] for information about what that means.
>> >
>> > [1] http://en.wikipedia.org/wiki/Alpha_compositing
>> >
>> > After Agg interpolates the pixel values, to prevent oversaturation it
>> > truncates all values to be less than alpha (which makes sense if everything
>> > is assumed to be premultiplied alpha). Arguably, the bug here is that
>> > nearest neighbor (which doesn't have to do any blending) doesn't perform the
>> > truncation step -- then both would look "wrong".
>> >
>> > It happens in this code snippet in span_image_filter_rgba: (base_mask is
>> > 255)
>> >
>> >         if(fg[order_type::A] > base_mask)     fg[order_type::A]
>> > = base_mask;
>> >         if(fg[order_type::R] > fg[order_type::A]) fg[order_type::R]
>> > = fg[order_type::A];
>> >         if(fg[order_type::G] > fg[order_type::A]) fg[order_type::G]
>> > = fg[order_type::A];
>> >         if(fg[order_type::B] > fg[order_type::A]) fg[order_type::B]
>> > = fg[order_type::A];
>> >
>> > So, the solution to make a partially transparent image is to not do:
>> >
>> >   pix[:,:,3] = 127
>> >
>> > but instead, do
>> >
>> >   pix *= 0.5
>> >
>> > Of course, the real fix here is to support alpha blending properly in the
>> > image class, then the user wouldn't have to deal with such details. A bug
>> > should probably be filed in the matplotlib issue tracker for this.
>> >
>> > Mike
>> >
>> > On 10/19/2011 12:23 PM, Daniel Hyams wrote:
>> >
>> > [Sorry, I keep getting tripped up with HTML mail....resent in ascii,
>> > and resaved one of the attachment png's to make it smaller.]
>> >
>> >
>> > Example script attached (PIL required). Basically, if I impose a
>> > specific value into an image's alpha channel and use any interpolation
>> > scheme other than 'nearest', there appears gray all where the figure
>> > didn't have any color to begin with.  I've also attached a screenshot
>> > of the output of the script on my machine.
>> >
>> > Hopefully I'm doing something wrongly?
>> >
>> > I chased the problem and managed to hack in a solution that fixes the
>> > problem, but it's extremely inefficient...basically, in matplotlib's
>> > image.py, routine BboxImage.make_image, you can create two images
>> > there....one with no alpha channel (call it imRGB) and one with (call
>> > it imRGBA). Go through all of the routine, doing exactly the same
>> > things to both of the images *except* for the interpolation, which is
>> > set to 'nearest' for imRGBA. Then, rip the colors out of imRGB, the
>> > alpha channel off of imRGBA, and put them together....go through all
>> > of the routine again with this composited image, and it works. I
>> > know...I told you it was bad ;)
>> >
>> > The problem seems to be in the "resize" call in that routine...resize,
>> > which calls into C code, does not appear to handle things correctly
>> > when the alpha is anything other than 255's across the board. It
>> > might be a problem in the agg routines, but hopefully it is just maybe
>> > a misuse of the agg routines.
>> >
>> > The behavior seems to be backend independent as far as I could test (I
>> > tried with wxagg and tk backends). I am using mpl 1.0.0 on Windows if
>> > it matters.
>> >
>> >
>> > --
>> > Daniel Hyams
>> > dh...@gm...
>> >
>> > ------------------------------------------------------------------------------
>> > 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-d2d-oct
>> >
>> > _______________________________________________
>> > Matplotlib-users mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > The demand for IT networking professionals continues to grow, and the
>> > demand for specialized networking skills is growing even more rapidly.
>> > Take a complimentary Learning@Ciosco Self-Assessment and learn
>> > about Cisco certifications, training, and career opportunities.
>> > http://p.sf.net/sfu/cisco-dev2dev
>> > _______________________________________________
>> > Matplotlib-users mailing list
>> > Mat...@li...
>> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> >
>> >
>>
>>
>>
>> --
>> Daniel Hyams
>> dh...@gm...
>
>
>
> --
> Daniel Hyams
> dh...@gm...
>
-- 
Daniel Hyams
dh...@gm...

Hello,
I'm using version 1.0.1 of matplotlib on a linux machine. uname -a returns
the following: Linux jgulinux 2.6.35.14-95.fc14.x86_64 #1 SMP Tue Aug 16
21:01:58 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux.
[jgu@jgulinux ~/.matplotlib]$ cat matplotlibrc
backend : TkAgg
interactive : True
Program that reproduces the problem (run in ipython):
x = arange(1000)
y = x
f = figure(1)
for ia in xrange(5):
 for ib in xrange(5):
 ax = subplot(5,5,ia*5+ib+1, navigate=True)
 ax.plot(x,y)
If we now tried to interactively navigate through any single subplot of the
figure, it is extremely slow. Not sure if this is a configuration error on
my side?
John

On Thursday, October 20, 2011, Friedrich Romstedt <
fri...@gm...> wrote:
> 2011年10月20日 Eric Firing <ef...@ha...>:
>> Friedrich (or others),
>>
>> I hope you will consider the following to be constructive.
>
> I agree :-/ It was very very late in the night [5:30 a.m.], so things
> happen, but I think that's no kind of excuse for my rude tone in that
> email. I'm sorry.
>
>> I understand one use case for a gray switch: sometimes one needs to make
>> gray versions of plots for formal publication, but one wants to have
>> nicer color versions for other purposes.
>
> Exactly, but I believe when we have the functionality the use cases
> will just start to emerge - like it always is.
>
> For instance, but this is just guessing, someone came up with the will
> to write out his figure in CMYK. Others might want to turn black into
> white and vice versa, keeping other colours invariant.
>
>> What is the use case for grayscale support for parts of the Figure? It
>> seems to me that this requires a much more complex and extensive set of
>> changes than a switch for the whole Figure. Is it really worth it?
>
> I think yes.
>
> It is a bit of effort, yes.
>
>> You indicate that some caching will need to be eliminated. Is this
>> correct? If your branch causes a significant loss of speed in
>> displaying and interacting with large data sets, then I will oppose
>> merging it. Speed matters for a significant fraction of mpl usage.
>
> Correct. I think it is measurable, but only of O(2). I believe this
> kind of fluctuation can be called noise :-)
>
> The tests cannot esily resolve this because they do everything once.
>
> And with a bit of work I might be able to keep the caching.
>
>> Improvements in mpl architecture that maintain or increase speed, and
>> that make it more comprehensible, maintainable, and capable, are
>> certainly welcome. Color handling has grown organically, often
>> bedeviled by that pesky alpha, and I have no doubt that it could be
>> cleaned up and improved.
>
> I can capably only speak of colors.py and some conversion functions
> somewhere else. I've noticed a rather small-grained approach. I
> tried to unify things.
>
> But this you already said.
>
> cu,
> Friedrich
>
Friedrich,
Great to hear from you again!
I have been doing some thinking about this problem and how it could relate
to issues I have encountered in my work on mplot3d. The key problem I
encounter there is that shading of the colors needs to be performed based on
perspective (rotation of the scene and such).
In many ways, this is a similar problem to wanting b&w versions of graphs.
The problem I have had in addressing this is that there are two primary ways
to specify color in mpl. First, you can specify it directly with strings or
rgb(a) tuples. Second, you can specify it through a ScalarMappable (eg,
colormap). This makes for two very different code paths to account for, and
it can often be difficult to detect which path is needed.
So, what if we unify everything under ScalarMappable? The use case of
directly specifying the color could be envisioned as the color spec being
the data applied to an "identity colormap".
Then, we extend ScalarMappable such that a chain of transforms could be
performed on the rgba array. I envision this to be very similar to how the
projections framework operates. We can then have a set of stock transforms
that users could select at will (such as color to b&w).
We can use the lessons and successes of the projections framework to guide
our design here.
Thoughts?
Ben Root

Holger Brandsmeier <holger.brandsmeier@...> writes:
> 
> Dear list,
> 
> I would like to have two subplots in a figure one below each other (so
> arranged in a 2x1 matrix). I want the upper subplot to have a very
> small height compared to the lower one, say 10 times smaller than the
> other one.
> 
> How can I do that with matplotlib? I didn't find that with subplot()
> command. I also found the add_subplot() function with many parameters,
> but I didn't see which of those parameter would help me.
> 
> Thanks for any advice,
> Holger
> 
Have a look at http://matplotlib.sourceforge.net/users/gridspec.html
greetings
Till

Hi all,
I've encountered the following problem when trying to use a logarithmic color scale:
The code
import numpy as np
import matplotlib.pyplot as plt
from matplotlib import ticker
x = np.arange(-100,105,5)
X,Y = np.meshgrid(x,x)
Z = X**2 + Y**2 + 0.1
plt.contourf(X,Y,Z.T, locator=ticker.LogLocator())
plt.colorbar()
works fine to create a contour map with logarithmic colorscale. Now I want to refine the scaling by adding more colorlevels. Therefore I add another option for the contourf() function, as follows:
plt.contourf(X,Y,Z.T, np.logspace(-1,5,15), locator=ticker.LogLocator())
However when I do this, all but one tick of the colorbar just vanish. What is the reason for this and how can I fix that?
Kind regards,
Marko

On 2011年10月19日 15:45:07 -0500
 Benjamin Root <ben...@ou...> wrote:
> On Fri, Oct 14, 2011 at 3:42 AM, Nils Wagner
> <nw...@ia...>wrote:
> 
>> Hi all,
>>
>> what is the native "data" coordinate system for Arrows 
>>in
>> a polar plot ?
>>
>> How do I add arrows to a polar plot ?
>>
>> An example would be appreciated.
>> fig = figure(figsize=(12,12))
>> ax = fig.add_subplot(111, polar=True)
>>
>> Nils
>>
>>
> I don't know if it is an existing feature or not. If it 
>isn't, then I think
> a feature request should be filed. If it is, then a 
>request should be filed
> anyway for an example to be added to the gallery.
> 
> Ben Root
Hi Ben,
it seems to work in general, but how can I increase the 
size of the arrowhead ?
from pylab import figure, arrow, show
import numpy as np
fig = figure(figsize=(15,15))
ax = fig.add_subplot(111, polar=True)
ax.arrow(0.0,0.0,np.pi/4,0.3,lw=2)
ax.arrow(0.0,0.0,np.pi/2,0.4)
show()
Nils

Hi Holger,
On Oct 20, 2011, at 11:21 AM, Holger Brandsmeier wrote:
> I would like to have two subplots in a figure one below each other (so
> arranged in a 2x1 matrix). I want the upper subplot to have a very
> small height compared to the lower one, say 10 times smaller than the
> other one.
> 
> How can I do that with matplotlib? I didn't find that with subplot()
> command. I also found the add_subplot() function with many parameters,
> but I didn't see which of those parameter would help me.
Is this what you need? 
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#scatter-hist-py-with-axesdivider
Best regards,
Jean-Louis
> 
> Thanks for any advice,
> Holger
> 
> -- 
> Holger Brandsmeier, SAM, ETH Zürich
> http://www.sam.math.ethz.ch/people/bholger
> 
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn 
> about Cisco certifications, training, and career opportunities. 
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 

On 2011年10月19日 15:45:07 -0500
 Benjamin Root <ben...@ou...> wrote:
> On Fri, Oct 14, 2011 at 3:42 AM, Nils Wagner
> <nw...@ia...>wrote:
> 
>> Hi all,
>>
>> what is the native "data" coordinate system for Arrows 
>>in
>> a polar plot ?
>>
>> How do I add arrows to a polar plot ?
>>
>> An example would be appreciated.
>> fig = figure(figsize=(12,12))
>> ax = fig.add_subplot(111, polar=True)
>>
>> Nils
>>
>>
> I don't know if it is an existing feature or not. If it 
>isn't, then I think
> a feature request should be filed. If it is, then a 
>request should be filed
> anyway for an example to be added to the gallery.
> 
> Ben Root
Done. See 
https://github.com/matplotlib/matplotlib/issues/542
Nils

Dear list,
I would like to have two subplots in a figure one below each other (so
arranged in a 2x1 matrix). I want the upper subplot to have a very
small height compared to the lower one, say 10 times smaller than the
other one.
How can I do that with matplotlib? I didn't find that with subplot()
command. I also found the add_subplot() function with many parameters,
but I didn't see which of those parameter would help me.
Thanks for any advice,
Holger
-- 
Holger Brandsmeier, SAM, ETH Zürich
http://www.sam.math.ethz.ch/people/bholger

2011年10月20日 Eric Firing <ef...@ha...>:
> Friedrich (or others),
>
> I hope you will consider the following to be constructive.
I agree :-/ It was very very late in the night [5:30 a.m.], so things
happen, but I think that's no kind of excuse for my rude tone in that
email. I'm sorry.
> I understand one use case for a gray switch: sometimes one needs to make
> gray versions of plots for formal publication, but one wants to have
> nicer color versions for other purposes.
Exactly, but I believe when we have the functionality the use cases
will just start to emerge - like it always is.
For instance, but this is just guessing, someone came up with the will
to write out his figure in CMYK. Others might want to turn black into
white and vice versa, keeping other colours invariant.
> What is the use case for grayscale support for parts of the Figure? It
> seems to me that this requires a much more complex and extensive set of
> changes than a switch for the whole Figure. Is it really worth it?
I think yes.
It is a bit of effort, yes.
> You indicate that some caching will need to be eliminated. Is this
> correct? If your branch causes a significant loss of speed in
> displaying and interacting with large data sets, then I will oppose
> merging it. Speed matters for a significant fraction of mpl usage.
Correct. I think it is measurable, but only of O(2). I believe this
kind of fluctuation can be called noise :-)
The tests cannot esily resolve this because they do everything once.
And with a bit of work I might be able to keep the caching.
> Improvements in mpl architecture that maintain or increase speed, and
> that make it more comprehensible, maintainable, and capable, are
> certainly welcome. Color handling has grown organically, often
> bedeviled by that pesky alpha, and I have no doubt that it could be
> cleaned up and improved.
I can capably only speak of colors.py and some conversion functions
somewhere else. I've noticed a rather small-grained approach. I
tried to unify things.
But this you already said.
cu,
Friedrich

On 10/19/2011 05:15 PM, Friedrich Romstedt wrote:
> Hi,
>
> I appreciate all the effort and, lastly, the large functionality
> offered by matplotlib. But I found no way around formulating things a
> bit provocative on
> http://friedrichromstedt.github.com/matplotlib-grayscale/index.html.
>
> The project is about matplotlib-grayscale, a matplotlib patch that
> aims at grayscale toggle-switch behaviour as well as colour filtering
> / conversion.
>
> The project has a proof of concept (see under the URL above), but I
> disregard this since it has major design flaws, although *it works*.
> But as most things in matplotlib, *which work*, I would rather prefer
> a well thought-through solution. No offense, it's just the way it
> goes with matplotlib. I have some examples in the roadmap.
>
> I'm telling upfront that I don't want to get engaged with mpl, I just
> want to get this my project getting an ex-project. So I want to do it
> quickly and properly, let it go to the main repository, and forget
> about it except bug-fixes, the usual maintenance.
>
> Time frame, is, including good testing, say 3 monthes. I want to get
> it started quickly and just want to let you all let know about this
> project. I'll do it irrespective of if there's clubbing, it's up to
> the maintainers to accept or reject it in the end.
>
> I'm asking for ideas about the general design, which do not go too far
> with mpl, but use the existing framework to its best. I've put some
> of my ideas on the web page noted above.
>
> I did not dive into it again yet after the few monthes of letting it
> put aside. I just dug out my old commit messages and have put them
> together on the web page together with the superficial things I
> remembered. But I think the detail knowledge can be recovered easily.
>
> Only constructive feedback please.
>
> Especially a documenter/tester with a fresh eye on the things I know
> now would be great. Same applies for testing. The testing done for
> the pre-github proof-of-concept by Benjamin Root must be noted here,
> it made flaws and side-tracks apparent I either didn't know about or
> did overlook. Documenting and testing of the technical things is up
> to me, only the interface documentation and testing boredom.
>
> Last time I kept the project secret, I'm not gonna do commit that mistake again.
>
> Without matplotlib, lastly, also this patch would simply not exist,
> neither in my mind nor in reality.
>
> cu,
> Friedrich
>
> P.S.: I keep the right of dropping the project at any time. I'll do
> my diploma next monthes, so time might be short. But I think it might
> serve its purpose.
>
Friedrich (or others),
I hope you will consider the following to be constructive.
I understand one use case for a gray switch: sometimes one needs to make 
gray versions of plots for formal publication, but one wants to have 
nicer color versions for other purposes.
What is the use case for grayscale support for parts of the Figure? It 
seems to me that this requires a much more complex and extensive set of 
changes than a switch for the whole Figure. Is it really worth it?
You indicate that some caching will need to be eliminated. Is this 
correct? If your branch causes a significant loss of speed in 
displaying and interacting with large data sets, then I will oppose 
merging it. Speed matters for a significant fraction of mpl usage.
Improvements in mpl architecture that maintain or increase speed, and 
that make it more comprehensible, maintainable, and capable, are 
certainly welcome. Color handling has grown organically, often 
bedeviled by that pesky alpha, and I have no doubt that it could be 
cleaned up and improved.
Eric

JJ,
The workaround works. Thanks.
-Sterling
On Oct 17, 2011, at 6:58PM, Jae-Joon Lee wrote:
> Meanwhile, you may do
> 
> from matplotlib.legend import Legend
> l = Legend(fig, h, l, loc='lower right')
> fig.legends.append(l)
> 
> This should be equivalent to fig.legend(h,l,loc='lower right').
> 
> Or, if you don't need axes legend, you may do
> 
> legend(h,l,loc='lower right', bbox_to_anchor=[0,0,1,1],
> bbox_transform=fig.transFigure)
> 
> Regards,
> 
> -JJ
> 
> On Tue, Oct 18, 2011 at 6:59 AM, Sterling Smith <sm...@fu...> wrote:
>> Let me first say that I appreciate the work that the developers have put into matplotlib. You're doing a great job.
>> 
>> I have filed a bug report at
>> 
>> https://github.com/matplotlib/matplotlib/issues/533
>> 
>> wherein I post the following
>> 
>> Consider:
>> 
>> from pylab import *
>> x = arange(0,1,.01)
>> y = x**2
>> fig = figure(2)
>> ax = fig.add_subplot(111)
>> errorbar(x,y,yerr=x/10.,label='$x^2$')
>> errorbar(x,y**3,yerr=x/10.,label='$x^6$')
>> legend(loc='upper center')
>> h,l = ax.get_legend_handles_labels()
>> fig.legend(h,l,loc='lower right')
>> 
>> 
>> I am getting the right legend for the axes based legend, but the figure based legend seems to be using the different parts of the errorbar for subsequent handles, instead of using them as a group. From what I can tell, this has appeared since the upgrade to version 1.1.0.
>> 
>> I am running on Linux, python 2.7, gtkAgg backend.
>> 
>> Thanks,
>> Sterling
>> 
>> 
>> ------------------------------------------------------------------------------
>> 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-d2d-oct
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 

Hi,
I appreciate all the effort and, lastly, the large functionality
offered by matplotlib. But I found no way around formulating things a
bit provocative on
http://friedrichromstedt.github.com/matplotlib-grayscale/index.html.
The project is about matplotlib-grayscale, a matplotlib patch that
aims at grayscale toggle-switch behaviour as well as colour filtering
/ conversion.
The project has a proof of concept (see under the URL above), but I
disregard this since it has major design flaws, although *it works*.
But as most things in matplotlib, *which work*, I would rather prefer
a well thought-through solution. No offense, it's just the way it
goes with matplotlib. I have some examples in the roadmap.
I'm telling upfront that I don't want to get engaged with mpl, I just
want to get this my project getting an ex-project. So I want to do it
quickly and properly, let it go to the main repository, and forget
about it except bug-fixes, the usual maintenance.
Time frame, is, including good testing, say 3 monthes. I want to get
it started quickly and just want to let you all let know about this
project. I'll do it irrespective of if there's clubbing, it's up to
the maintainers to accept or reject it in the end.
I'm asking for ideas about the general design, which do not go too far
with mpl, but use the existing framework to its best. I've put some
of my ideas on the web page noted above.
I did not dive into it again yet after the few monthes of letting it
put aside. I just dug out my old commit messages and have put them
together on the web page together with the superficial things I
remembered. But I think the detail knowledge can be recovered easily.
Only constructive feedback please.
Especially a documenter/tester with a fresh eye on the things I know
now would be great. Same applies for testing. The testing done for
the pre-github proof-of-concept by Benjamin Root must be noted here,
it made flaws and side-tracks apparent I either didn't know about or
did overlook. Documenting and testing of the technical things is up
to me, only the interface documentation and testing boredom.
Last time I kept the project secret, I'm not gonna do commit that mistake again.
Without matplotlib, lastly, also this patch would simply not exist,
neither in my mind nor in reality.
cu,
Friedrich
P.S.: I keep the right of dropping the project at any time. I'll do
my diploma next monthes, so time might be short. But I think it might
serve its purpose.
-- 
I want to be honest and open to you from the beginning who I am and
what I'm doing. So here's a small collection of informative links:
http://github.com/friedrichromstedt/ (github code sharing);
http://friedrichr.blogspot.com/2011/10/home-dashboard.html
(All-Purpose Blog); http://picasaweb.google.com/friedrichromstedt/
(photos which are public); http://vimeo.com/friedrichr/ (videos which
are public). There's a legacy web page
http://www.friedrichromstedt.org/ which is to be replaced. There's a
legacy YouTube channel http://www.youtube.com/user/friedrichromstedt/
which is unmaintained. And there's a news feed on Twitter:
@f_romstedt.

On 10/19/11 4:37 PM, questions anon wrote:
> thank you, I am not quite sure how to 'draw' the shapefile
 from matplotlib.collections import LineCollection
 ax = plt.gca() # get current axes instance
# 'DSE_REGIONS' instance variable created by readshapefile method call.
 lines = LineCollection(map.DSE_REGIONS)
 ax.add_collection(lines)
-Jeff
> but making those changes and removing the shapefile has sped the 
> processing up considerably!
> Thank you for your help
>
> On Wed, Oct 19, 2011 at 11:42 PM, Jeff Whitaker <js...@fa... 
> <mailto:js...@fa...>> wrote:
>
> On 10/18/11 8:55 PM, questions anon wrote:
>> Thanks Jeff, that certainly speeds it up! But when I take them
>> out of the loop and place them elsewhere they are no longer added
>> to the map.
>> Is there someway I can call them in the loop but still get it to
>> run quickly?
>> Thanks
>
> Just the Basemap instance creation and the transformation of
> coordinates to projection space should be hoisted out of the loop
>
>
> map =
> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
> 
> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
> x,y=map(*N.meshgrid(LON,LAT))
>
> you can leave the other statements in.
>
> If you still have memory issues, bring the readshapefile call out,
> and draw the shapes whose coordinates are stored in the instance
> variable map.DSE_REGIONS manually in the loop.
>
> -Jeff
>
>>
>> On Fri, Oct 14, 2011 at 10:54 PM, Jeff Whitaker
>> <js...@fa... <mailto:js...@fa...>> wrote:
>>
>> On 10/12/11 8:20 PM, questions anon wrote:
>>> Hi All,
>>> I keep receiving a memory error when processing many netcdf
>>> files. I assumed it had something to do with how I loop
>>> things and maybe needed to close things off properly but I
>>> recently received an error that made me think it might be
>>> because of matplotlib.
>>>
>>> In the code below I am looping through a bunch of netcdf
>>> files (each file is hourly data for one month) and within
>>> each netcdf file I am outputting a *png file every three
>>> hours. This works for one netcdf file (therefore one month)
>>> but when it begins to process the next netcdf file I receive
>>> a memory error (see below). Since I have tidied some of my
>>> code up it seems to process partly into the second file but
>>> then I still receive the memory error.
>>> I have tried a few suggestions such as:
>>> -Combining the dataset using MFDataset (using NETCDF4) is
>>> not an option because the files do not have unlimited
>>> dimension.
>>> - gc.collect() but that just results in a /GEOS_ERROR: bad
>>> allocation error/.
>>> -only open LAT and LON once (which worked)
>>>
>>> System Details:
>>> Python 2.7.2 |EPD 7.1-2 (32-bit)| (default, Jul 3 2011,
>>> 15:13:59) [MSC v.1500 32 bit (Intel)] on win32
>>>
>>> Any feedback will be greatly appreciated as I seem to keep
>>> ending up with memory errors when working with netcdf files
>>> this even happens if I am using a much better computer.
>>>
>>> *Most recent error: *
>>> Traceback (most recent call last):
>>> File
>>> "C:\plot_netcdf_merc_multiplot_across_multifolders_TSFC.py",
>>> line 78, in <module>
>>> plt.savefig((os.path.join(outputfolder,
>>> 'TSFC'+date_string+'UTC.png')))
>>> File "C:\Python27\lib\site-packages\matplotlib\pyplot.py",
>>> line 363, in savefig
>>> return fig.savefig(*args, **kwargs)
>>> File "C:\Python27\lib\site-packages\matplotlib\figure.py",
>>> line 1084, in savefig
>>> self.canvas.print_figure(*args, **kwargs)
>>> File
>>> "C:\Python27\lib\site-packages\matplotlib\backends\backend_wxagg.py",
>>> line 100, in print_figure
>>> FigureCanvasAgg.print_figure(self, filename, *args,
>>> **kwargs)
>>> File
>>> "C:\Python27\lib\site-packages\matplotlib\backend_bases.py",
>>> line 1923, in print_figure
>>> **kwargs)
>>> File
>>> "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>>> line 438, in print_png
>>> FigureCanvasAgg.draw(self)
>>> File
>>> "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>>> line 393, in draw
>>> self.renderer = self.get_renderer()
>>> File
>>> "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>>> line 404, in get_renderer
>>> self.renderer = RendererAgg(w, h, self.figure.dpi)
>>> File
>>> "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
>>> line 59, in __init__
>>> self._renderer = _RendererAgg(int(width), int(height),
>>> dpi, debug=False)
>>> RuntimeError: Could not allocate memory for image
>>>
>>> *Error when I added gc.collect()*
>>> GEOS_ERROR: bad allocation
>>>
>>> *Old error (before adding gc.collect() )*
>>> /Traceback (most recent call last):
>>> File
>>> "d:/plot_netcdf_merc_multiplot_across_multifolders__memoryerror.py",
>>> line 44, in <module>
>>> TSFC=ncfile.variables['T_SFC'][1::3]
>>> File "netCDF4.pyx", line 2473, in
>>> netCDF4.Variable.__getitem__ (netCDF4.c:23094)
>>> MemoryError/
>>>
>>>
>>>
>>> from netCDF4 import Dataset
>>> import numpy as N
>>> import matplotlib.pyplot as plt
>>> from mpl_toolkits.basemap import Basemap
>>> from netcdftime import utime
>>> from datetime import datetime
>>> import os
>>> import gc
>>>
>>>
>>> shapefile1="E:/
>>>
>>> griddeddatasamples/GIS/DSE_REGIONS"
>>> MainFolder=r"E:/griddeddatasamples/GriddedData/InputsforValidation/T_SFC/"
>>> OutputFolder=r"E:/griddeddatasamples/GriddedData/OutputsforValidation"
>>> fileforlatlon=Dataset("E:/griddeddatasamples/GriddedData/InputsforValidation/T_SFC/TSFC_1974_01/IDZ00026_VIC_ADFD_T_SFC.nc",
>>> 'r+', 'NETCDF4')
>>> LAT=fileforlatlon.variables['latitude'][:]
>>> LON=fileforlatlon.variables['longitude'][:]
>>>
>>> for (path, dirs, files) in os.walk(MainFolder):
>>> for dir in dirs:
>>> print dir
>>> path=path+'/'
>>> for ncfile in files:
>>> if ncfile[-3:]=='.nc':
>>> print "dealing with ncfiles:", ncfile
>>> ncfile=os.path.join(path,ncfile)
>>> ncfile=Dataset(ncfile, 'r+', 'NETCDF4')
>>> TSFC=ncfile.variables['T_SFC'][1::3]
>>> TIME=ncfile.variables['time'][1::3]
>>> ncfile.close()
>>> gc.collect()
>>>
>>> for TSFC, TIME in zip((TSFC[:]),(TIME[:])):
>>> cdftime=utime('seconds since 1970年01月01日
>>> 00:00:00')
>>> ncfiletime=cdftime.num2date(TIME)
>>> print ncfiletime
>>> timestr=str(ncfiletime)
>>> d = datetime.strptime(timestr, '%Y-%m-%d
>>> %H:%M:%S')
>>> date_string = d.strftime('%Y%m%d_%H%M')
>>>
>>> map =
>>> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>>> 
>>> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
>>> x,y=map(*N.meshgrid(LON,LAT))
>>> map.drawcoastlines(linewidth=0.5)
>>> map.readshapefile(shapefile1, 'DSE_REGIONS')
>>> map.drawstates()
>>>
>>> plt.title('Surface temperature at %s
>>> UTC'%ncfiletime)
>>> ticks=[-5,0,5,10,15,20,25,30,35,40,45,50]
>>> CS = map.contourf(x,y,TSFC, ticks,
>>> cmap=plt.cm.jet)
>>> l,b,w,h =0.1,0.1,0.8,0.8
>>> cax = plt.axes([l+w+0.025, b, 0.025, h], )
>>> cbar=plt.colorbar(CS, cax=cax,
>>> drawedges=True)
>>>
>>> plt.savefig((os.path.join(OutputFolder,
>>> 'TSFC'+date_string+'UTC.png')))
>>> plt.close()
>>> gc.collect()
>>>
>>
>> Try moving these lines
>>
>>
>> map =
>> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>> 
>> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
>> x,y=map(*N.meshgrid(LON,LAT))
>> map.drawcoastlines(linewidth=0.5)
>> map.readshapefile(shapefile1, 'DSE_REGIONS')
>> map.drawstates()
>>
>> out of the loop.
>>
>> -Jeff
>>
>>
>
>

There has to be something else in play here. I'll try to keep this
short, but the summary is this: I can get the transparency to look
right, but only if 1) I put "straight" alpha in image, not
premultiplied, and 2) I hack agg to remove specificially every
instance of the lines of code that you refer to above.
Why this is, I don't know. Hopefully I'm still misusing something.
However, it behaves as if the clipping of alpha in the agg library is
corrupting the alpha channel. I also submit that I could have broken
some other transparency capabilities of matplotlib, because I don't
know what other routines use what I hacked....I did check a few
transparent polygons and such though, and everything seemed to be
fine.
I know that the agg library has been around for quite a long time, so
that also means that such a basic bug is unlikely.
I've reattached the (slightly modified) script that reproduces the
problem, along with a sample image that it uses. The only change to
the script is right at the top, where a different image is read, a
quick statement is placed to add an alpha channel if there is not
already one, and I'm attempting to use premultiplied alphas. I've
also attached a screenshot of the output. Notice that in this case,
both "transparent" images look wrong.
Now, if I 1) hack agg to remove the alpha clipping, and 2) modify the
one line in the attached python script so that I use straight alpha,
everything looks right. Specifically, I removed every instance of the
code below from xxxx, rebuilt all of the matplotlib .so's, and
specifically replaced _image.so and _backend_agg.so in my matplotlib
distribution.
 if(fg[order_type::A] > base_mask) fg[order_type::A]
= base_mask;
 if(fg[order_type::R] > fg[order_type::A])
fg[order_type::R] = fg[order_type::A];
 if(fg[order_type::G] > fg[order_type::A])
fg[order_type::G] = fg[order_type::A];
 if(fg[order_type::B] > fg[order_type::A])
fg[order_type::B] = fg[order_type::A];
On Wed, Oct 19, 2011 at 2:34 PM, Daniel Hyams <dh...@gm...> wrote:
>
> Ah, thanks so much Michael! That explanation helps a great deal; I
> was always considering things in "straight alpha" format, not even
> knowing that there was alternative.
>
> I'll play with this tonight; I don't see any problem getting the thing
> working, though, now that I know what agg expects to see...
>
> And yes, alpha support in the image class would be very helpful ;)
>
> On Wed, Oct 19, 2011 at 2:16 PM, Michael Droettboom <md...@st...> wrote:
> > You are right that Agg is doing the resizing here. Agg expects
> > premultiplied alpha. See [1] for information about what that means.
> >
> > [1] http://en.wikipedia.org/wiki/Alpha_compositing
> >
> > After Agg interpolates the pixel values, to prevent oversaturation it
> > truncates all values to be less than alpha (which makes sense if everything
> > is assumed to be premultiplied alpha). Arguably, the bug here is that
> > nearest neighbor (which doesn't have to do any blending) doesn't perform the
> > truncation step -- then both would look "wrong".
> >
> > It happens in this code snippet in span_image_filter_rgba: (base_mask is
> > 255)
> >
> >         if(fg[order_type::A] > base_mask)     fg[order_type::A]
> > = base_mask;
> >         if(fg[order_type::R] > fg[order_type::A]) fg[order_type::R]
> > = fg[order_type::A];
> >         if(fg[order_type::G] > fg[order_type::A]) fg[order_type::G]
> > = fg[order_type::A];
> >         if(fg[order_type::B] > fg[order_type::A]) fg[order_type::B]
> > = fg[order_type::A];
> >
> > So, the solution to make a partially transparent image is to not do:
> >
> >   pix[:,:,3] = 127
> >
> > but instead, do
> >
> >   pix *= 0.5
> >
> > Of course, the real fix here is to support alpha blending properly in the
> > image class, then the user wouldn't have to deal with such details. A bug
> > should probably be filed in the matplotlib issue tracker for this.
> >
> > Mike
> >
> > On 10/19/2011 12:23 PM, Daniel Hyams wrote:
> >
> > [Sorry, I keep getting tripped up with HTML mail....resent in ascii,
> > and resaved one of the attachment png's to make it smaller.]
> >
> >
> > Example script attached (PIL required). Basically, if I impose a
> > specific value into an image's alpha channel and use any interpolation
> > scheme other than 'nearest', there appears gray all where the figure
> > didn't have any color to begin with.  I've also attached a screenshot
> > of the output of the script on my machine.
> >
> > Hopefully I'm doing something wrongly?
> >
> > I chased the problem and managed to hack in a solution that fixes the
> > problem, but it's extremely inefficient...basically, in matplotlib's
> > image.py, routine BboxImage.make_image, you can create two images
> > there....one with no alpha channel (call it imRGB) and one with (call
> > it imRGBA). Go through all of the routine, doing exactly the same
> > things to both of the images *except* for the interpolation, which is
> > set to 'nearest' for imRGBA. Then, rip the colors out of imRGB, the
> > alpha channel off of imRGBA, and put them together....go through all
> > of the routine again with this composited image, and it works. I
> > know...I told you it was bad ;)
> >
> > The problem seems to be in the "resize" call in that routine...resize,
> > which calls into C code, does not appear to handle things correctly
> > when the alpha is anything other than 255's across the board. It
> > might be a problem in the agg routines, but hopefully it is just maybe
> > a misuse of the agg routines.
> >
> > The behavior seems to be backend independent as far as I could test (I
> > tried with wxagg and tk backends). I am using mpl 1.0.0 on Windows if
> > it matters.
> >
> >
> > --
> > Daniel Hyams
> > dh...@gm...
> >
> > ------------------------------------------------------------------------------
> > 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-d2d-oct
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> > ------------------------------------------------------------------------------
> > The demand for IT networking professionals continues to grow, and the
> > demand for specialized networking skills is growing even more rapidly.
> > Take a complimentary Learning@Ciosco Self-Assessment and learn
> > about Cisco certifications, training, and career opportunities.
> > http://p.sf.net/sfu/cisco-dev2dev
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>
>
>
> --
> Daniel Hyams
> dh...@gm...
--
Daniel Hyams
dh...@gm...

thank you, I am not quite sure how to 'draw' the shapefile but making those
changes and removing the shapefile has sped the processing up considerably!
Thank you for your help
On Wed, Oct 19, 2011 at 11:42 PM, Jeff Whitaker <js...@fa...> wrote:
> On 10/18/11 8:55 PM, questions anon wrote:
>
> Thanks Jeff, that certainly speeds it up! But when I take them out of the
> loop and place them elsewhere they are no longer added to the map.
> Is there someway I can call them in the loop but still get it to run
> quickly?
> Thanks
>
>
> Just the Basemap instance creation and the transformation of coordinates to
> projection space should be hoisted out of the loop
>
>
> map =
> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>
> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
> x,y=map(*N.meshgrid(LON,LAT))
>
> you can leave the other statements in.
>
> If you still have memory issues, bring the readshapefile call out, and draw
> the shapes whose coordinates are stored in the instance variable
> map.DSE_REGIONS manually in the loop.
>
> -Jeff
>
>
> On Fri, Oct 14, 2011 at 10:54 PM, Jeff Whitaker <js...@fa...>wrote:
>
> On 10/12/11 8:20 PM, questions anon wrote:
>
> Hi All,
> I keep receiving a memory error when processing many netcdf files. I
> assumed it had something to do with how I loop things and maybe needed to
> close things off properly but I recently received an error that made me
> think it might be because of matplotlib.
>
> In the code below I am looping through a bunch of netcdf files (each file
> is hourly data for one month) and within each netcdf file I am outputting a
> *png file every three hours. This works for one netcdf file (therefore one
> month) but when it begins to process the next netcdf file I receive a memory
> error (see below). Since I have tidied some of my code up it seems to
> process partly into the second file but then I still receive the memory
> error.
> I have tried a few suggestions such as:
> -Combining the dataset using MFDataset (using NETCDF4) is not an option
> because the files do not have unlimited dimension.
> - gc.collect() but that just results in a *GEOS_ERROR: bad allocation
> error*.
> -only open LAT and LON once (which worked)
>
> System Details:
> Python 2.7.2 |EPD 7.1-2 (32-bit)| (default, Jul 3 2011, 15:13:59) [MSC
> v.1500 32 bit (Intel)] on win32
>
> Any feedback will be greatly appreciated as I seem to keep ending up with
> memory errors when working with netcdf files this even happens if I am using
> a much better computer.
>
> *Most recent error: *
> Traceback (most recent call last):
> File "C:\plot_netcdf_merc_multiplot_across_multifolders_TSFC.py", line
> 78, in <module>
> plt.savefig((os.path.join(outputfolder, 'TSFC'+date_string+'UTC.png')))
> File "C:\Python27\lib\site-packages\matplotlib\pyplot.py", line 363, in
> savefig
> return fig.savefig(*args, **kwargs)
> File "C:\Python27\lib\site-packages\matplotlib\figure.py", line 1084, in
> savefig
> self.canvas.print_figure(*args, **kwargs)
> File
> "C:\Python27\lib\site-packages\matplotlib\backends\backend_wxagg.py", line
> 100, in print_figure
> FigureCanvasAgg.print_figure(self, filename, *args, **kwargs)
> File "C:\Python27\lib\site-packages\matplotlib\backend_bases.py", line
> 1923, in print_figure
> **kwargs)
> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
> line 438, in print_png
> FigureCanvasAgg.draw(self)
> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
> line 393, in draw
> self.renderer = self.get_renderer()
> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
> line 404, in get_renderer
> self.renderer = RendererAgg(w, h, self.figure.dpi)
> File "C:\Python27\lib\site-packages\matplotlib\backends\backend_agg.py",
> line 59, in __init__
> self._renderer = _RendererAgg(int(width), int(height), dpi,
> debug=False)
> RuntimeError: Could not allocate memory for image
>
> *Error when I added gc.collect()*
> GEOS_ERROR: bad allocation
>
> *Old error (before adding gc.collect() )*
> *Traceback (most recent call last):
> File "d:/plot_netcdf_merc_multiplot_across_multifolders__memoryerror.py",
> line 44, in <module>
> TSFC=ncfile.variables['T_SFC'][1::3]
> File "netCDF4.pyx", line 2473, in netCDF4.Variable.__getitem__
> (netCDF4.c:23094)
> MemoryError*
>
>
>
> from netCDF4 import Dataset
> import numpy as N
> import matplotlib.pyplot as plt
> from mpl_toolkits.basemap import Basemap
> from netcdftime import utime
> from datetime import datetime
> import os
> import gc
>
>
> shapefile1="E:/
>
> griddeddatasamples/GIS/DSE_REGIONS"
> MainFolder=r"E:/griddeddatasamples/GriddedData/InputsforValidation/T_SFC/"
> OutputFolder=r"E:/griddeddatasamples/GriddedData/OutputsforValidation"
> fileforlatlon=Dataset("E:/griddeddatasamples/GriddedData/InputsforValidation/T_SFC/TSFC_1974_01/IDZ00026_VIC_ADFD_T_SFC.nc",
> 'r+', 'NETCDF4')
> LAT=fileforlatlon.variables['latitude'][:]
> LON=fileforlatlon.variables['longitude'][:]
>
> for (path, dirs, files) in os.walk(MainFolder):
> for dir in dirs:
> print dir
> path=path+'/'
> for ncfile in files:
> if ncfile[-3:]=='.nc':
> print "dealing with ncfiles:", ncfile
> ncfile=os.path.join(path,ncfile)
> ncfile=Dataset(ncfile, 'r+', 'NETCDF4')
> TSFC=ncfile.variables['T_SFC'][1::3]
> TIME=ncfile.variables['time'][1::3]
> ncfile.close()
> gc.collect()
>
> for TSFC, TIME in zip((TSFC[:]),(TIME[:])):
> cdftime=utime('seconds since 1970年01月01日 00:00:00')
> ncfiletime=cdftime.num2date(TIME)
> print ncfiletime
> timestr=str(ncfiletime)
> d = datetime.strptime(timestr, '%Y-%m-%d %H:%M:%S')
> date_string = d.strftime('%Y%m%d_%H%M')
>
> map =
> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>
> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
> x,y=map(*N.meshgrid(LON,LAT))
> map.drawcoastlines(linewidth=0.5)
> map.readshapefile(shapefile1, 'DSE_REGIONS')
> map.drawstates()
>
> plt.title('Surface temperature at %s UTC'%ncfiletime)
> ticks=[-5,0,5,10,15,20,25,30,35,40,45,50]
> CS = map.contourf(x,y,TSFC, ticks, cmap=plt.cm.jet)
> l,b,w,h =0.1,0.1,0.8,0.8
> cax = plt.axes([l+w+0.025, b, 0.025, h], )
> cbar=plt.colorbar(CS, cax=cax, drawedges=True)
>
> plt.savefig((os.path.join(OutputFolder,
> 'TSFC'+date_string+'UTC.png')))
> plt.close()
> gc.collect()
>
>
> Try moving these lines
>
>
> map =
> Basemap(projection='merc',llcrnrlat=-40,urcrnrlat=-33,
>
> llcrnrlon=139.0,urcrnrlon=151.0,lat_ts=0,resolution='i')
> x,y=map(*N.meshgrid(LON,LAT))
> map.drawcoastlines(linewidth=0.5)
> map.readshapefile(shapefile1, 'DSE_REGIONS')
> map.drawstates()
>
> out of the loop.
>
> -Jeff
>
>
>
>

On Fri, Oct 14, 2011 at 3:42 AM, Nils Wagner
<nw...@ia...>wrote:
> Hi all,
>
> what is the native "data" coordinate system for Arrows in
> a polar plot ?
>
> How do I add arrows to a polar plot ?
>
> An example would be appreciated.
> fig = figure(figsize=(12,12))
> ax = fig.add_subplot(111, polar=True)
>
> Nils
>
>
I don't know if it is an existing feature or not. If it isn't, then I think
a feature request should be filed. If it is, then a request should be filed
anyway for an example to be added to the gallery.
Ben Root

Ah, thanks so much Michael! That explanation helps a great deal; I
was always considering things in "straight alpha" format, not even
knowing that there was alternative.
I'll play with this tonight; I don't see any problem getting the thing
working, though, now that I know what agg expects to see...
And yes, alpha support in the image class would be very helpful ;)
On Wed, Oct 19, 2011 at 2:16 PM, Michael Droettboom <md...@st...> wrote:
> You are right that Agg is doing the resizing here. Agg expects
> premultiplied alpha. See [1] for information about what that means.
>
> [1] http://en.wikipedia.org/wiki/Alpha_compositing
>
> After Agg interpolates the pixel values, to prevent oversaturation it
> truncates all values to be less than alpha (which makes sense if everything
> is assumed to be premultiplied alpha). Arguably, the bug here is that
> nearest neighbor (which doesn't have to do any blending) doesn't perform the
> truncation step -- then both would look "wrong".
>
> It happens in this code snippet in span_image_filter_rgba: (base_mask is
> 255)
>
>         if(fg[order_type::A] > base_mask)     fg[order_type::A]
> = base_mask;
>         if(fg[order_type::R] > fg[order_type::A]) fg[order_type::R]
> = fg[order_type::A];
>         if(fg[order_type::G] > fg[order_type::A]) fg[order_type::G]
> = fg[order_type::A];
>         if(fg[order_type::B] > fg[order_type::A]) fg[order_type::B]
> = fg[order_type::A];
>
> So, the solution to make a partially transparent image is to not do:
>
>   pix[:,:,3] = 127
>
> but instead, do
>
>   pix *= 0.5
>
> Of course, the real fix here is to support alpha blending properly in the
> image class, then the user wouldn't have to deal with such details. A bug
> should probably be filed in the matplotlib issue tracker for this.
>
> Mike
>
> On 10/19/2011 12:23 PM, Daniel Hyams wrote:
>
> [Sorry, I keep getting tripped up with HTML mail....resent in ascii,
> and resaved one of the attachment png's to make it smaller.]
>
>
> Example script attached (PIL required). Basically, if I impose a
> specific value into an image's alpha channel and use any interpolation
> scheme other than 'nearest', there appears gray all where the figure
> didn't have any color to begin with.  I've also attached a screenshot
> of the output of the script on my machine.
>
> Hopefully I'm doing something wrongly?
>
> I chased the problem and managed to hack in a solution that fixes the
> problem, but it's extremely inefficient...basically, in matplotlib's
> image.py, routine BboxImage.make_image, you can create two images
> there....one with no alpha channel (call it imRGB) and one with (call
> it imRGBA). Go through all of the routine, doing exactly the same
> things to both of the images *except* for the interpolation, which is
> set to 'nearest' for imRGBA. Then, rip the colors out of imRGB, the
> alpha channel off of imRGBA, and put them together....go through all
> of the routine again with this composited image, and it works. I
> know...I told you it was bad ;)
>
> The problem seems to be in the "resize" call in that routine...resize,
> which calls into C code, does not appear to handle things correctly
> when the alpha is anything other than 255's across the board. It
> might be a problem in the agg routines, but hopefully it is just maybe
> a misuse of the agg routines.
>
> The behavior seems to be backend independent as far as I could test (I
> tried with wxagg and tk backends). I am using mpl 1.0.0 on Windows if
> it matters.
>
>
> --
> Daniel Hyams
> dh...@gm...
>
> ------------------------------------------------------------------------------
> 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-d2d-oct
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
-- 
Daniel Hyams
dh...@gm...