matplotlib-devel Mailing List for matplotlib (Page 463)

On Monday 31 July 2006 09:32, JIM MacDonald wrote:
> > The resolution for Postscript is 72 dpi, and I'm not sure this can be
> > changed. Would you send me an example postscript file along with the
> > original png?
>
> Sure,
> http://jimmacdonald.co.uk/matplotlib/image.png
> http://jimmacdonald.co.uk/matplotlib/image.eps
> http://jimmacdonald.co.uk/matplotlib/image.py
>
> image.py generates image.eps from image.png. image.png is simple
> enough for ps2pdf not to use DCT encoding. Looking at the postscript
> shows that the image has resolution of 335x230 compared to the
> original of 318x301.

I don't think this is a problem with the postscript backend. You're rescaling 
the image in your script. Try something like this: 

from pylab import *

rc('text', usetex=True)
rc('ps', usedistiller="xpdf")

figure(1,figsize=(6, 4))
im=imread('image.png')
imshow(im,interpolation='nearest')#,extent=[0.98, 20, 0.01, 0.5])
#axis('normal');
savefig('image.eps')

Darren

> I'll look into this soon. I'm hesitant to add another rc option, maybe we can
> consider using these settings as the defaults. I'll post again after I have
> had a chance to play with it.
Defaulting to lossless FlateEncode compression seems like a good idea,
if the file is too big you can always run another distill cycle after
wards manually.

Another possibility would be to set the option based on the format of
the image loaded (I'm  sure I read somewhere that it is planned to
support formats other than PNG). ie FlateEncode for GIF's and PNG's
and DCTEncode for JPEG's.

> The resolution for Postscript is 72 dpi, and I'm not sure this can be changed.
> Would you send me an example postscript file along with the original png?
Sure,
http://jimmacdonald.co.uk/matplotlib/image.png
http://jimmacdonald.co.uk/matplotlib/image.eps
http://jimmacdonald.co.uk/matplotlib/image.py

image.py generates image.eps from image.png. image.png is simple
enough for ps2pdf not to use DCT encoding. Looking at the postscript
shows that the image has resolution of 335x230 compared to the
original of 318x301.

JIM
---

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:
    Eric> return newtrans if not units == 'inches': raise
    Eric> ValueError('units must be dots or inches') if fig is None:

This all looks great and I like the interface.  My only suggestions is
to add points (1/72. inches) since this is commonly used throughout
matplotlib, is easy, and is the most common distance metric used in
graphics.

    Eric> Minimal testing and illustration of the use of offsets is
    Eric> now in examples/transoffset.py.  It includes cartesian and
    Eric> polar coordinates.
 
Excellent!

JDH

>>>>> "Bill" == Bill Baxter <wb...@gm...> writes:

    Bill> Ok.  Such a pain though...  Are whole files acceptable
    Bill> instead of diffs?  It's relatively easy to do a windiff or

Multiple contributions per patch are fine, just do like you did and
list what is in them.  If there is an objection to part of the patch,
you may be asked to resubmit w/o the controversial parts, but if all
the changes look good the whole thing can go in.  And we prefer svn
diffs over individual files.

Ken, would you like to be added to the devel list to handle some of
these patches.  Just email me your sf id if so.

JDH

John,

I will respond to the more philosophical parts of your message later.

I have committed changes to _transforms.* and transforms.py along the 
lines of your suggestions for a quick improvement to the ease of drawing 
with offsets.


> The best way may be for the extension code to provide a shallowcopy
> method and require derived transform classes to implement it.  All
> references will be preserved, but a new object will be created.
> 
> We only need this for SeparableTransformation and
> NonseparableTransformation but the methods will also have to be
> defined virtually in the base classes.
> 
> We have to think about what should be preserved in the shallow
> copies.  For the use case at hand, we want to preserve the references
> to the values but not the offset transform.
> 
I think I got this right--or at least as right as the existing deepcopy 
methods--but it would be good if you, or another c++ wizard, could take 
a look.  The way I have it seems to work as intended, but testing has 
been light, and I don't really know c++.  I have never written any from 
scratch, only modified existing code.

> I'm not so sure that deepcopy is really needed.  I can't think of a
> use case off hand.

I think it is needed for pickling, but I suspect that the screwiness of 
the objects that the _transforms module produces would prevent pickling 
in any case.  Other than that, I don't see any point in the deepcopy 
methods, or the corresponding (and redundant) deepcopy functions in 
transforms.py.  I marked with comments a block that I think should be 
excised from transforms.py.

The convenience function I came up with is transforms.offset_copy:

def offset_copy(trans, fig=None, x=0, y=0, units='inches'):
     '''
     Return a shallow copy of a transform with an added offset.
       args:
         trans is any transform
       kwargs:
         fig is the current figure; it can be None if units are 'dots'
         x, y give the offset in units of 'inches' or 'dots'
         units is 'inches' or 'dots'
     '''
     newtrans = trans.shallowcopy()
     if units == 'dots':
         newtrans.set_offset((x,y), identity_transform())
         return newtrans
     if not units == 'inches':
         raise ValueError('units must be dots or inches')
     if fig is None:
         raise ValueError('For units of inches a fig kwarg is needed')
     tx = Value(x) * fig.dpi
     ty = Value(y) * fig.dpi
     newtrans.set_offset((0,0), translation_transform(tx, ty))
     return newtrans



Minimal testing and illustration of the use of offsets is now in 
examples/transoffset.py.  It includes cartesian and polar coordinates.

Eric

Is it possible to add another level to the axes rc parameters, so the x and y 
axes can be controlled independently.

axes.xaxis.*
axes.yaxis.*


I am happy to add this feature if people think this is a good addition.

Cheers,
Malte.

On 7/31/06, Ken McIvor <mc...@ii...> wrote:
> On Jul 30, 2006, at 8:07 AM, Bill Baxter wrote:
> > I went ahead and implemented this yesterday on a long plane flight.
> > The changed files (backend_bases.py,  and widgets.py) are attached to
> > the above tracker entry.  Also I changed backend_wx.py to grab the
> > mouse generally when you click on the graphs, so that panning and such
> > continues to track even when you go outside the window.  Similar
> > changes should probably also be made to the other backends too.
>
> This sounds like it could be a pretty stellar improvement to the WX
> backend.  Thanks!

Just to be clear, the only thing that applies to wx specifically is
that I made the wx backend grab the system pointer on mouse down and
release it on mouse up.  (Basically just a change of 4 lines of code
-- two CaptureMouse() calls and two ReleaseMouse() calls).   The rest
is GUI independent and should benefit all GUI backends.

>
> I should be at a work-related meeting on Tuesday with Matt Newville,
> the WX backend maintainer.  I'll try to get some time set aside to
> get your changes merged on my laptop before them, so that we can
> check them out properly afterward.  My big concern is to investigate
> how these changes may affect people who are embedding WxAgg figures
> in wxPython applications.  If you've done what I think you have, that
> shouldn't be a problem.

Definitely more people should test it and review the code.  It works
for me, but maybe there are some things I haven't thought of.  Like
I've never tried embedding.  But I don't think this should cause
problems there.  On the other hand, the widget-level grabbing
infrastructure might have problems with a GUI back-end that doesn't do
system-level grabbing.  For instance you start dragging on a Slider,
drag off the window, and let go.  If you aren't doing system level
grabbing then you won't ever get the mouse up to tell you that you
should release the widget-level mouse grab.

> > I also added get_value methods to the CheckButtons and RadioButtons,
> > because it didn't seem like there was any good way to get that info.
>
> You may want to submit this portion of the changes as a separate
> patch.  I've found that my patches get accepted faster when I only do
> one thing per patch.

Ok.  Such a pain though...  Are whole files acceptable instead of
diffs?  It's relatively easy to do a windiff or whatever to look over
the changes and accept or reject line by line.   (In fact Robert
Osfield who quite ably runs the OpenSceneGraph project feels so
strongly about it that he *only* allows patches to be submitted as
complete files so he can easilly use a visual diff tool to merge
changes).

> > Finally I don't really get what the deal is with the Slider's
> > "closedmin"/"closedmax" options.
>
> Sorry, I can't help you with this one.
>
> > Please let me know if there's a better way/place to submit patches.
>
> I've always done exactly what you're doing now: uploading it on SF
> then emailing the developers' list.

Ok. Thanks.

--Bill

Hi Ken,
Thanks for the reply.

On 7/31/06, Ken McIvor <mc...@ii...> wrote:
> On Jul 24, 2006, at 9:16 PM, Bill Baxter wrote:
> > I think all these problems could be fixed if the display interface
> > were turned into a separate process that communicates with the Python
> > program using pipes or some other IPC mechanism.  I used this
> > technique in a (C/C++) image debugging utility program I wrote
> > (http://www.billbaxter.com/projects/imdebug) and it works quite well.
>
> The biggest problem I see with this approach is that matplotlib has a
> "display list" drawing model (as opposed to the "big matrix of
> pixels" model).  An example of what I mean is that when someone
> resizes a {Gtk,Tk,Wx}Agg figure, the entire plot is re-rendered from
> scratch to the new pixel dimensions.  It could be a failure of
> imagination, but I can't see how you could move the display interface
> to a subprocess without moving the rest of matplotlib along with it.
> I just can't see a clear line along which to separate out the "graph
> display server" part.

What's the problem with sending the "display list" or with having most
of matplotlib also exist in the separate process?  As long as
evaluating that display list doesn't involve making extensive
callbacks into user code, then it shouldn't be a problem.  Having
matplotlib live on both sides of the process boundary is ok in my
opinion, because it can be made to work that way.  But having to have
the *users's* app on both sides is a problem.  Or having to do so many
RPC callbacks back to users' code that a single rendering becomes
intolerably slow.

Conceptually, in terms of the "clear line", I think maybe a special
'axes' class would get you a lot of what is needed.  That would act
like a proxy for 'axes' actually living in another process.

Anyway, clearly matplotlib shouldn't always use remote display. If
you're using for embedded graphing then that would be silly.  It would
be more for general interactive use and debugging purposes.

> > Has anyone given thought to making matplotlib work in such a manner?
> > It would be hell to do in C or C++ I think, but with Python's
> > extensive RPC libs I bet it wouldn't be so bad.
>
> Python has extensive RPC libraries?!?!  ;-)

Heh, well compared to C++ at least.  :-)  My only experience with it
was with doing some very simple operations using xmlrpc.  But compared
with how hard that would have been for me to do in C++ I was
impressed.

> The point of this long-winded email is that you probably could build
> some kind of RPC system to run matplotlib remotely, but I believe it
> would be an awful lot of work.  In terms of manhours, my opinion is
> that you'd come out ahead if you just focused on debugging your
> current problems.

Ok.  It's good to know practically the best way to achieve "good
enough" but I like to think and discuss about how to achieve "best
possible", also.  :-)

Regards
--bb

On Jul 30, 2006, at 8:07 AM, Bill Baxter wrote:
> I went ahead and implemented this yesterday on a long plane flight.
> The changed files (backend_bases.py,  and widgets.py) are attached to
> the above tracker entry.  Also I changed backend_wx.py to grab the
> mouse generally when you click on the graphs, so that panning and such
> continues to track even when you go outside the window.  Similar
> changes should probably also be made to the other backends too.

This sounds like it could be a pretty stellar improvement to the WX  
backend.  Thanks!

I should be at a work-related meeting on Tuesday with Matt Newville,  
the WX backend maintainer.  I'll try to get some time set aside to  
get your changes merged on my laptop before them, so that we can  
check them out properly afterward.  My big concern is to investigate  
how these changes may affect people who are embedding WxAgg figures  
in wxPython applications.  If you've done what I think you have, that  
shouldn't be a problem.

> I also added get_value methods to the CheckButtons and RadioButtons,
> because it didn't seem like there was any good way to get that info.

You may want to submit this portion of the changes as a separate  
patch.  I've found that my patches get accepted faster when I only do  
one thing per patch.

> Finally I don't really get what the deal is with the Slider's
> "closedmin"/"closedmax" options.

Sorry, I can't help you with this one.

> Please let me know if there's a better way/place to submit patches.

I've always done exactly what you're doing now: uploading it on SF  
then emailing the developers' list.

Ken

Andrew,

This looks very cool, and I'm looking forward to playing around with  
it.  Thanks for the hard work!

Shooting from the hip, here are some initial comments.  I may be able  
to submit patches for some of the more innocuous items later in the  
week.

1. It appears that as_sizer_element() uses the _axes_sizer_elements  
dictionary to cache MplAxesSizerElement instances.  Using a  
WeakKeyDictionary from the "weakref" module instead of a regular  
dictionary may be necessary to allow the garbage collection of the  
MplAxesSizerElements when their associated Axes gets GC'd.

2. Convenience MplBoxSizer subclasses that let you omit the "orient"  
keyword might be nice:

     class MplHBoxSizer(MplBoxSizer):
         def __init__(self):
             MplBoxSizer.__init__(self, orientation='vertical')

3. Couldn't you just drop mplsizer.py into the "matplotlib.toolkits"  
virtual package?  Maybe you can't -- I'm pretty new to applied python- 
eggery.

4. I feel we should avoid the whole European/American spelling  
problem that WX has.  Why not make both 'align_centre' and  
'align_center' do the same thing?

5. Why not use shorter names, with less redundancy? (e.g.  
"matplotlib.toolkits.sizer", FigureSizer, Box, HBox, Grid, etc)

Ken

On Thu, Jul 27, 2006 at 01:33:42PM +0100, JIM MacDonald wrote:
> Another way to do it is to pass extra
> command line options to ps2pdf (-dAutoFilterColorImages=3Dfalse
> -sColorImageFilter=3DFlateEncode should do it for colour images). I
> thought embedding it in the PS file would be more flexible.

    +1 for that. I am having exactly the same problem.

--=20
    Ga=EBl

On Jul 24, 2006, at 9:16 PM, Bill Baxter wrote:
> I think all these problems could be fixed if the display interface
> were turned into a separate process that communicates with the Python
> program using pipes or some other IPC mechanism.  I used this
> technique in a (C/C++) image debugging utility program I wrote
> (http://www.billbaxter.com/projects/imdebug) and it works quite well.

The biggest problem I see with this approach is that matplotlib has a  
"display list" drawing model (as opposed to the "big matrix of  
pixels" model).  An example of what I mean is that when someone  
resizes a {Gtk,Tk,Wx}Agg figure, the entire plot is re-rendered from  
scratch to the new pixel dimensions.  It could be a failure of  
imagination, but I can't see how you could move the display interface  
to a subprocess without moving the rest of matplotlib along with it.   
I just can't see a clear line along which to separate out the "graph  
display server" part.

> Has anyone given thought to making matplotlib work in such a manner?
> It would be hell to do in C or C++ I think, but with Python's
> extensive RPC libs I bet it wouldn't be so bad.

Python has extensive RPC libraries?!?!  ;-)

In seriousness, RPC is an acknowledged weakness of Python's standard  
library.  For example, Python gives you a sockets API that is much  
nicer to use than the BSD sockets API or WinSock, but which still  
makes you worry about all of the platform-specific idiosyncrasies of  
socket programming.  It's my understanding that this is one of the  
big reasons Twisted came into being.

As another example, before Python 2.4 added the "subprocess" module,  
there was no portable way to spawn and communicate with  
subprocesses... you'd have to worry about the shell of whatever  
platform you were on mangling the commandline, you couldn't reliably  
interrupt subprocesses on win32 (no os.kill() to send a SIGINT with),  
etc.

The point of this long-winded email is that you probably could build  
some kind of RPC system to run matplotlib remotely, but I believe it  
would be an awful lot of work.  In terms of manhours, my opinion is  
that you'd come out ahead if you just focused on debugging your  
current problems.  I suspect that the matplotlib developers and  
irregular contributers like myself will more able to help with that  
debugging than we would be able to help with writing a display  
server... but please don't think that I'm speaking for everyone!

Ken

I submitted an enhancement request to the Sourceforge bug list about
grabbing behavior in the GUI-independent widgets.
http://sourceforge.net/tracker/index.php?func=detail&aid=1530104&group_id=80706&atid=560720

I went ahead and implemented this yesterday on a long plane flight.
The changed files (backend_bases.py,  and widgets.py) are attached to
the above tracker entry.  Also I changed backend_wx.py to grab the
mouse generally when you click on the graphs, so that panning and such
continues to track even when you go outside the window.  Similar
changes should probably also be made to the other backends too.

I also added get_value methods to the CheckButtons and RadioButtons,
because it didn't seem like there was any good way to get that info.

Finally I don't really get what the deal is with the Slider's
"closedmin"/"closedmax" options.   These don't seem very useful to me
(namely the =False variety).  If it meant the max was actually
max-[machine epsilon] then ok, but it's implemented as "don't set the
value if it would get set to the max" i.e. how close you get to the
max/min depends on how patient you are carefully moving the mouse to
the end of the slider.  Which is just frustrating to me.  It's hard to
make it go "as high as it will go".

Please let me know if there's a better way/place to submit patches.

--bb

On 7/30/06, Andrew Straw <str...@as...> wrote:
>  The basic
> idea is to create a layout engine for matplotlib. Not wanting to
> (re-)invent an API, I decided simply to imitate the layout engine I knew
> best, which is wxPython.

Very cool!

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> John, I think we really need copy (and maybe deepcopy)
    Eric> functions that work with all transforms, not just Separable
    Eric> transforms.  This looks fairly easy except for one thing:
    Eric> the transform creation functions return objects that don't
    Eric> provide any clean way of distinguishing among the types of
    Eric> transform.  type(trans) reports <type 'Affine'>, regardless

I've seen this, I thinki it's a problem with pycxx but am not sure

    Eric> of what kind of transform it really is.  I have not been
    Eric> able to figure out where this is coming from.  One can't
    Eric> cleanly use hasattr(funcxy) to detect a Nonseparable
    Eric> transform because all transforms have the attribute, whether
    Eric> they use it or not.  I could use "try: trans.get_funcxy()"

Again, this is a problem with pycxx.  You cannot do inheritance where
B and C inherit some methods from A unless all methods are in A, B and
C.  It's ugly but that is the way it is for now.  So I define all the
methods in the base class and raise if they are not available.
Unfortunately, pycxx is not actively developed so I doubt this will
change .

    Eric> and catch the exception, but that is ugly.  (And the second
    Eric> time I tried it, it hung ipython.)

    Eric> I suspect you have thought about this already--do you have
    Eric> any suggested solutions?  Is there at least a simple way to
    Eric> get type(trans) to work right?  From the code it looks like
    Eric> it should, so there appears to be a bug in the code or in
    Eric> cxx.

The best way may be for the extension code to provide a shallowcopy
method and require derived transform classes to implement it.  All
references will be preserved, but a new object will be created.

We only need this for SeparableTransformation and
NonseparableTransformation but the methods will also have to be
defined virtually in the base classes.

We have to think about what should be preserved in the shallow
copies.  For the use case at hand, we want to preserve the references
to the values but not the offset transform.

I'm not so sure that deepcopy is really needed.  I can't think of a
use case off hand.

As I respond, I wonder if we are applying the right solution to the
wrong problem.  I think these changes are worth doing because they are
easy and work with the existing code and are useful.  But in the
longer run, I think the offsets, while useful, can be better
accomplished by developing a transform chain as Jouni suggested.
Normal affine multiplication doesn't work since the transformations
may be nonlinear.  But we should be able to do something like (here in
python but this would probably be in the extension code)


class CompositeTransform:
    def __init__(self, transforms):
        self._transforms = transforms
    def xy_tup(self, xy):
        for transform in self._transforms:
            xy = transform.xy_tup(xy)
        return xy

Removing the offset transforms would break internal and external code,
but would probably be a cleaner solution in the long run.

JDH

John,

I think we really need copy (and maybe deepcopy) functions that work 
with all transforms, not just Separable transforms.  This looks fairly 
easy except for one thing: the transform creation functions return 
objects that don't provide any clean way of distinguishing among the 
types of transform.  type(trans) reports <type 'Affine'>, regardless of 
what kind of transform it really is.  I have not been able to figure out 
where this is coming from.  One can't cleanly use hasattr(funcxy) to 
detect a Nonseparable transform because all transforms have the 
attribute, whether they use it or not.  I could use "try: 
trans.get_funcxy()" and catch the exception, but that is ugly.  (And the 
second time I tried it, it hung ipython.)

I suspect you have thought about this already--do you have any suggested 
solutions?  Is there at least a simple way to get type(trans) to work 
right?  From the code it looks like it should, so there appears to be a 
bug in the code or in cxx.

Eric

Due to repeated emails by Eric Firing about how something like this
would be nice to have, I finally got around to packaging a little
utility I wrote. I uploaded it to the MPL source repository. The basic
idea is to create a layout engine for matplotlib. Not wanting to
(re-)invent an API, I decided simply to imitate the layout engine I knew
best, which is wxPython.

Disclaimer: This isn't bug-free, complete, or well-documented and this
announcement should merely be taken as a call to "commence hacking now".

That being said, I've used mplsizer for several figures for publication,
so I don't consider it that bad or incomplete, either.

Anyhow, the source code, licensed under the MIT license, is available at:
https://svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits/mplsizer

One note: aside from depending on matplotlib, this requires setuptools.
Sorry to those of you who hate setuptools, but it simply gives me tools
that make my life easier. If you want to change mplsizer to not require
setuptools, that's fine by me, but we should keep it setuptools compatible.

Here's the last part of the demo_basic.py script. "fig" is a matplotlib
Figure instance, "a","b","b2", and "lowest" are matplotlib Axes instances.

    # Now perform the mplsizer stuff

    import matplotlib.toolkits.mplsizer as mplsizer

    frame = mplsizer.MplSizerFrame( fig )
    sizer = mplsizer.MplBoxSizer()
    frame.SetSizer(sizer)

    sizer.Add(a,name='a',expand=1)
    sizer.Add(b,name='b',all=0,left=1,border=0.2)
    sizer.Add(b2,name='b2')

    if more_plots:
        hsizer = mplsizer.MplBoxSizer(orientation='horizontal')
        hsizer.Add(c,name='c',option=1,align_bottom=1)
        hsizer.Add(d,name='d',align_centre=1)
        sizer.Add(hsizer,all=0,bottom=1,border=0.5,expand=1,option=1)

    frame.Layout() # triggers layout

    # It's naughty to use the private attribute, but, hey, this is for
    # debugging only, so it's OK, right?
    lowest.set_position(hsizer._rect)
pylab.show()

Darren,

I don't like the default either--I just left it in place so as not to 
change too many things at once.  There is always some tension in mpl 
between doing things the Matlab way, at least by default, and doing 
things better.  If there is no opinion to the contrary, I am happy to 
change colorbar defaults for the better.  I use the "shrink" kwarg 
routinely to make the colorbar smaller; I think it should be smaller by 
default.  I generally prefer a colorbar with a length about 80% that of 
the corresponding image axis length.

What is really needed to optimize it, however, is a smarter axes packing 
algorithm.  So far, I have considered it best to at least defer this 
potentially complex change in favor of sticking with simple automatic 
behavior and the present reasonably easy manual configurability.  There 
may still be fairly simple ways to improve the default behavior, 
however, beyond picking better default parameters for the present 
algorithms.

The present algorithm divides the figure box in two, with "fraction" 
giving the fraction reserved for the colorbar.  The image axes are then 
resized and repositioned within the remainder.

One of the reasons that doing a really good job of automatic colorbar 
sizing and positioning is not trivial is that aspect ratio handling in 
the draw method determines the actual size of the image; to make the 
colorbar match that, we would have to put the colorbar sizing in the 
draw method after the image dimensions have been determined.  Probably 
this can all be done cleanly the same sort of Value magic that is used 
in transforms, but I have not tried to figure it out.  I think it would 
require setting up some sort of axes drawing order, with care taken to 
avoid circular dependencies.

So, to summarize, I don't mind doing some simple things to make colorbar 
sizing usually look nicer by default, but a more complex and complete 
solution is not high priority for me now.

Eric

Darren Dale wrote:
> I would like to ask about the behavior of colorbar(). In my opinion, the 
> default colorbar is too big. I know the default is similar to matlab's 
> colorbar, but I dont think it should stretch beyond the axes. Also, there is 
> arguably too much space between the colorbar and the right edge of the 
> figure.  I'm attaching two pngs, one is the default behavior and the other is 
> my suggested alternative, which I did with colorbar(fraction=0.0305). I don't 
> understand what fraction is scaled to. I expected fraction=1 to make the 
> height equal to the original axes height, but that actually crashes python:
> 
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  St9bad_alloc
> Aborted
> 
> I don't want to seem too critical of the work that has already been put into 
> the colorbar. I just think it needs a bit of polish. Comments?
> 
> Darren
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thursday 27 July 2006 8:33 am, JIM MacDonald wrote:
> Hi,
>
> I've just moved from MATLAB to matplotlib, and I'm really impressed
> with the quality of the PS figures it generates with usetex and the
> xpdf distiller. 

Glad to hear it.

> I've hit a couple of problems though
[...]
> The first problem I noticed is that the distilling process was causing
> some of my images to have (lossy) compression applied and others not.
> It turns out that it is a feature of ps2pdf that it tries to detect
> the content of the image and apply appropriate compression.  You can
> over ride this distiller options. My patch adds a new rc option
> ps.image_compression that can be set to auto (preserves the current
> behaviour), DCTEncode (applies lossy JPEG compression), and
> FlateEncode (lossless compression). The distiller commands are
> embedded in the ps file. I looked at making it a flag on each image,
> but couldn't get it to work. Another way to do it is to pass extra
> command line options to ps2pdf (-dAutoFilterColorImages=false
>  -sColorImageFilter=FlateEncode should do it for colour images). I
> thought embedding it in the PS file would be more flexible.

I'll look into this soon. I'm hesitant to add another rc option, maybe we can 
consider using these settings as the defaults. I'll post again after I have 
had a chance to play with it.

> My second problem involved the resolutions of the image.  I'd like to
> preserve the resolution of my image in the PS output, but I can't
> figure out how to stop the image being resized and interpolated.
> Obviously you need to do this for the bitmap backends, but for vector
> ones surely you can just scale the original image in the vector
> output.

The resolution for Postscript is 72 dpi, and I'm not sure this can be changed. 
Would you send me an example postscript file along with the original png?

Gael Varoquaux wrote:
>     Hi,
>
> 	Trying out version 0.87.4 I noticed that the example given on
> pages 
> http://matplotlib.sourceforge.net/screenshots/plotmap.py
> and
> http://scipy.org/Cookbook/Matplotlib/Maps
> fail with :
>
> In [1]: from matplotlib.toolkits.basemap import Basemap
> ---------------------------------------------------------------------------
> exceptions.ImportError                               Traceback (most
> recent call last)
>
> /home/varoquau/<ipython console>
>
> ImportError: No module named toolkits.basemap
>
>     I had a quick look and couldn't find where basemap had gone. How
> should these pages be modified ?
>
>   
Gabriel:  Basemap is a separate toolkit - it's not included in 
matplotlib.  You can get it from the matplotlib sf project page.

-Jeff

-- 
Jeffrey S. Whitaker         Phone  : (303)497-6313
Meteorologist               FAX    : (303)497-6449
NOAA/OAR/PSD  R/PSD1        Email  : Jef...@no...
325 Broadway                Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web    : http://tinyurl.com/5telg

I would like to ask about the behavior of colorbar(). In my opinion, the 
default colorbar is too big. I know the default is similar to matlab's 
colorbar, but I dont think it should stretch beyond the axes. Also, there is 
arguably too much space between the colorbar and the right edge of the 
figure.  I'm attaching two pngs, one is the default behavior and the other is 
my suggested alternative, which I did with colorbar(fraction=0.0305). I don't 
understand what fraction is scaled to. I expected fraction=1 to make the 
height equal to the original axes height, but that actually crashes python:

terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
Aborted

I don't want to seem too critical of the work that has already been put into 
the colorbar. I just think it needs a bit of polish. Comments?

Darren

Hi Stephen,
Yep, ipython is not bad, but it is not really a replacement for a real
IDE.  IPython also seems to act a little wanky with graphs to me.  For
instance my plots seem to get drawn interactively (read: very
SLOOOOOWLY) when I use the special -pylab mode.  Maybe I'm not
configuring ipython properly, but part of my point is that end users
shouldn't have to think about it, and shouldn't need some special
-pylab mode.  It should just work.  And I think it would if the
displayer's guts were in a completely separate process, acting as a
graph display server.

The only complication I can see is for callbacks from mouse and
keyboard events that occur on the graphs (but does matplotlib even
support that yet?-- I only saw it mentioned on the web page).   Those
events would still need to find their way into callbacks in the
original process.  But that's doable too, I think.  Just use a
separate thread for communication with the graph display server.  And
would perhaps be even less painful than dealing with the wx event
loop.

Anyway, it's more of a 'food for thought' suggestion than anything
else.  It's not like I'm going to have time to implement it (though it
seems like it would be a fun project if I did have the time).

I am curious as to what the current thinking is about tacking such
event loop issues, though.  Surely folks don't think that "use
ipython" is the be-all-and-end-all ultimate solution.

--bb

On 7/26/06, Stephen Walton <ste...@cs...> wrote:
> Bill Baxter wrote:
> > I think all these problems could be fixed if the display interface
> > were turned into a separate process
> Have you tried ipython?
>
> http://ipython.scipy.org/

Hi,

I've just moved from MATLAB to matplotlib, and I'm really impressed
with the quality of the PS figures it generates with usetex and the
xpdf distiller. I've hit a couple of problems though, one I've manged
to solve (patch against 0.87.4 attached) and the other I'd be greatful
if you could help me with please.

I've been using imshow to basically put a set of axes round an image
produced my simulation code. Here's a minimal version of my script:

----------------------------------------------
from pylab import *

rc('text', usetex=True)
rc('ps', usedistiller="xpdf")

figure(1,figsize=(6, 4))
im=imread('image.png') # a 301x318 image
imshow(im,interpolation='nearest',extent=[0.98, 20, 0.01, 0.5])
axis('normal');
savefig('image.eps')
--------------------------------------------

The first problem I noticed is that the distilling process was causing
some of my images to have (lossy) compression applied and others not.
It turns out that it is a feature of ps2pdf that it tries to detect
the content of the image and apply appropriate compression.  You can
over ride this distiller options. My patch adds a new rc option
ps.image_compression that can be set to auto (preserves the current
behaviour), DCTEncode (applies lossy JPEG compression), and
FlateEncode (lossless compression). The distiller commands are
embedded in the ps file. I looked at making it a flag on each image,
but couldn't get it to work. Another way to do it is to pass extra
command line options to ps2pdf (-dAutoFilterColorImages=false
 -sColorImageFilter=FlateEncode should do it for colour images). I
thought embedding it in the PS file would be more flexible.


My second problem involved the resolutions of the image.  I'd like to
preserve the resolution of my image in the PS output, but I can't
figure out how to stop the image being resized and interpolated.
Obviously you need to do this for the bitmap backends, but for vector
ones surely you can just scale the original image in the vector
output.

Thanks in advance for you help and some great software!

JIM
---

Hi all,

  I would like to enable the key pressed event (key '1'  '2'  'a'  'g' .. )
of NavigationToolbar2 in my pyGTK app.
(These keys shortcut are described here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1432252&group_id=80706&atid=560722
)
The shorcuts work perfectly using pylab. But when I include matplotlib in my
pyGTK app the shorcuts are broken.
How could I manage to make them work,
and/or,
where I should start in the source code to undestand how it work, that I
could reproduce the shorkey behavior directly in my own application code?.

Thanks,

David

Bill Baxter wrote:
> I think all these problems could be fixed if the display interface
> were turned into a separate process
Have you tried ipython?

http://ipython.scipy.org/