matplotlib-devel Mailing List for matplotlib

Hi,
The backend_base in the trunk now has the draw_text_as_path method
which draws the text using the textpath module. The draw_text and the
draw_tex method calls it by default. This will enable a primitive
support for text and tex for all the backend which implements
draw_path method. This should not affect the functionality of existing
backends. The draw_text_as_path in the backend_base is a very basic
implementation. It simply calls draw_path for rendering. A special
version of the draw_tex method for the svg backend is implemented,
which caches the glyph paths of characters to reduces the output size.
So, here are examples.
usetex w/ svg backend : http://dl.getdropbox.com/u/178748/mpl/tex_demo.svg
text with html5 canvas backend : http://dl.getdropbox.com/u/178748/mpl/test.html
Well, the quality of the rendered text is not best, but seems good
enough for me.
Regards,
-JJ

Hi Michael,
On Sat, Aug 29, 2009 at 9:45 AM, John Hunter <jd...@gm...> wrote:
> On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan<mcs...@uc...> wrote:
>> Here you go. If you can think of anything else to include, I'll work
>> on it. I think the next thing I'll add is something on embedding
>> images in the corners of plots. figimage is the way to do this,
>> right?
This is very nice, many thanks! If you are interested, I think that a
presentation on this would be very well received at the informal
scientific computing in python group that I coordinate at UC Berkeley:
https://cirl.berkeley.edu/view/Py4Science
I don't know how convenient it is for you to make the trip, but if
it's possible, we'd love to have you do a presentation on image
processing. Just let me know any time, it's best if you write
directly to my work address:
Fer...@be...
in case I miss a message on the mailing lists (I monitor that address
much more closely).
Cheers,
f

I was looking through this, and have a suggestion as well:
You have a line that reads
In[10]: plt.hist(lum_img)
This should probably be
plt.hist(lum_img.ravel(),bins=<some larger number>)
As it is right now, you are making a histogram of each line
individually, and my experience has been that this tends to cause
issues (memory and confusion-related) with relatively large images.
On Wed, Sep 2, 2009 at 6:42 AM, Michael Sarahan <mcs...@uc...> wrote:
> Great suggestions. I'll find time to work on them in the near future,
> hopefully.
>
> -Mike
>
> On Sat, Aug 29, 2009 at 6:06 PM, Gary Ruben<gr...@bi...> wrote:
>> Very nice addition Michael.
>>
>> I note that the plt.colormap() line must have gotten lost. It's referred to
>> but not there.
>> I'll add some ideas to John's list:
>>
>> * Demonstrate the imsave() command.
>> * Rather than show 50 lines or so of array data, just show a few lines, but
>> demonstrate what img.shape is before and after slicing out the B channel
>> with img[:,:,0]
>> * It may be worth mentioning explicitly that img[:,:,0] will give you the
>> blue channel for an RGB and an RGBA image.
>> * Demonstrate the "upper" and "lower" keywords where relevant.
>> * Add a pointer to the scipy.ndimage module
>> * Extend the examples with RGB and RGBA images.
>> * You might like to show how to recarrays and views on the individual colour
>> channels. There are examples in the mailing list archives or maybe on the
>> scipy website - I can't remember where.
>> * If you want to get more advanced, talk about higher bit depth images than
>> 8 bits per channel.
>> * If you want to get even more advanced, show how to change the UI to probe
>> the pixel value (I wish matplotlib did this by default).
>>
>> Gary R.
>>
>> John Hunter wrote:
>>>
>>> On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahan<mcs...@uc...>
>>> wrote:
>>>>
>>>> Here you go. If you can think of anything else to include, I'll work
>>>> on it. I think the next thing I'll add is something on embedding
>>>> images in the corners of plots. figimage is the way to do this,
>>>> right?
>>
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Sep 15, 2009 at 7:57 AM, Michael Droettboom <md...@st...> wrote:
> Yeah, I have the same "not quite right" feeling about it. What about
> putting the caption in an "option" such as:
>
> .. plot:: foo.py
>  :caption: This is my caption
>
> I don't know if the caption can have newlines in this mode, though. I will
> have to experiment.
Not possible, as far as I could tell. This was my first reflex and
all of my experiments ended losing the other lines, and I couldn't
find by searching the lists whether there was any way to do it. But I
admit I didn't go as far as asking on the docutils or sphinx lists.
> It's not possible now. The tricky part of this is that currently we don't
> keep the module around after it's done plotting. This is actually very much
> on purpose since keeping all that data around for all of the example plots
> in the matplotlib documentation would quickly consume a lot of memory.
> Perhaps when used in this mode (with a function argument) we could. Alas,
> again that's api-by-inputs :)
Well, even if the module isn't kept in memory, from an api perspective
I think it would still be useful to have this
.. plot:: script.py func
mode. It would make it easier to organize scripts for plot generation
in papers.
But don't worry too much about it. The real problem was having
figures with captions, and at least we have that done. Hopefully some
time in the future these extensions can be cleaned up a little bit
(the code is indeed a bit messy).
In the meantime, we have something very useful that we need *today*,
so I'm happy :)
Cheers,
f

Fernando Perez wrote:
> Hi Michael,
>
> On Mon, Sep 14, 2009 at 6:57 AM, Michael Droettboom <md...@st...> wrote:
> 
>> I'm not sure it's that bad. It's certainly possible to do all these things
>> with a single directive, since providing a path or providing source code is
>> mutually exclusive. The thing one can't do is provide inline source *and* a
>> caption. I applied your patch, renaming the directive back to "plot" and
>> ran it over the matplotlib docs, and it doesn't seem to break anything.
>> 
>
> Well, if you're OK with the api-by-inputs approach (name+text =
> caption, text only=code), then I have no qualms using it. It felt a
> bit hackish so I was perhaps overly cautious, but I'd much rather:
>
> - have this in upstream mpl than in my own projects
> - have a single directive to remember
>
> So many thanks for integrating it!
> 
Yeah, I have the same "not quite right" feeling about it. What about 
putting the caption in an "option" such as:
 .. plot:: foo.py
 :caption: This is my caption
I don't know if the caption can have newlines in this mode, though. I 
will have to experiment.
>> Of course, we can also provide two directives, "plot" and "figplot" based on
>> essentially the same source code. I'm kind of neutral on the matter.
>> 
>
> I'm pretty neutral too, though perhaps it might be worth thinking
> about this a little more, to get a really good long-term solution.
> 
> 2. An extended version of today's support for files, that can handle
> entry points:
>
> .. plot:: script.py func1
>
> Caption for figure 1
>
> .. plot:: script.py func2
>
> Caption for figure 2
>
> This would *import* script only once, and then for each figure it
> would call the given function (argumentless, to keep things simple for
> now). Basically each call would be the equivalent of
>
> import script; script.funcN() # N=1,2
>
> This would make it easy to compute expensive data in script once, and
> then render multiple plots out of it without re-executing the script
> in full each time.
>
> Or is this already possible with today's plot()?
> 
It's not possible now. The tricky part of this is that currently we 
don't keep the module around after it's done plotting. This is actually 
very much on purpose since keeping all that data around for all of the 
example plots in the matplotlib documentation would quickly consume a 
lot of memory. Perhaps when used in this mode (with a function 
argument) we could. Alas, again that's api-by-inputs :)
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi Michael,
On Mon, Sep 14, 2009 at 6:57 AM, Michael Droettboom <md...@st...> wrote:
> I'm not sure it's that bad. It's certainly possible to do all these things
> with a single directive, since providing a path or providing source code is
> mutually exclusive. The thing one can't do is provide inline source *and* a
> caption. I applied your patch, renaming the directive back to "plot" and
> ran it over the matplotlib docs, and it doesn't seem to break anything.
Well, if you're OK with the api-by-inputs approach (name+text =
caption, text only=code), then I have no qualms using it. It felt a
bit hackish so I was perhaps overly cautious, but I'd much rather:
- have this in upstream mpl than in my own projects
- have a single directive to remember
So many thanks for integrating it!
> Of course, we can also provide two directives, "plot" and "figplot" based on
> essentially the same source code. I'm kind of neutral on the matter.
I'm pretty neutral too, though perhaps it might be worth thinking
about this a little more, to get a really good long-term solution.
Basically, what I'd like to have is a directive that can cover these
two scenarios:
1. Like today, plot with code:
.. plot::
 plot(x,y)
2. An extended version of today's support for files, that can handle
entry points:
.. plot:: script.py func1
 Caption for figure 1
.. plot:: script.py func2
 Caption for figure 2
This would *import* script only once, and then for each figure it
would call the given function (argumentless, to keep things simple for
now). Basically each call would be the equivalent of
import script; script.funcN() # N=1,2
This would make it easy to compute expensive data in script once, and
then render multiple plots out of it without re-executing the script
in full each time.
Or is this already possible with today's plot()?
I think this would cover all the use cases I have in mind, from years
of using a similar approach but with Makefiles.
Cheers,
f