matplotlib-devel Mailing List for matplotlib (Page 4)

John, Jeff,

> Eric:  Thanks - contour indeed now seems to work perfectly with masked 
> arrays, but I still have problems with contourf (see attached 
> ortho_test.png).  Unfortunately, neither of your suggested workarounds 
> help, the first makes no difference and the second makes it much worse.
> -Jeff

The attached patch against the cntr.c in cvs does the following:

1) Fixes the bug you (Jeff) described above.

2) Adds a print function for debugging, but normally unused.

3) Fixes a minor bug in which space for an array of ints was allocated 
where only an array of chars was used.

The original masked array contourf bug is still there, but I suspect 
(and hope!) it will not present a serious problem for basemap.  I still 
want to find and fix it, but that may take a long time.

I want to make some minor cleanups and one API change in contour.py, but 
I will leave that for a separate message, probably within 24 hours.

Eric

I have been trying to deal with some font problems related to the new tex=20
capabilities in MPL. Let me summarize what MPL is doing, when text.usetex i=
s=20
true in rc:

texmanager runs TeX (or LaTeX) on a string, and John has somehow extracted =
an=20
image of that string and its bbox information to intelligently layout and=20
render the text.

the ps backend will produce a transitional eps file with a bunch of psfrag=
=20
markers, along with an associated tex file. backend_ps runs latex on the te=
x=20
file, which embeds the eps, and replaces the markers with the actual text.=
=20
Now we have a ps file, which can be converted into an eps if desired with=20
ps2epsi, or maybe this could be changed to a call to ghostscript: gs=20
=2DdNOPAUSE -sDEVICE=3Depswrite -sOutputFile=3Dtex_demo.eps tex_demo.ps. As=
 far as=20
the user is concerned, you type savefig('foo.eps') and get foo.eps,=20
blissfully unaware of all the intermediate steps.

Here is my current problem. I embed an eps file generated with ps2epsi in a=
=20
new tex document. The dvi looks ok, but after dvips, the text in my figure=
=20
gets inverted and shifted. This seems to be a bigger problem when using lat=
ex=20
classes that do some font handling behind the scenes, for example, article=
=20
seems ok, but revtex4 and ha-prosper yield unacceptable results.

On the other hand, if I use ghostscript to generate the eps, I can embed th=
e=20
files and the printed page looks fine, but the fonts look terrible on scree=
n.=20
Here is a comment from the afpl website=20
http://www.cs.wisc.edu/~ghost/doc/AFPL/8.50/Issues.htm:

=2D--
pswrite device generates low level PostScript.

pswrite and epswrite devices reduce everything to path, fill, stroke, clip=
=20
image, and imagemask operations. Although the resulting file prints OK it=20
produces unsatisfactory results when scaled, distilled or imported into=20
graphic editors. The file can easily exceed 4GB and hit file size limits in=
=20
some applications or operation systems. Handling of big files is slow.=20
=2D--
The associated bug report (filed over 2 years ago) says this is a low prior=
ity=20
problem.

How can MPL deal with these non-MPL issues? I know John doesn't like the id=
ea=20
of handling text in eps as images, but if we did, could that be a suitable=
=20
workaround? Does anyone have another suggestion?

Darren

On Wed, 2005-06-01 at 15:49 -0700, Andrew Straw wrote:
> John Hunter wrote:
> >>>>>>"Nicholas" == Nicholas Young <su...@su...> writes:
> > 
> > 
> >     Nicholas> Now done in the attached patch, I also added support for
> >     Nicholas> MxNx3 images; as I suspected these are noticeably slower
> >     Nicholas> than MxNx4 images but I changed my mind and decided it
> >     Nicholas> was worth supporting them.
> > 
> > Great, I just committed this to CVS.
> > 
> > Andrew, if you get a minute to update from CVS, can you make sure that
> > the PIL changes don't cause a problem for your PIL using mpl scripts?
> 
> I didn't have much of a check, but image_demo3.py still works.
> 
> This may be the apparently-longstanding imshow resizing bug (that I 
> haven't followed), but this demo shows some storage behavior when 
> resizing -- horizontal stretching of the window allows the aspect ratio 
> of the image to change to horizontally stretched, but vertical 
> stretching of the window appears to scale the image to maintain its 
> original aspect ratio.

I don't think this is connected to the changes I've made; as I've
changed none of the resizing/streaching/fixed aspect code.  I've not
followed any prior discussion (and so don't know why the problem hasn't
been fixed) but if I'm reading it correctly it's fairly clear from the
general imshow code that problem is going to manifest itself.

Nick

On Wednesday 01 June 2005 18:38, John Hunter wrote:

> Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).
>
That beeing said, I'm also in the need of a way of saving eps figures of gray 
contours in negative, in order to save toner... with the standard gray 
colormap, my contours are very dark, leading to a huge consumption of toner.

With a gray colormap "in negative", the result would be at least as readable 
and consumes much less toner.

Two strategies are possible here:

- either display the gray colormap as usual on the screen, but save the figure 
in negative with the "eps" or "png" backends (this is AFAIK the default 
behaviour of IDL),

- or provide a "negative gray" colormap ; I've tried to hack the cm.py in that 
way, and tried something like:

_ngray_data =  {'red':   ((0., 1, 1), (1., 0, 0)),
               'green': ((0., 1, 1), (1., 0, 0)),
               'blue':  ((0., 1, 1), (1., 0, 0))}

but there seems to be a problem with the highest values, that keep beeing 
displayed in white instead of black.

What do you think ?

PS: which place would be the more appropriate for this discussion, the -user 
or -devel mailing list ?

Cheers,
Nicolas

John Hunter wrote:
>>>>>>"Nicholas" == Nicholas Young <su...@su...> writes:
> 
> 
>     Nicholas> Now done in the attached patch, I also added support for
>     Nicholas> MxNx3 images; as I suspected these are noticeably slower
>     Nicholas> than MxNx4 images but I changed my mind and decided it
>     Nicholas> was worth supporting them.
> 
> Great, I just committed this to CVS.
> 
> Andrew, if you get a minute to update from CVS, can you make sure that
> the PIL changes don't cause a problem for your PIL using mpl scripts?

I didn't have much of a check, but image_demo3.py still works.

This may be the apparently-longstanding imshow resizing bug (that I 
haven't followed), but this demo shows some storage behavior when 
resizing -- horizontal stretching of the window allows the aspect ratio 
of the image to change to horizontally stretched, but vertical 
stretching of the window appears to scale the image to maintain its 
original aspect ratio.

Cheers!
Andrew

>>>>> "Keith" == Keith Goodman <kwg...@gm...> writes:

    Keith> Thought you might be interested in knowing that the Octave
    Keith> maintainers are looking into using matplotlib in Octave.

Hi Keith, 

I very recently exchanged emails with Tom Holroyd (CCd on this mail),
who was also interested in adding mpl plotting to octave.  We thought
that embedding the python interpreter might be the path of least
resistance.  It might be good for Tom to be in touch with the octave
people to avoid duplication of effort.

There are also some inconsistencies in the plotting functions between
mpl and matlab, in addition to the lack of 3D.  For example, our plot
command does not currently support plot(x, Y) or plot(X,Y) where X and
Y are matrices, though it would be easy to add such functionality.
Also, the default behavior of imshow is pretty different (in
matplotlib imshow scales the image to fit the current axes box).
These differences will surely cause some minor headaches, but for the
most part the interfaces are compatible.  A combination of
extending/patching matplotlib and doing some translation on the octave
side would probably work for most (2D) cases.

Thanks for the heads up,
JDH

Thought you might be interested in knowing that the Octave maintainers
are looking into using matplotlib in Octave.

(Octave, by the way, is a free language for numerical computation that
is mostly compatible with Matlab.)

---------- Forwarded message ----------
From: John W. Eaton <jwe at bevo dot che dot wisc dot edu>
Date: Jun 1, 2005 9:54 AM
Subject: Re: Line thickness
To: Keith Goodman <kwgoodman at gmail dot com>
Cc: octave maintainers mailing list <maintainers at octave dot org>


[I'm moving this discussion to the maintainers list.]

On  1-Jun-2005, Keith Goodman wrote:

| Take a look at the beautiful screenshots (and the code used to
| generate the plots) at
| http://matplotlib.sourceforge.net/screenshots.html

OK, it seems like it would be useful to be able to use this directly
from Octave.  What would be the best way to make that happen?  Do we
need a general Octave <-> Python interface, or can we just build
bindings for matplotlib?  How about a handle graphics compatible
interface for Octave that uses matplotlib?  The one major difficulty
that I see is that matplotlib seems to only handle 2-d plotting.

jwe

On Wednesday 01 June 2005 18:50, Fernando Perez wrote:
>
> I wonder though: if we also get 'reversed' colormaps, is this going to
> be a cause for confusion with the 'reversed' colorbar keyword?  It may
> not be a problem in the end, as long as the two different ideas are
> clearly explained, to prevent others falling into the same trap I did.
>
Please feel free to use any keyword you want, provided the feature is 
implemented ! English is not my native language, so I just came to "reverse" 
as the closest word to what I had in mind, but for sure there must be better 
alternatives (invert, mirror, whatever)

Nicolas

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
>     Fernando> mmh, just yesterday I was talking to JDH about this: I
>     Fernando> have the feeling that the right place to implement this
>     Fernando> would be to provide colormaps (the beasts lurking
>     Fernando> underneath colorbars) with an easy way to get reversed
>     Fernando> versions.  I don't think that a hack at the level of the
>     Fernando> colorbar function is the right place, design wise, to do
>     Fernando> this.  But I could be wrong...
> 
> Unless I misunderstand, Nicolas and you want different things.  You
> want a reversed color map (eg for the case of jet, red would map to
> small numbers and blue to large numbers).  Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).

Ah!  Yes, sorry: I did misunderstand Nicolas, probably because I parsed 
his post through the lens of our discussion too quickly.  Sorry for the 
noise...

I wonder though: if we also get 'reversed' colormaps, is this going to 
be a cause for confusion with the 'reversed' colorbar keyword?  It may 
not be a problem in the end, as long as the two different ideas are 
clearly explained, to prevent others falling into the same trap I did.

f

On Wednesday 01 June 2005 18:38, John Hunter wrote:

> Unless I misunderstand, Nicolas and you want different things.  You
> want a reversed color map (eg for the case of jet, red would map to
> small numbers and blue to large numbers).  Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).
>
> Or am I misunderstanding?
>
At least you understood correctly what I meant ;-)

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:

    Fernando> mmh, just yesterday I was talking to JDH about this: I
    Fernando> have the feeling that the right place to implement this
    Fernando> would be to provide colormaps (the beasts lurking
    Fernando> underneath colorbars) with an easy way to get reversed
    Fernando> versions.  I don't think that a hack at the level of the
    Fernando> colorbar function is the right place, design wise, to do
    Fernando> this.  But I could be wrong...

Unless I misunderstand, Nicolas and you want different things.  You
want a reversed color map (eg for the case of jet, red would map to
small numbers and blue to large numbers).  Nicolas wants a standard
colormap but with the colorbar display inverted (red would still map
to large numbers but for vertical colorbars would be on the bottom and
for horizontal colorbars would be on the left -- the colorbar tick
labels would change too).

Or am I misunderstanding?

JDH

Nicolas Girard wrote:
> Hi all,
> 
> with most of my contours, upper values are on the left side and lower values 
> on the right side ; to the contrary the colorbar (created with 
> orientation='horizontal') displays colors ranging from the lowest to the 
> highest ; this leads to an unpleasant look. (No, I cannot reverse my whole 
> contours, their orientation is important ;-)
> 
> What I'd find useful is a "reverse" option that would make the colorbar 
> display colors ranging from the highest to the lowest ; and I've tried to 
> hack the figure.py file.

mmh, just yesterday I was talking to JDH about this: I have the feeling 
that the right place to implement this would be to provide colormaps 
(the beasts lurking underneath colorbars) with an easy way to get 
reversed versions.  I don't think that a hack at the level of the 
colorbar function is the right place, design wise, to do this.  But I 
could be wrong...

I've been meaning to make some changes to the colormaps code to fix this 
along with a number of other annoyances it has, but I haven't gotten 
around to it yet.

Best,

f

Hi all,

with most of my contours, upper values are on the left side and lower values 
on the right side ; to the contrary the colorbar (created with 
orientation='horizontal') displays colors ranging from the lowest to the 
highest ; this leads to an unpleasant look. (No, I cannot reverse my whole 
contours, their orientation is important ;-)

What I'd find useful is a "reverse" option that would make the colorbar 
display colors ranging from the highest to the lowest ; and I've tried to 
hack the figure.py file.

You'll find the attached patch as a result. apart from fixing a pair of typos 
in the docstring, it allows *colors* of the colorbars to be reversed, but not 
its ticks :-/ 

Then I'm afraid this patch is all but useful... but perhaps it helps getting 
the idea. I'd glad if this feature could be added to the colorbar...

Thanks for reading,

Cheers,
Nicolas

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:

    Nicholas> Now done in the attached patch, I also added support for
    Nicholas> MxNx3 images; as I suspected these are noticeably slower
    Nicholas> than MxNx4 images but I changed my mind and decided it
    Nicholas> was worth supporting them.

Great, I just committed this to CVS.

Andrew, if you get a minute to update from CVS, can you make sure that
the PIL changes don't cause a problem for your PIL using mpl scripts?

Thanks!
JDH

On Wed, 2005-06-01 at 13:14 +0100, Nicholas Young wrote:
> On Wed, 2005-06-01 at 12:39 +0100, Nicholas Young wrote:
> > On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> > > >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> > > I have mixed feelings about making this a separate class / separate
> > > function.  The current axes imshow / image.AxesImage is already
> > > overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
> > > What is the logic of making a special functions/classes case for MxNx4
> > > with directshow.  On the one hand, I appreciate the desire to simplify
> > > the code by pulling it into separate classes and functions.  On the
> > > other hand, I wonder if it will confuse users to have one separate
> > > function for UInt8 images and another for everything else.  Another
> > > worry I have about the separate DirectImage class is that it copies
> > > much of the image resize functionality from AxesImage, including the
> > > broken handling of aspect='preserve'.  This too argues for keeping as
> > > much functionality in AxesImage as possible, testing for A.typecode()
> > > where appropriate.  What do you think?
> 
> Sorry to reply to my own message but I realised just after sending it
> that it didn't make any sense (as MxNx4 images aren't normalised
> anyway).  I now realise that it makes sense to assume that an MxNx4
> UInt8 image will contain pixel data as John suggested and I'll rewrite
> my code to implement this.
> 
> It also occurred  to me that it would make sense to change the PIL code
> to avoid the UInt8 -> Float -> UInt transition.  I'll try implementing
> this after making the alterations John suggested.

Now done in the attached patch, I also added support for MxNx3 images;
as I suspected these are noticeably slower than MxNx4 images but I
changed my mind and decided it was worth supporting them.

I changed the PIL image output to output from PIL RGBX (alpha is 255) or
RGBA images only when converting to a string and then array.  This will
use more memory but, as the conversion to RGBA is done no more than once
and by PIL code (which is probably optimised), should be the fastest
option.  I changed the conversion code to always attempt to convert to
RGBA whenever an unsupported format is given and to raise an error on
catching a ValueError (rather than before trying the conversion); this
adds support for several image types.  I'd also suggest changing the
error raised here to a ValueError rather than a SystemError (as the
error is due to an unsupported value) but haven't in case others are
catching the SystemError.

Additionally I changed the docstring for the imshow function to state
that floating point MxNx3 and MxNx4 arrays aren't normalised (this was
the original source of my earlier confusion).

Nick

On Wed, 2005-06-01 at 12:39 +0100, Nicholas Young wrote:
> On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> > >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> > I have mixed feelings about making this a separate class / separate
> > function.  The current axes imshow / image.AxesImage is already
> > overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
> > What is the logic of making a special functions/classes case for MxNx4
> > with directshow.  On the one hand, I appreciate the desire to simplify
> > the code by pulling it into separate classes and functions.  On the
> > other hand, I wonder if it will confuse users to have one separate
> > function for UInt8 images and another for everything else.  Another
> > worry I have about the separate DirectImage class is that it copies
> > much of the image resize functionality from AxesImage, including the
> > broken handling of aspect='preserve'.  This too argues for keeping as
> > much functionality in AxesImage as possible, testing for A.typecode()
> > where appropriate.  What do you think?
> 
> I'm happy for it be be called from imshow but I can't think of a syntax
> to do so which isn't going to be confusing.  The existing variations to
> imshow are all based upon the type of the input image and this won't
> work here - the case of someone who wants to plot a MxNx4 UInt8 array
> and have the values it contains normalised being the problem.  Another
> keyword parameter could be added which only takes effect in this case; I
> thought this likely to confuse but if you prefer it I'm happy.

Sorry to reply to my own message but I realised just after sending it
that it didn't make any sense (as MxNx4 images aren't normalised
anyway).  I now realise that it makes sense to assume that an MxNx4
UInt8 image will contain pixel data as John suggested and I'll rewrite
my code to implement this.

It also occurred  to me that it would make sense to change the PIL code
to avoid the UInt8 -> Float -> UInt transition.  I'll try implementing
this after making the alterations John suggested.

Nick

On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> I have mixed feelings about making this a separate class / separate
> function.  The current axes imshow / image.AxesImage is already
> overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
> What is the logic of making a special functions/classes case for MxNx4
> with directshow.  On the one hand, I appreciate the desire to simplify
> the code by pulling it into separate classes and functions.  On the
> other hand, I wonder if it will confuse users to have one separate
> function for UInt8 images and another for everything else.  Another
> worry I have about the separate DirectImage class is that it copies
> much of the image resize functionality from AxesImage, including the
> broken handling of aspect='preserve'.  This too argues for keeping as
> much functionality in AxesImage as possible, testing for A.typecode()
> where appropriate.  What do you think?

I'm happy for it be be called from imshow but I can't think of a syntax
to do so which isn't going to be confusing.  The existing variations to
imshow are all based upon the type of the input image and this won't
work here - the case of someone who wants to plot a MxNx4 UInt8 array
and have the values it contains normalised being the problem.  Another
keyword parameter could be added which only takes effect in this case; I
thought this likely to confuse but if you prefer it I'm happy.

Nick