matplotlib-devel Mailing List for matplotlib

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