2008/1/29, Neil Crighton <[EMAIL PROTECTED]>:
>
> I think it would be a shame to lose the current matplotlib 3d plotting
> functionality, even if it's not ideal. I've found it very useful for
> plotting small sets of data, and much more straightforward to use than
> Mayavi or other vtk-based 3d pl
Michael Droettboom skrev:
> Ok. I'll change this in SVN.
>
It works for me now as well.
/Jörgen
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/g
Michael Droettboom skrev:
> For some reason, when axis() is called, the "emit" flag (which
> determines whether to update all of the shared axes) was being set to
> False by default. There may be a good reason for this that I'm not
> aware of, but it seems reasonably harmless, and doesn't break
So I have a (slightly) new plot type I would like to add to the
matplotlib codebase, and I'd like to ask A) if people would be
interested in the patch and B) what the best way to implement it would be.
I am currently calling the plot type "pcontourf"--it's essentially a
pcolor, but instead of a
Jordan,
This sounds useful, but I think it can be implemented without any new
plot type, simply by using a different sort of norm to do the
colormapping. I need to add this anyway, and I have a prototype. It is
very simple. I will get it in within the next few days, and then you
can see whe
In the course of answering a question by Alan Isaac, I saved some
figures at different dpi values and hit a bug with png output:
imshow(rand(100,100))
gcf().savefig('f200.png', dpi=200)
This results in tick labels that overlap the image, and it gets worse
with higher dpi. PS backend output is
I was just working with a student to do this. It is straightforward
(using norms, as Eric suggests), but not short. I think it would be
good to include wrappers for creating these norms to MPL.
The advantage is then it works for everything: pcolor, scatter, etc.
-Rob
On Jan 31, 2008, at 1
I noticed this bug last week (and forgot to send it in until now.. I
know.. shame on me..).
Here is the workaround (responsible for my laziness):
figure(dpi=500)
# make a figure
savefig(dpi=500)
That is, as long as the figure and savefig dpi match, it looks
alright. Otherwise, the tick lab
