matplotlib-users

[Matplotlib-users] large postscript files

[<jo...@st...>]

Hi,

The following plot

>>> from numarray import *
>>> x = arange(80000)
>>> from pylab import plot,show
>>> plot(x,x)
>>> show()

and saving in postscript format generated a file of 1.5MB, while the equivalent is 
only 288KB in xmgrace (another plotting program). If I use plot(x,x,"k,"), this
even leads to a horrible 8.0MB. How come? I understand there is an issue 
with the fonts, but this can't be the only responsible, can it? Plotting no points, 
just a title, and saving in postscript leads to a file size of only 133KB.

FWIW, I'm trying to make postscript plots using Python 2.4.1, latest numarray, 
and matplotlib 0.83.2.

Cheers,
Joris



Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Matplotlib-users] large postscript files

[Bill D. <wjd...@at...>]

I cannot help you with making matplotlib create smaller files but sam2p
<http://www.inf.bme.hu/%7Epts/sam2p/> is an image conversion program
that creates small files. You might be able to convert your file to make
it smaller.

Bill

jo...@st... wrote:
> Hi,
>
> The following plot
>
>   
>>>> from numarray import *
>>>> x = arange(80000)
>>>> from pylab import plot,show
>>>> plot(x,x)
>>>> show()
>>>>         
>
> and saving in postscript format generated a file of 1.5MB, while the equivalent is 
> only 288KB in xmgrace (another plotting program). If I use plot(x,x,"k,"), this
> even leads to a horrible 8.0MB. How come? I understand there is an issue 
> with the fonts, but this can't be the only responsible, can it? Plotting no points, 
> just a title, and saving in postscript leads to a file size of only 133KB.
>
> FWIW, I'm trying to make postscript plots using Python 2.4.1, latest numarray, 
> and matplotlib 0.83.2.
>
> Cheers,
> Joris
>
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>   

Re: [Matplotlib-users] show()

[Matt <cre...@ya...>]

Is there a method of using the show() command more
than once in a script?  I know that it should be
called once all commands have been entered for the
graph, but I'm wondering if there is a way of
resetting this so that I can call show() a second time
without my program crashing.

Thanks,
Matt

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [Matplotlib-users] large postscript files

[Darren D. <dd...@co...>]

On Wednesday 06 September 2006 07:49, jo...@st... wrote:
> Hi,
>
> The following plot
>
> >>> from numarray import *
> >>> x = arange(80000)
> >>> from pylab import plot,show
> >>> plot(x,x)
> >>> show()
>
> and saving in postscript format generated a file of 1.5MB, while the
> equivalent is only 288KB in xmgrace (another plotting program). If I use
> plot(x,x,"k,"), this even leads to a horrible 8.0MB. How come? I understand
> there is an issue with the fonts, but this can't be the only responsible,
> can it? Plotting no points, just a title, and saving in postscript leads to
> a file size of only 133KB.
>
> FWIW, I'm trying to make postscript plots using Python 2.4.1, latest
> numarray, and matplotlib 0.83.2.

Each data point consists of a line like 

54.3869 28.6788 l

which is 17 bytes long. 17*80000 = 1.36MB. Maybe we dont need as many sig 
figs, that could cut the size down by maybe 25%.

Darren

Re: [Matplotlib-users] large postscript files

[John H. <jdh...@ac...>]

>>>>> "Darren" == Darren Dale <dd...@co...> writes:


    Darren> which is 17 bytes long. 17*80000 = 1.36MB. Maybe we dont
    Darren> need as many sig figs, that could cut the size down by
    Darren> maybe 25%.

We could make the fmt string for PS and SVG output floats a
configurable parameter and be done with it.  As you know, we've spent
a lot of time trying to get the right string that doesn't produce
visual errors and I'm not inclined to change the default.  But we
could make it an rc param for those who want to trade accuracy for
space.

JDH

Re: [Matplotlib-users] large postscript files

[Darren D. <dd...@co...>]

On Wednesday 06 September 2006 09:49, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
>     Darren> which is 17 bytes long. 17*80000 = 1.36MB. Maybe we dont
>     Darren> need as many sig figs, that could cut the size down by
>     Darren> maybe 25%.
>
> We could make the fmt string for PS and SVG output floats a
> configurable parameter and be done with it.  As you know, we've spent
> a lot of time trying to get the right string that doesn't produce
> visual errors and I'm not inclined to change the default.  But we
> could make it an rc param for those who want to trade accuracy for
> space.

Good idea. Should we make it a kwarg or an rc parameter? The number of rc 
parameters continues to grow...

Re: [Matplotlib-users] large postscript files

[Alan G I. <ai...@am...>]

On Wed, 6 Sep 2006, John apparently wrote:=20
> could make it an rc param for those who want to trade=20
> accuracy for space.

Does anyone really care about 25% enough to make this=20
worthwhile?  Just wondering.

Cheers,
Alan Isaac

Re: [Matplotlib-users] large postscript files

[John H. <jdh...@ac...>]

>>>>> "joris" == joris  <jo...@st...> writes:

    joris> Hi, The following plot

    >>>> from numarray import * x = arange(80000) from pylab import
    >>>> plot,show plot(x,x) show()

    joris> and saving in postscript format generated a file of 1.5MB,
    joris> while the equivalent is only 288KB in xmgrace (another
    joris> plotting program). If I use plot(x,x,"k,"), this even leads
    joris> to a horrible 8.0MB. How come? I understand there is an
    joris> issue with the fonts, but this can't be the only
    joris> responsible, can it? Plotting no points, just a title, and
    joris> saving in postscript leads to a file size of only 133KB.

    joris> FWIW, I'm trying to make postscript plots using Python
    joris> 2.4.1, latest numarray, and matplotlib 0.83.2.

matplotlib embeds the truetype fonts directly into the postscript
file, so what you see on the screen is what you get in the ps file.
This is a feature and not a bug :-).  The file size ocst is fixed and
does not grow with plot size.  If you find these largish PS files
unpalatable, you can use native postscript fonts by setting

ps.useafm         : True    # use of afm fonts, results in small files

in your matplotlibrc file -- http://matplotlib.sf.net/matplotlibrc

JDH

Re: [Matplotlib-users] large postscript files

[<hu...@ya...>]

Le mercredi 6 septembre 2006 09:49, Darren Dale a =E9crit=A0:
> On Wednesday 06 September 2006 07:49, jo...@st... wrote:
> > Hi,
> >
> > The following plot
> >
> > >>> from numarray import *
> > >>> x =3D arange(80000)
> > >>> from pylab import plot,show
> > >>> plot(x,x)
> > >>> show()
> >
> > and saving in postscript format generated a file of 1.5MB, while the
> > equivalent is only 288KB in xmgrace (another plotting program). If I use
> > plot(x,x,"k,"), this even leads to a horrible 8.0MB. How come? I
> > understand there is an issue with the fonts, but this can't be the only
> > responsible, can it? Plotting no points, just a title, and saving in
> > postscript leads to a file size of only 133KB.
> >
> > FWIW, I'm trying to make postscript plots using Python 2.4.1, latest
> > numarray, and matplotlib 0.83.2.
>
> Each data point consists of a line like
>
> 54.3869 28.6788 l
>
> which is 17 bytes long. 17*80000 =3D 1.36MB. Maybe we dont need as many s=
ig
> figs, that could cut the size down by maybe 25%.
>
> Darren

Another things that can be good to add is a better clipping. For the moment=
=20
there are no clipping that means if I have something like::


x =3D  arange(1000)
plot(x,x)
xlim(30,40)
savefig('test.svg')


All the point are stored in the file, not only the part between 30 and 40.

This is something I spoke before and I fill a bug or feature request on=20
sourceforge (I'have been unable to find it today but I looked fast).

You can check the problem with the svg created if you open it with inkscape=
,=20
you'll see all the point. I understood that this is a bug inside inkscape t=
oo=20
butthat means that all the point are there and it's a big concern for me wh=
en=20
I have to plot plenty of spectra and use only a small range because I know=
=20
that my file at the end will be huge. The only way I found is 1) save in pn=
g=20
and use another software to save it in eps but I loose the fact that eps is=
 a=20
vectoriel format 2) do the clipping myself or 3) create my plot with anothe=
r=20
software like pgplot or gnuplot.=20

Re: [Matplotlib-users] large postscript files

[John H. <jdh...@ac...>]

>>>>> "humufr" == humufr  <hu...@ya...> writes:
    humufr> Another things that can be good to add is a better
    humufr> clipping. For the moment there are no clipping that means
    humufr> if I have something like::

Here is a little demo that shows you how to do a line that clips
itself to the data view (assuming x is sorted).  It also adds a level
of detail marker when the number of points is not too large.  We used
to have this as a feature in mpl, but removed it because noone ever
used it.  We could add something like this again...


"""
Clip a line according to the current xlimits
"""

from matplotlib.lines import Line2D
import matplotlib.numerix as nx
from pylab import figure, show

class ClippedLine(Line2D):
    """
    Clip the xlimits to the axes view limits -- this example assumes x is sorted
    """

    def __init__(self, ax, *args, **kwargs):
        Line2D.__init__(self, *args, **kwargs)
        self.ax = ax


    def set_data(self, *args, **kwargs):
        Line2D.set_data(self, *args, **kwargs)
        self.xorig = nx.array(self._x)
        self.yorig = nx.array(self._y)
        
    def draw(self, renderer):
        xlim = self.ax.get_xlim()

        ind0, ind1 = nx.searchsorted(self.xorig, xlim)
        self._x = self.xorig[ind0:ind1]
        self._y = self.yorig[ind0:ind1]
        N = len(self._x)
        if N<1000:
            self._marker = 's'
            self._linestyle = '-'
        else:
            self._marker = None
            self._linestyle = '-'
        
    
        Line2D.draw(self, renderer)
        self._x = self.xorig
        self._y = self.yorig


fig = figure()
ax = fig.add_subplot(111, autoscale_on=False)

t = nx.arange(0.0, 100.0, 0.01)
s = nx.sin(2*nx.pi*t)
line = ClippedLine(ax, t, s, color='g', ls='-', lw=2)
ax.add_line(line)
ax.set_xlim(10,30)
ax.set_ylim(-1.1,1.1)
show()
        
        

Re: [Matplotlib-users] large postscript files

[Christopher B. <Chr...@no...>]

Alan G Isaac wrote:
> Does anyone really care about 25% enough to make this 
> worthwhile?  Just wondering.

I tend to think not. You put 80,000 points in a PS, it's going to be 
big. That's all there is to it, it's the nature of Postscript.

I do think clipping is a good idea though.

What is the maximum precision in Postscript? It seems unlikely that you 
could plot 80,000 points and not have number of them overlap, unless 
it's clipped, so removing essentially redundant points may be another 
way to to go.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [Matplotlib-users] large postscript files

[Joris De R. <jo...@st...>]

   [CB]: What is the maximum precision in Postscript? It seems unlikely that you 
   [CB]: could plot 80,000 points and not have number of them overlap, unless 
   [CB]: it's clipped, so removing essentially redundant points may be another 
   [CB]: way to to go.

This seems to be the way that xmgrace does it. I have been comparing
postscript output of mpl and xmgrace, and found that mpl incorporates the
fulll 80000 points while xmgrace only retains roughly 17000 of them. 

So I downloaded the xmgrace source code and tried to figure out why this is 
the case. Their postscript driver routines are in psdrv.c and are called by routines
in draw.c. Looking into the latter reveiled that they have indeed a purge_dense_points()
function, which removes the points that you wouldn't see on the plot anyway.

As far as I understand, the algorithm works as follows:

1) Define what you mean by "dense" points
    a) init what you mean by far_away 
    b) start at the first point, and loop over the points until you find one far_away
    c) hop to that one, continue looping until you find again a point far_away
    d) hop to that one, continue looping... etc  until you looped over all points
    e) count the number of hops.
        If all points turn out to be far away from each other, 'far_away'
        was too conservative -> increase far_away and repeat steps b)-e).
        In the other case: you found a definition of "dense"

2) Sift out the dense points
    Similar to 1) but only keep the points you hopped to, i.e. the ones that
    are far_away from each other.


It seems to work well for xmgrace, I never encountered any problems of too many
points purged. I do think it needs to be coded in C to work efficiently, though, i.e. 
Python would be too slow. Perhaps the mpl developers might be interested to include
it one day? The gain in postscript file size would be huge...

Cheers,
Joris

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Re: [Matplotlib-users] large postscript files

[Christopher B. <Chr...@no...>]

Joris De Ridder wrote:
> As far as I understand, the algorithm works as follows:
> 
> 1) Define what you mean by "dense" points
>     a) init what you mean by far_away 
>     b) start at the first point, and loop over the points until you find one far_away
>     c) hop to that one, continue looping until you find again a point far_away
>     d) hop to that one, continue looping... etc  until you looped over all points
>     e) count the number of hops.
>         If all points turn out to be far away from each other, 'far_away'
>         was too conservative -> increase far_away and repeat steps b)-e).
>         In the other case: you found a definition of "dense"

This is an odd way to do it. It seems to me that the only way to define 
"dense" is by resolution. What resolution do you want to be able to 
display? As PS is scalable, this isn't an easy question, but it is at 
least limited by the resolution of PS -- does PS use floating or fixed 
point, and what precision? Resolution could also be a user-settable 
property.

Another way to define resolution is by how you are drawing the points. 
If you are drawing dots at 1pt diameter, then there is no reason to plot 
two separate dots that are only 0.1pt from each-other.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer
                                     		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...