matplotlib-devel Mailing List for matplotlib

>>>>> "Jeff" == Jeff Whitaker <js...@fa...> writes:
 Jeff> Eric: The combination of your two patches (cntr_bugfix.diff
 Jeff> and cntr_bugfix2.diff) does indeed fix all of the problems
 Jeff> with the basemap examples. Many thanks!
Are you testing from CVS ? I committed them and want to make sure I
have the right version in.
Thanks to all...
JDH

Eric Firing wrote:
> John, Jeff,
>
> The attached patch against the cntr.c in cvs does the following:
>
> 1) Fixes the bug you (Jeff) described above.
>
> 2) Adds a print function for debugging, but normally unused.
>
> 3) Fixes a minor bug in which space for an array of ints was allocated 
> where only an array of chars was used.
>
> The original masked array contourf bug is still there, but I suspect 
> (and hope!) it will not present a serious problem for basemap. I 
> still want to find and fix it, but that may take a long time.
>
> I want to make some minor cleanups and one API change in contour.py, 
> but I will leave that for a separate message, probably within 24 hours.
>
> Eric
Eric: The combination of your two patches (cntr_bugfix.diff and cntr_bugfix2.diff) does indeed fix all of the problems with the basemap examples. Many thanks!
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/CDC R/CDC1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Thursday 02 June 2005 1:55 pm, you wrote:
> Darren Dale <dd...@co...> writes:
> [snip]
>
> > the ps backend will produce a transitional eps file with a bunch of
> > psfrag markers, along with an associated tex file. backend_ps runs latex
> > on the tex file, which embeds the eps, and replaces the markers with the
> > actual text. Now we have a ps file, which can be converted into an eps =
if
> > desired with ps2epsi, or maybe this could be changed to a call to
> > ghostscript: gs -dNOPAUSE -sDEVICE=3Depswrite -sOutputFile=3Dtex_demo.e=
ps
> > tex_demo.ps. As far as the user is concerned, you type savefig('foo.eps=
')
> > and get foo.eps, blissfully unaware of all the intermediate steps.
>
> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=3Dmpprologues
>
> describes a similar situation, but they use dvips -E to generate the
> eps file directly. Could you do that rather than using ghostscript?
> Apart from anything else, it should be quicker.
I had tried this. -E does not seem to be very robust, I cant view the=20
resulting eps files, they appear to be corrupted.
>
> > Here is my current problem. I embed an eps file generated with ps2epsi =
in
> > a new tex document. The dvi looks ok, but after dvips, the text in my
> > figure gets inverted and shifted. This seems to be a bigger problem when
> > using latex classes that do some font handling behind the scenes, for
> > example, article seems ok, but revtex4 and ha-prosper yield unacceptable
> > results.
>
> As an alternative, could you use the .tex/.eps pair directly. This
> would allow you to use the same font and text size in the figure
> caption as in the main document.
This is the way it was originally done. I think it is much better to have a=
=20
single nugget than to have a half complete figure. I think scientific=20
journals may have a problem with submitting these kinds of half complete=20
figures for publication.
>
> > On the other hand, if I use ghostscript to generate the eps, I can
> > embed the files and the printed page looks fine, but the fonts look
> > terrible on screen.
>
> If you are using xdvi, then I found that too. I blamed it on
> ghostscript being used to render the graphics with low resolution, or
> not antialiasing the text.
>
[...]
> >
> > How can MPL deal with these non-MPL issues? I know John doesn't like the
> > idea of handling text in eps as images, but if we did, could that be a
> > suitable workaround?
>
> I agree with John here.
So do I. But I have a thesis, two papers, and two talks to write. I was hop=
ing=20
practicality might temporarily win out, but I dont know for sure that such =
an=20
effort would even solve the problem.
>
> > Does anyone have another suggestion?
>
> Hope these suggestions might help.
>
> Chris
>
> PS One further thought I had is MetaPost.
> http://www.tex.ac.uk/cgi-bin/texfaq2html?label=3DMP Is it possible for
> matplotlib to embed the tex expressions in the same way that metapost
> does? This might not solve your problem however, as xdvi currently has
> a problem displaying them - see
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D295205 for details.
>
> PPS If you need something in a hurry (for your thesis?), can you
> create the whole thing as a bitmap? or use the latex "ite" package to
> position labels? If you do the latter, there is a patch I should send
> you - otherwise it clashes with various packages.
Thank you for the suggestions, but they are both significant deviations fro=
m=20
what I already have in place, and I have to prepare a talk for June 13. In=
=20
the worst case scenario, I will just set usetex to false, and make some=20
temporary changes in my local installation to work around some font layout=
=20
issues that usetex had addressed.
=46onts, fonts, fonts. My new f-word.
=2D-=20
Darren S. Dale
Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850
dd...@co...
http://people.ccmr.cornell.edu/~dd55/

Nicolas Girard wrote:
> That beeing said, I'm also in the need of a way of saving eps figures of gray 
> contours in negative, in order to save toner... with the standard gray 
> colormap, my contours are very dark, leading to a huge consumption of toner.
> 
> With a gray colormap "in negative", the result would be at least as readable 
> and consumes much less toner.
> 
> Two strategies are possible here:
> 
> - either display the gray colormap as usual on the screen, but save the figure 
> in negative with the "eps" or "png" backends (this is AFAIK the default 
> behaviour of IDL),
-1. One of mpl's strengths is that it shows you on screen what you get 
on paper, I'd _hate_ to folow IDL here (or for that matter, on just 
about anything else).
> - or provide a "negative gray" colormap ; I've tried to hack the cm.py in that 
> way, and tried something like:
> 
> _ngray_data = {'red': ((0., 1, 1), (1., 0, 0)),
> 'green': ((0., 1, 1), (1., 0, 0)),
> 'blue': ((0., 1, 1), (1., 0, 0))}
I've meen meaning to add a .reversed() method to the colormap instances, 
which will automatically return an instance of the given colormap with 
its lookup table reversed, and the name simply with a suffix appended 
(_r, _rev, r, ...). I think this is the right solution, and I also 
think we should supply, by default, reversed versions of the standard 
colormaps. At the very least, the gray_rev (or whatever it gets called) 
can be _extremely_ useful.
> but there seems to be a problem with the highest values, that keep beeing 
> displayed in white instead of black.
Mmh, I haven't seen this. I have the same defined in my default 
run-time config loaded by ipython, and I haven't seen this kind of 
clipping, but maybe I just haven't noticed it. I've been using 
matshow() and haven't seen this, I'll look again in more detail later.
Cheers,
f

Darren Dale <dd...@co...> writes:
[snip]
> the ps backend will produce a transitional eps file with a bunch of psfrag 
> markers, along with an associated tex file. backend_ps runs latex on the tex 
> file, which embeds the eps, and replaces the markers with the actual text. 
> Now we have a ps file, which can be converted into an eps if desired with 
> ps2epsi, or maybe this could be changed to a call to ghostscript: gs 
> -dNOPAUSE -sDEVICE=epswrite -sOutputFile=tex_demo.eps tex_demo.ps. As far as 
> the user is concerned, you type savefig('foo.eps') and get foo.eps, 
> blissfully unaware of all the intermediate steps.
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=mpprologues
describes a similar situation, but they use dvips -E to generate the
eps file directly. Could you do that rather than using ghostscript?
Apart from anything else, it should be quicker.
> 
> Here is my current problem. I embed an eps file generated with ps2epsi in a 
> new tex document. The dvi looks ok, but after dvips, the text in my figure 
> gets inverted and shifted. This seems to be a bigger problem when using latex 
> classes that do some font handling behind the scenes, for example, article 
> seems ok, but revtex4 and ha-prosper yield unacceptable results.
As an alternative, could you use the .tex/.eps pair directly. This
would allow you to use the same font and text size in the figure
caption as in the main document. 
> 
> On the other hand, if I use ghostscript to generate the eps, I can
> embed the files and the printed page looks fine, but the fonts look
> terrible on screen. 
If you are using xdvi, then I found that too. I blamed it on
ghostscript being used to render the graphics with low resolution, or
not antialiasing the text.
> Here is a comment from the afpl website 
> http://www.cs.wisc.edu/~ghost/doc/AFPL/8.50/Issues.htm:
> 
> ---
> pswrite device generates low level PostScript.
> 
> pswrite and epswrite devices reduce everything to path, fill, stroke, clip 
> image, and imagemask operations. Although the resulting file prints OK it 
> produces unsatisfactory results when scaled, distilled or imported into 
> graphic editors. The file can easily exceed 4GB and hit file size limits in 
> some applications or operation systems. Handling of big files is slow. 
> ---
> The associated bug report (filed over 2 years ago) says this is a low priority 
> problem.
> 
> How can MPL deal with these non-MPL issues? I know John doesn't like the idea 
> of handling text in eps as images, but if we did, could that be a suitable 
> workaround? 
I agree with John here. 
> Does anyone have another suggestion?
Hope these suggestions might help. 
Chris
PS One further thought I had is MetaPost.
http://www.tex.ac.uk/cgi-bin/texfaq2html?label=MP Is it possible for
matplotlib to embed the tex expressions in the same way that metapost
does? This might not solve your problem however, as xdvi currently has
a problem displaying them - see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=295205 for details.
PPS If you need something in a hurry (for your thesis?), can you
create the whole thing as a bitmap? or use the latex "ite" package to
position labels? If you do the latter, there is a patch I should send
you - otherwise it clashes with various packages.
 

John, Jeff,
> Eric: Thanks - contour indeed now seems to work perfectly with masked 
> arrays, but I still have problems with contourf (see attached 
> ortho_test.png). Unfortunately, neither of your suggested workarounds 
> help, the first makes no difference and the second makes it much worse.
> -Jeff
The attached patch against the cntr.c in cvs does the following:
1) Fixes the bug you (Jeff) described above.
2) Adds a print function for debugging, but normally unused.
3) Fixes a minor bug in which space for an array of ints was allocated 
where only an array of chars was used.
The original masked array contourf bug is still there, but I suspect 
(and hope!) it will not present a serious problem for basemap. I still 
want to find and fix it, but that may take a long time.
I want to make some minor cleanups and one API change in contour.py, but 
I will leave that for a separate message, probably within 24 hours.
Eric

I have been trying to deal with some font problems related to the new tex=20
capabilities in MPL. Let me summarize what MPL is doing, when text.usetex i=
s=20
true in rc:
texmanager runs TeX (or LaTeX) on a string, and John has somehow extracted =
an=20
image of that string and its bbox information to intelligently layout and=20
render the text.
the ps backend will produce a transitional eps file with a bunch of psfrag=
=20
markers, along with an associated tex file. backend_ps runs latex on the te=
x=20
file, which embeds the eps, and replaces the markers with the actual text.=
=20
Now we have a ps file, which can be converted into an eps if desired with=20
ps2epsi, or maybe this could be changed to a call to ghostscript: gs=20
=2DdNOPAUSE -sDEVICE=3Depswrite -sOutputFile=3Dtex_demo.eps tex_demo.ps. As=
 far as=20
the user is concerned, you type savefig('foo.eps') and get foo.eps,=20
blissfully unaware of all the intermediate steps.
Here is my current problem. I embed an eps file generated with ps2epsi in a=
=20
new tex document. The dvi looks ok, but after dvips, the text in my figure=
=20
gets inverted and shifted. This seems to be a bigger problem when using lat=
ex=20
classes that do some font handling behind the scenes, for example, article=
=20
seems ok, but revtex4 and ha-prosper yield unacceptable results.
On the other hand, if I use ghostscript to generate the eps, I can embed th=
e=20
files and the printed page looks fine, but the fonts look terrible on scree=
n.=20
Here is a comment from the afpl website=20
http://www.cs.wisc.edu/~ghost/doc/AFPL/8.50/Issues.htm:
=2D--
pswrite device generates low level PostScript.
pswrite and epswrite devices reduce everything to path, fill, stroke, clip=
=20
image, and imagemask operations. Although the resulting file prints OK it=20
produces unsatisfactory results when scaled, distilled or imported into=20
graphic editors. The file can easily exceed 4GB and hit file size limits in=
=20
some applications or operation systems. Handling of big files is slow.=20
=2D--
The associated bug report (filed over 2 years ago) says this is a low prior=
ity=20
problem.
How can MPL deal with these non-MPL issues? I know John doesn't like the id=
ea=20
of handling text in eps as images, but if we did, could that be a suitable=
=20
workaround? Does anyone have another suggestion?
Darren

On Wed, 2005年06月01日 at 15:49 -0700, Andrew Straw wrote:
> John Hunter wrote:
> >>>>>>"Nicholas" == Nicholas Young <su...@su...> writes:
> > 
> > 
> > Nicholas> Now done in the attached patch, I also added support for
> > Nicholas> MxNx3 images; as I suspected these are noticeably slower
> > Nicholas> than MxNx4 images but I changed my mind and decided it
> > Nicholas> was worth supporting them.
> > 
> > Great, I just committed this to CVS.
> > 
> > Andrew, if you get a minute to update from CVS, can you make sure that
> > the PIL changes don't cause a problem for your PIL using mpl scripts?
> 
> I didn't have much of a check, but image_demo3.py still works.
> 
> This may be the apparently-longstanding imshow resizing bug (that I 
> haven't followed), but this demo shows some storage behavior when 
> resizing -- horizontal stretching of the window allows the aspect ratio 
> of the image to change to horizontally stretched, but vertical 
> stretching of the window appears to scale the image to maintain its 
> original aspect ratio.
I don't think this is connected to the changes I've made; as I've
changed none of the resizing/streaching/fixed aspect code. I've not
followed any prior discussion (and so don't know why the problem hasn't
been fixed) but if I'm reading it correctly it's fairly clear from the
general imshow code that problem is going to manifest itself.
Nick

On Wednesday 01 June 2005 18:38, John Hunter wrote:
> Nicolas wants a standard
> colormap but with the colorbar display inverted (red would still map
> to large numbers but for vertical colorbars would be on the bottom and
> for horizontal colorbars would be on the left -- the colorbar tick
> labels would change too).
>
That beeing said, I'm also in the need of a way of saving eps figures of gray 
contours in negative, in order to save toner... with the standard gray 
colormap, my contours are very dark, leading to a huge consumption of toner.
With a gray colormap "in negative", the result would be at least as readable 
and consumes much less toner.
Two strategies are possible here:
- either display the gray colormap as usual on the screen, but save the figure 
in negative with the "eps" or "png" backends (this is AFAIK the default 
behaviour of IDL),
- or provide a "negative gray" colormap ; I've tried to hack the cm.py in that 
way, and tried something like:
_ngray_data = {'red': ((0., 1, 1), (1., 0, 0)),
 'green': ((0., 1, 1), (1., 0, 0)),
 'blue': ((0., 1, 1), (1., 0, 0))}
but there seems to be a problem with the highest values, that keep beeing 
displayed in white instead of black.
What do you think ?
PS: which place would be the more appropriate for this discussion, the -user 
or -devel mailing list ?
Cheers,
Nicolas