Re: Rasterized artists have wrong transform

On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <efiring@...> wrote:
> Jae-Joon Lee wrote:
>>
>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eric.bruning@...>
>> wrote:
>>>
>>> I like that this solution doesn't litter every call to draw with
>>> rasterize checks. But it means that the rasterization support had
>>> better be robust, since Artist authors might not know they're
>>> interacting with the rasterization code. It has the downside of being
>>> implicit rather than explicit.
>>
>> Eric,
>> I think we'd better stick to your decorator solution.
>>
>> Anyhow, I thought you had a svn commit permission but it seems not. Do
>> you (and other dwevelopers) mind if I commit this patch to the trunk?
>
> It would be especially good for John and Mike to have a look.
>
> As a matter of style, I suggest a name change. "@hook_before_after_draw" is
> too generic, and brings to mind discussions a long time ago about possibly
> adding a general hook mechanism; even before rasterization, and before
> decorators were available, there were thoughts that we might need this.
>  (Now I don't remember what the motivation was, but I think it had to do
> with coordinating different elements of a plot.)  In any case, the decorator
> is actually very specific to rasterization, so maybe call it
> "@with_rasterization"  or "@allow_rasterization".
>
> I am very anxious to see rasterization support in place; let's just be sure

Re: [Matplotlib-users] fill_between

On Thu, Apr 30, 2009 at 3:55 PM, T J <tjhnson@...> wrote:
> On Thu, Apr 30, 2009 at 2:29 PM, John Hunter <jdh2358@...> wrote:
>>
>>
>> On Thu, Apr 30, 2009 at 4:14 PM, T J <tjhnson@...> wrote:
>>>
>>> Fill between is for filling between two y-values over a range of
>>> x-values.  Is there anything which fills between to x-values over a
>>> range of y-values?
>>
>> Nothing with the ease of use of fill_between, but you can always write your
>> own PolyCollection, which is what fill_between does (see the function
>> implementation for details) or create a Polygon for a simple region.  My use
>> cases are typically in the time series world where I have datetime on the
>> x-axis and some range of values on the y.  If folks think it is sufficiently
>> useful to have a fill_betweenx function with a similar interface, you could
>> probably fairly easy port fill_between to fill_betweenx.
>>
>>   http://matplotlib.sourceforge.net/faq/howto_faq.html#contributing-howto
>>
>
> Done.  Attached diff is against rev7075.
>

I've added the patch to the tracker.

http://sourceforge.net/tracker/?func=detail&aid=2786759&group_id=80706&atid=560722

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 

Re: [Matplotlib-users] fill_between

On Mon, May 4, 2009 at 12:53 PM, T J <tjhnson@...> wrote:

> I've added the patch to the tracker.
>
> http://sourceforge.net/tracker/?func=detail&aid=2786759&group_id=80706&atid=560722

Thanks -- looks good.  I've committed it to r7079

JDH

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf

Re: Rasterized artists have wrong transform

I'm attaching a slightly modified version of the patch, originally by
Eric Bruning.
I changed the name to "allow_rasterization", and added some code to
check if the draw method is decorated when set_rasterized is called
(I'll be glad to hear any better idea for this).

The second patch is to let you use MixedModeRenderer when saving ps
output, i.e., rasterzation for ps backend. The rasterization per
artist is not that useful for ps backend as it does not support alpha
compositions. However, I introduced *rasterization_zorder* attributes
in Axes class, and slightly modified its draw method so that all the
artists whose zorder is below *rasterization_zorder* will be
rasterized (to a single image). My main use case for this is to have
transparent (but rasterized) contour lines or texts overlayed on top
of a background  image (for PS backend). Take a look at the example
script I added (examples/misc/rasterization_demo.py).

Any comment or suggestion will be welcomed.
I'm planning to commit this change to the svn soon, unless others come
up with some issues.

Regards,

-JJ

On Mon, May 4, 2009 at 10:05 AM, Eric Bruning <eric.bruning@...> wrote:
> On Wed, Apr 29, 2009 at 4:17 PM, Eric Firing <efiring@...> wrote:
>> Jae-Joon Lee wrote:
>>>
>>> On Sun, Apr 26, 2009 at 11:31 PM, Eric Bruning <eric.bruning@...>

Re: Rasterized artists have wrong transform

On Tue, May 5, 2009 at 1:08 PM, Jae-Joon Lee <lee.j.joon@...> wrote:

> Any comment or suggestion will be welcomed.
> I'm planning to commit this change to the svn soon, unless others come
> up with some issues.

I am getting the following error when I test on svn HEAD

johnh <at> flag:misc> python rasterization_demo.py
Traceback (most recent call last):
  File "rasterization_demo.py", line 49, in ?
    plt.savefig("test_reasterization.eps", dpi=150)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/pyplot.py",
line 354, in savefig
    return fig.savefig(*args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/figure.py",
line 1002, in savefig
    self.canvas.print_figure(*args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py",
line 1467, in print_figure
    bbox_inches_restore=_bbox_inches_restore,
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backend_bases.py",
line 1321, in print_eps
    return ps.print_eps(*args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 847, in print_eps
    return self._print_ps(outfile, 'eps', *args, **kwargs)
  File "/home/titan/johnh/dev/lib/python2.4/site-packages/matplotlib/backends/backend_ps.py",
line 879, in _print_ps
    orientation, isLandscape, papertype,

Re: Rasterized artists have wrong transform

Thanks John,

Sorry for the buggy patch. The error occurs when usetex=False and
ps.useafm=False, which was not my setup.
Here is a patch to fix it.

--- lib/matplotlib/backends/backend_ps.py.orig  2009-05-05
14:44:31.000000000 -0400
+++ lib/matplotlib/backends/backend_ps.py       2009-05-05
14:44:36.000000000 -0400
@@ -993,7 +993,7 @@
         Ndict = len(psDefs)
         print >>fh, "%%BeginProlog"
         if not rcParams['ps.useafm']:
-            Ndict += len(renderer.used_characters)
+            Ndict += len(ps_renderer.used_characters)
         print >>fh, "/mpldict %d dict def"%Ndict
         print >>fh, "mpldict begin"
         for d in psDefs:
@@ -1001,7 +1001,7 @@
             for l in d.split('\n'):
                 print >>fh, l.strip()
         if not rcParams['ps.useafm']:
-            for font_filename, chars in renderer.used_characters.values():
+            for font_filename, chars in ps_renderer.used_characters.values():
                 if len(chars):
                     font = FT2Font(font_filename)
                     cmap = font.get_charmap()

> If we take the time upfront to be consistent, any search replace

Re: Rasterized artists have wrong transform

To avoid confusion, how about renaming draw_wrapper._rasterized to
draw_wrapper._supports_rasterization ?

This helps to distinguish from artist._rasterized, which has a
different purpose.

The lack of consistency in decoration language for different artists
is my fault. It reflects the different ways the base artist module is
imported for the subclasses of artist.

Thanks,
Eric

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

Re: Rasterized artists have wrong transform

I'm attaching the revised patch (I may split the patch for commit).

Regards,

-JJ

On Tue, May 5, 2009 at 3:22 PM, Eric Bruning <eric.bruning@...> wrote:
> To avoid confusion, how about renaming draw_wrapper._rasterized to
> draw_wrapper._supports_rasterization ?
>
> This helps to distinguish from artist._rasterized, which has a
> different purpose.
>
> The lack of consistency in decoration language for different artists
> is my fault. It reflects the different ways the base artist module is
> imported for the subclasses of artist.
>
> Thanks,
> Eric
>

Index: lib/matplotlib/legend.py
===================================================================
--- lib/matplotlib/legend.py	(revision 7085)
+++ lib/matplotlib/legend.py	(working copy)
@@ -26,7 +26,7 @@
 import numpy as np

 from matplotlib import rcParams

Re: Rasterized artists have wrong transform

On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee.j.joon@...> wrote:
> I'm attaching the revised patch (I may split the patch for commit).

Still encountering troubles ....

johnh <at> flag:misc> python rasterization_demo.py
Traceback (most recent call last):
  File "rasterization_demo.py", line 41, in ?
    ax4.set_rasterization_zorder(-10)
AttributeError: 'AxesSubplot' object has no attribute 'set_rasterization_zorder'

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

Re: Rasterized artists have wrong transform

On Tue, May 5, 2009 at 2:52 PM, John Hunter <jdh2358@...> wrote:
> On Tue, May 5, 2009 at 2:49 PM, Jae-Joon Lee <lee.j.joon@...> wrote:
>> I'm attaching the revised patch (I may split the patch for commit).
>
> Still encountering troubles ....

Oops, ignore me.  Looks like I just reapplied the *old* patch that was
laying around.  Give me a few minutes to test....

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com