matplotlib-users Mailing List for matplotlib

Satish Raghunath wrote:
> Hi, 
> I am using a simulator called aerialvision which uses matplot . I 
> installed matplot on my Linux machine and now I use the simulator it 
> gives me an error stating that 
> 
> File 
> "/usr/local/lib/python2.7/site-packages/matplotlib/backends/tkagg.py", 
> line 1, in <module>
> import _tkagg
> ImportError: No module named _tkagg
> 
> Can anyone please help me with this 
> 
> Thanks! 
> satish 
> 
> 
You probably didn't have the tk development packages when you installed 
mpl. Install them and re-install mpl checking that it correctly detects 
that tk is installed.
JLS

Hi,
 I am using a simulator called aerialvision which uses matplot . I
installed matplot on my Linux machine and now I use the simulator it gives
me an error stating that
File "/usr/local/lib/python2.7/site-packages/matplotlib/backends/tkagg.py",
line 1, in <module>
 import _tkagg
ImportError: No module named _tkagg
Can anyone please help me with this
Thanks!
satish

j vickroy wrote:
> Thanks much for this information and also for taking the additional time 
> to try the optipng tool. It is very helpful.
> 
> Since the above mentioned PNG generation is one step in a "near" 
> real-time products generation system, I was hoping to avoid the addition 
> of another component (i.e., PNG compression) in the stream, but it 
> appears unavoidable.
yes, but you can build it into your python script. I'm sorry I don't 
have time to write a sample for you, but:
You can get the RGBA buffer from MPL
You can convert that to a PIL RGBA image.
You can use PIL's "quantize" method to make a palletted image.
You can save that palleted image as a PNG.
I think that will all run pretty fast.
By the way, I'm pretty sure there are a few functions in MPL already 
that use PIL if it is installed -- so if you get this working, it may be 
worth adding to MPL -- or maybe not, it's pretty specialized.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I've traced this back to revision 7867:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/axes.py?r1=7867&r2=7866&pathrev=7867 
<http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/axes.py?r1=7867&r2=7866&pathrev=7867>
Andrew: I'm sure that change is there for a good reason -- do you 
remember what it was? I don't just want to revert it. Interestingly, 
get_clip_on() is True by default, and I'm not sure in what case it's set 
to False in this context.
Mike
On 07/23/2010 03:36 AM, Tobias Winchen wrote:
> Hi,
>
> 
>> On Thursday 22 July 2010 Michael Droettboom wrote:
>> Which backend are you using?
>> 
> I tried this with GTKAgg and Qt4Agg, its was working with 0.99.0 and 0.99.1 on
> Debian/Squeeze and 0.99.0 on Scientific Linux 5. I first noticed this with
> 0.99.3 on Debian/Squeeze, but it is the same with with 1.0.0 on Debian/Squeeze
> and Scientific Linux 5.
>
> 
>> Can you provide a short script that
>> reproduces the bug?
>> 
> This script reproduces the behaviour:
>
>
> import pylab
> from math import *
>
> d = [[1,2],[3,4]]
>
> f = pylab.figure()
> pylab.subplot(111, projection='hammer')
>
> pylab.imshow(d, extent=(-pi,pi,-pi/2,pi/2))
> f.show()
>
>
> It creates the following plot in version 0.99.0
> http://web.physik.rwth-aachen.de/~winchen/mpl_0990.png
>
> and in version 0.99.3
> http://web.physik.rwth-aachen.de/~winchen/mpl_0993.png
>
> Best regards,
>
>
> Tobias
> 
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 7/23/10 3:16 PM, Michael Droettboom wrote:
> I've traced this back to revision 7867:
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/axes.py?r1=7867&r2=7866&pathrev=7867 
> <http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/axes.py?r1=7867&r2=7866&pathrev=7867>
>
> Andrew: I'm sure that change is there for a good reason -- do you 
> remember what it was? I don't just want to revert it. Interestingly, 
> get_clip_on() is True by default, and I'm not sure in what case it's 
> set to False in this context.
Hi Mike,
I don't remember this. But looking back at the commit logs, I see 
"imshow: only apply axes patch clipping if image doesn't clip itself" as 
the original commit message and then a few minutes later I committed the 
test test_imshow_clip() in text_axes.py. It looks like I was responding 
to a bug and/or patch submission. As long as that test still passes, I 
think it's OK to check in your fix. We could also add Tobias' script as 
another test.
-Andrew

On Fri, Jul 23, 2010 at 3:18 AM, aliko <ali...@gm...> wrote:
> Although the curves now are fitting in the box, the axes data does not
> updated and freezes at some initial values. I'm also reworked example in
> order to use two Y axises one to the left and one at the right. And the
> second plot attached to the right axis is not autoscaled as the first
> does. Those the two things stops me now.
> Any suggestions is highly appreciated!
>
> # -*- coding: utf-8 -*-
> """
> Created on Fri Jul 23 10:53:59 2010
>
> @author: ali
> """
>
> import sys
>
> from matplotlib.figure import Figure
> from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as
> FigureCanvas
>
> from PyQt4 import QtGui
>
> import numpy as np
> import time
>
> ITERS = 1000
>
> class BlitQT(FigureCanvas):
> def __init__(self):
> FigureCanvas.__init__(self, Figure())
> self.figure.subplots_adjust(right=0.75)
>
> self.ax1 = self.figure.add_subplot(111)
> self.ax1.set_ylabel("Func1")
> self.ax2 = self.ax1.twinx()
> self.ax2.set_ylabel("Func2")
>
> self.ax1.grid()
> self.draw()
>
> self.ax1_background = self.copy_from_bbox(self.ax1.bbox)
> self.ax2_background = self.copy_from_bbox(self.ax2.bbox)
> self.cnt = 0
>
> self.x = np.arange(0,2*np.pi,0.01)
> self.line1, = self.ax1.plot(self.x, np.sin(self.x), 'b',
> animated=True)
> self.line2, = self.ax2.plot(self.x, np.cos(self.x), 'r',
> animated=True)
>
> self.tstart = time.time()
> self.startTimer(10)
>
>
> def timerEvent(self, evt):
> y1 = self.x * np.sin(self.x+self.cnt/10.0)
> y2 = np.cos(self.x+self.cnt/10.0) / self.x
> self.ax1.set_ylim(y1.min(), y1.max())
> self.ax2.set_ylim(y2.min(), y2.max())
> self.restore_region(self.ax1_background, bbox=self.ax1.bbox)
> # self.restore_region(self.ax2_background, bbox=self.ax2.bbox)
>
> # update the data
> self.line1.set_ydata(y1)
> self.line2.set_ydata(y2)
> # just draw the animated artist
> self.ax1.draw_artist(self.line1)
> self.ax2.draw_artist(self.line2)
> # just redraw the axes rectangle
> # self.blit(self.ax1.bbox)
> self.blit(self.ax2.bbox)
>
> if self.cnt == 0:
> self.draw()
> if self.cnt==ITERS:
> # print the timing info and quit
> print 'FPS:' , ITERS/(time.time()-self.tstart)
> sys.exit()
> else:
> self.cnt += 1
>
> app = QtGui.QApplication(sys.argv)
> widget = BlitQT()
> widget.show()
>
> sys.exit(app.exec_())
>
>
aliko,
By doing the plot() call at every iteration of the loop, you are causing
conflicts with the blitting code, which is the source of the slowness. You
need to remove the plot() calls you added and move the set_ylim() call to
*before* "self.ax1_background = self.copy_from_bbox(self.ax1.bbox)".
Actually, it probably should also be before the call to "self.draw()".
Here is why. When you create an axes, but have not yet plotted any data,
the limits aren't known. When you copy the background, it is copying
whatever it knows at that time -- which is that it does *not* know the
limits. Then, each call to "restore_region()" restores that information --
including the fact that it doesn't know the limits.
Therefore, if you set the limits *before* drawing the background and copying
it, then restore_region() will then know the proper axes limits and handle
it correctly.
I hope this makes more sense.
Ben Root

BTW -- I think a possible fix may be to do:
 if not im.get_clip_path():
 im.set_clip_path(self.patch)
Mike
On 07/23/2010 09:16 AM, Michael Droettboom wrote:
> I've traced this back to revision 7867:
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/axes.py?r1=7867&r2=7866&pathrev=7867 
> <http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/axes.py?r1=7867&r2=7866&pathrev=7867>
>
> Andrew: I'm sure that change is there for a good reason -- do you 
> remember what it was? I don't just want to revert it. Interestingly, 
> get_clip_on() is True by default, and I'm not sure in what case it's 
> set to False in this context.
>
> Mike
>
> On 07/23/2010 03:36 AM, Tobias Winchen wrote:
>> Hi,
>>
>> 
>>> On Thursday 22 July 2010 Michael Droettboom wrote:
>>> Which backend are you using?
>>> 
>> I tried this with GTKAgg and Qt4Agg, its was working with 0.99.0 and 0.99.1 on
>> Debian/Squeeze and 0.99.0 on Scientific Linux 5. I first noticed this with
>> 0.99.3 on Debian/Squeeze, but it is the same with with 1.0.0 on Debian/Squeeze
>> and Scientific Linux 5.
>>
>> 
>>> Can you provide a short script that
>>> reproduces the bug?
>>> 
>> This script reproduces the behaviour:
>>
>>
>> import pylab
>> from math import *
>>
>> d = [[1,2],[3,4]]
>>
>> f = pylab.figure()
>> pylab.subplot(111, projection='hammer')
>>
>> pylab.imshow(d, extent=(-pi,pi,-pi/2,pi/2))
>> f.show()
>>
>>
>> It creates the following plot in version 0.99.0
>> http://web.physik.rwth-aachen.de/~winchen/mpl_0990.png
>>
>> and in version 0.99.3
>> http://web.physik.rwth-aachen.de/~winchen/mpl_0993.png
>>
>> Best regards,
>>
>>
>> Tobias
>> 
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first --http://p.sf.net/sfu/sprint-com-first
>>
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>> 
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

 I solved the problem and I'm going to explain the solution I used, it 
can be useful for someone.
y data for each series are contained into 2 different arrays, say y1 and 
y2.
The code is the sequent:
if max(y1) > max(y2):
 y_max = max(y1)
else:
 y_max = max(y2)
if min(y1) < min(y2):
 y_min= min(y1)
else:
 y_min = min(y2)
y_upper_limit = y_max+ y_max/10 # to leave some blank space on 
the top
y_lower_limit = y_min + y_min/10 # to leave some blank space on 
the bottom
Then, in your plot, you set ylim(y_lower_limit, y_upper_limit) and 
that's it.
This solution is good because it doesn't depend on the order of 
magnitude of the processed data, while specifying axes manually can give 
some problems for very different data sets.
I hope this message is correctly sent to the mailing list, the procedure 
for answering a message is not so immediate in my opinion.
Then, I subscribed the mailing list, so from the following messages (I 
have some other problems) I will use a different e-mail address.
Bye :)
Il 20/07/2010 22:28, Benjamin Root ha scritto:
> Somehow, this doesn't seem very satisfying. It is almost accidental. 
> There has to be a better way to do this.
>
> Ben Root
>
> 2010年7月20日 Thøger Emil Juul Thorsen <th...@fy... 
> <mailto:th...@fy...>>
>
> One way is to specify the axes manually, e.g. setting:
>
> (with matyplotlib.pyplot importad as plt:)
>
> plt.axis([200, 500, -600, 600])
>
> ...or whatever seems fitting for you, and do that on both of the y
> axes.
> That should align them nicely.
>
> On Sat, 2010年07月17日 at 20:37 +0200, Daniele Padula wrote:
> > Hi everybody,
> > I have a problem with a plot. I attach a figure to be easily
> understandable.
> >
> > As you can see from the figure, I have in the same area a line
> and a bar
> > plot. The problem is that y=0 for right y axis is different with
> respect
> > to left y axis one. I want the two y=0 to be the same.
> >
> > How can i do that?
> >
> > Excuse me for my bad english, I'm italian :)
> >
> > Thanks in advance.
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first <http://sprint.com/first> --
> http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________ Matplotlib-users
> mailing list Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first <http://sprint.com/first> --
> http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Eric Firing wrote:
>>> You can post-process the image with something like ImageMagick.
>>>
>>> Another alternative is to use PIL -- you can grab the matplotlib buffer,
>>> make a PIL image out of it, and use PIL to convert to an 8-bit palleted
>>> image.
>>>
>>> For that matter, you could probably bypass MPL, and use numpy to create
>>> the 8-bit image you want, and PIL to save it as a PNG.
>>>
>>> -Chris
>>>
>>> Thanks much for the helpful information. I will revisit PIL; I tried matplotlib because of other requirements (colorbar, various figure annotations) which did not appear to be readily available in PIL. At this stage, it depends on how important the requirement is to reduce the size of the PNG images.
>>>
>>> 
>> -- jv
>> 
>
> Try optipng:
>
> http://optipng.sourceforge.net/
>
> Here I am running it on a gray-scale image created by mpl; it was 
> generated in such a way that there are only 100 distinct shades of gray.
> You can see that it reduces the file size by quite a bit, converting it 
> from RGBA to grayscale. This is lossless. For this to work, you have 
> to make sure you have no more than 256 distinct colors--they don't have 
> to be gray.
>
> -rw-rw-r-- 1 efiring efiring 8458 2010年07月22日 16:26 grayfig.png
> efiring@manini:~$ optipng grayfig.png
> OptiPNG 0.6.3: Advanced PNG optimizer.
> Copyright (C) 2001-2009 Cosmin Truta.
>
> ** Processing: grayfig.png
> 800x600 pixels, 4x8 bits/pixel, RGB+alpha
> Reducing image to 8 bits/pixel, grayscale
> Input IDAT size = 8352 bytes
> Input file size = 8458 bytes
>
> Trying:
> zc = 9 zm = 8 zs = 0 f = 0		IDAT size = 3721
> zc = 9 zm = 8 zs = 0 f = 5		IDAT size = 3301
> zc = 9 zm = 8 zs = 1 f = 5		IDAT size = 3286
>
> Selecting parameters:
> zc = 9 zm = 8 zs = 1 f = 5		IDAT size = 3286
>
> Output IDAT size = 3286 bytes (5066 bytes decrease)
> Output file size = 3377 bytes (5081 bytes = 60.07% decrease)
>
> efiring@manini:~$ ll grayfig.png
> -rw-rw-r-- 1 efiring efiring 3377 2010年07月22日 16:26 grayfig.png
>
>
> Eric
>
> ------------------------------------------------------------------------------
> 
Thanks much for this information and also for taking the additional time 
to try the optipng tool. It is very helpful.
Since the above mentioned PNG generation is one step in a "near" 
real-time products generation system, I was hoping to avoid the addition 
of another component (i.e., PNG compression) in the stream, but it 
appears unavoidable.
-- jv

Although the curves now are fitting in the box, the axes data does not 
updated and freezes at some initial values. I'm also reworked example in 
order to use two Y axises one to the left and one at the right. And the 
second plot attached to the right axis is not autoscaled as the first 
does. Those the two things stops me now.
Any suggestions is highly appreciated!
# -*- coding: utf-8 -*-
"""
Created on Fri Jul 23 10:53:59 2010
@author: ali
"""
import sys
from matplotlib.figure import Figure
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as 
FigureCanvas
from PyQt4 import QtGui
import numpy as np
import time
ITERS = 1000
class BlitQT(FigureCanvas):
 def __init__(self):
 FigureCanvas.__init__(self, Figure())
 self.figure.subplots_adjust(right=0.75)
 self.ax1 = self.figure.add_subplot(111)
 self.ax1.set_ylabel("Func1")
 self.ax2 = self.ax1.twinx()
 self.ax2.set_ylabel("Func2")
 self.ax1.grid()
 self.draw()
 self.ax1_background = self.copy_from_bbox(self.ax1.bbox)
 self.ax2_background = self.copy_from_bbox(self.ax2.bbox)
 self.cnt = 0
 self.x = np.arange(0,2*np.pi,0.01)
 self.line1, = self.ax1.plot(self.x, np.sin(self.x), 'b', 
animated=True)
 self.line2, = self.ax2.plot(self.x, np.cos(self.x), 'r', 
animated=True)
 self.tstart = time.time()
 self.startTimer(10)
 def timerEvent(self, evt):
 y1 = self.x * np.sin(self.x+self.cnt/10.0)
 y2 = np.cos(self.x+self.cnt/10.0) / self.x
 self.ax1.set_ylim(y1.min(), y1.max())
 self.ax2.set_ylim(y2.min(), y2.max())
 self.restore_region(self.ax1_background, bbox=self.ax1.bbox)
# self.restore_region(self.ax2_background, bbox=self.ax2.bbox)
 # update the data
 self.line1.set_ydata(y1)
 self.line2.set_ydata(y2)
 # just draw the animated artist
 self.ax1.draw_artist(self.line1)
 self.ax2.draw_artist(self.line2)
 # just redraw the axes rectangle
# self.blit(self.ax1.bbox)
 self.blit(self.ax2.bbox)
 if self.cnt == 0:
 self.draw()
 if self.cnt==ITERS:
 # print the timing info and quit
 print 'FPS:' , ITERS/(time.time()-self.tstart)
 sys.exit()
 else:
 self.cnt += 1
app = QtGui.QApplication(sys.argv)
widget = BlitQT()
widget.show()
sys.exit(app.exec_())

Hi,
> On Thursday 22 July 2010 Michael Droettboom wrote:
> Which backend are you using? 
I tried this with GTKAgg and Qt4Agg, its was working with 0.99.0 and 0.99.1 on
Debian/Squeeze and 0.99.0 on Scientific Linux 5. I first noticed this with 
0.99.3 on Debian/Squeeze, but it is the same with with 1.0.0 on Debian/Squeeze 
and Scientific Linux 5.
> Can you provide a short script that
> reproduces the bug?
This script reproduces the behaviour:
import pylab 
from math import *
d = [[1,2],[3,4]]
f = pylab.figure()
pylab.subplot(111, projection='hammer')
pylab.imshow(d, extent=(-pi,pi,-pi/2,pi/2))
f.show()
It creates the following plot in version 0.99.0
http://web.physik.rwth-aachen.de/~winchen/mpl_0990.png
and in version 0.99.3
http://web.physik.rwth-aachen.de/~winchen/mpl_0993.png
Best regards,
Tobias

> The problem here is probably with the blitting. You make a copy of the 
> background before plotting the data. Before you plot the data, the axes 
> have no clue what's its limits are supposed to be. In your example, it 
> won't know until you do the plotting. Then when you restore the 
> background, it is restoring the background that never knew the limits.
> 
> I suggest calling ax.set_xlim() and ax.set_ylim() before doing the 
> copy_from_bbox().
> 
> I hope that helps,
> Ben Root
> 
> 
Thank you very much Ben Root for your prompt response and valuable 
assistance! Now I can set the limits using set_ylim. I call it just 
before self.restore_region(...). But I should calculate limits myself in 
order to provide them to that function.
In my case it looks like this:
y1 = np.sin(self.x+self.cnt/10.0)
y2 = (self.x+self.cnt)/50.0
self.ax.set_ylim(min(y1.min(), y2.min()), max(y1.max(), y2.max()))
another way I've discovered is to call plot() function in every step. 
But this approach is little slowly the difference is about 5%.

>> You can post-process the image with something like ImageMagick.
>>
>> Another alternative is to use PIL -- you can grab the matplotlib buffer,
>> make a PIL image out of it, and use PIL to convert to an 8-bit palleted
>> image.
>>
>> For that matter, you could probably bypass MPL, and use numpy to create
>> the 8-bit image you want, and PIL to save it as a PNG.
>>
>> -Chris
>>
>> Thanks much for the helpful information. I will revisit PIL; I tried matplotlib because of other requirements (colorbar, various figure annotations) which did not appear to be readily available in PIL. At this stage, it depends on how important the requirement is to reduce the size of the PNG images.
>>
> -- jv
Try optipng:
http://optipng.sourceforge.net/
Here I am running it on a gray-scale image created by mpl; it was 
generated in such a way that there are only 100 distinct shades of gray.
You can see that it reduces the file size by quite a bit, converting it 
from RGBA to grayscale. This is lossless. For this to work, you have 
to make sure you have no more than 256 distinct colors--they don't have 
to be gray.
-rw-rw-r-- 1 efiring efiring 8458 2010年07月22日 16:26 grayfig.png
efiring@manini:~$ optipng grayfig.png
OptiPNG 0.6.3: Advanced PNG optimizer.
Copyright (C) 2001-2009 Cosmin Truta.
** Processing: grayfig.png
800x600 pixels, 4x8 bits/pixel, RGB+alpha
Reducing image to 8 bits/pixel, grayscale
Input IDAT size = 8352 bytes
Input file size = 8458 bytes
Trying:
 zc = 9 zm = 8 zs = 0 f = 0		IDAT size = 3721
 zc = 9 zm = 8 zs = 0 f = 5		IDAT size = 3301
 zc = 9 zm = 8 zs = 1 f = 5		IDAT size = 3286
Selecting parameters:
 zc = 9 zm = 8 zs = 1 f = 5		IDAT size = 3286
Output IDAT size = 3286 bytes (5066 bytes decrease)
Output file size = 3377 bytes (5081 bytes = 60.07% decrease)
efiring@manini:~$ ll grayfig.png
-rw-rw-r-- 1 efiring efiring 3377 2010年07月22日 16:26 grayfig.png
Eric

On 07/22/2010 03:40 PM, j vickroy wrote:
> Christopher Barker wrote:
>> Jim Vickroy wrote:
>>
>>> The attachment is a simple script that creates a 2D array of unsigned,
>>> 8-bit integers and uses matplotlib to save it as a PNG file.
>>>
>>> Unfortunately, the PNG file is much larger than expected -- apparently
>>> because it is True-Color; on my MS Windows machine, bit depth, for the
>>> file, is listed as 32 rather than the expected 8.
>>>
>>
>>
>>> Can matplotlib be used to accomplish this? If so, could someone direct
>>> me to where this is discussed?
>>>
>>
>> I don't think so directly. MPL uses a 32 bit image buffer internally,
>> and that's what gets saved out in the PNG.
>>
>> You can post-process the image with something like ImageMagick.
>>
>> Another alternative is to use PIL -- you can grab the matplotlib buffer,
>> make a PIL image out of it, and use PIL to convert to an 8-bit palleted
>> image.
>>
>> For that matter, you could probably bypass MPL, and use numpy to create
>> the 8-bit image you want, and PIL to save it as a PNG.
>>
>> -Chris
>>
>> Thanks much for the helpful information. I will revisit PIL; I tried matplotlib because of other requirements (colorbar, various figure annotations) which did not appear to be readily available in PIL. At this stage, it depends on how important the requirement is to reduce the size of the PNG images.
>>
> -- jv
No need to use anything other than matplotlib for generating the 
figure--Chris's main point is that mpl does not provide configuration 
options for saving png files, but you can take such a png file, complete 
with image, colorbar, annotations, whatever, and use pil or ImageMagick 
(and there are probably several additional alternatives) to convert to a 
more compact png format. I took a quick look at the documentation of 
pil and IM, but unfortunately did not see any nice example of this--it 
is not obvious to me how to generate the palette. I suspect it is not 
hard, but it might take a while to figure it out from the docs.
Programs like the following might do what you want:
http://www.libpng.org/pub/png/apps/pngquant.html
http://pngnq.sourceforge.net/
Eric
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Christopher Barker wrote:
> Jim Vickroy wrote:
> 
>> The attachment is a simple script that creates a 2D array of unsigned, 
>> 8-bit integers and uses matplotlib to save it as a PNG file.
>>
>> Unfortunately, the PNG file is much larger than expected -- apparently 
>> because it is True-Color; on my MS Windows machine, bit depth, for the 
>> file, is listed as 32 rather than the expected 8.
>> 
>
> 
>> Can matplotlib be used to accomplish this? If so, could someone direct 
>> me to where this is discussed?
>> 
>
> I don't think so directly. MPL uses a 32 bit image buffer internally, 
> and that's what gets saved out in the PNG.
>
> You can post-process the image with something like ImageMagick.
>
> Another alternative is to use PIL -- you can grab the matplotlib buffer, 
> make a PIL image out of it, and use PIL to convert to an 8-bit palleted 
> image.
>
> For that matter, you could probably bypass MPL, and use numpy to create 
> the 8-bit image you want, and PIL to save it as a PNG.
>
> -Chris
>
> Thanks much for the helpful information. I will revisit PIL; I tried matplotlib because of other requirements (colorbar, various figure annotations) which did not appear to be readily available in PIL. At this stage, it depends on how important the requirement is to reduce the size of the PNG images.
> 
-- jv
>
>
>