I found a bug in the Y-axis scaling. See the attached PS file. The Y-axis scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having experience with the scaling code want to fix this? For those interested, this is a section of the far ultraviolet spectrum of the variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet Spectroscopic Explorer (FUSE for short). -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
Paul Barrett wrote: > I found a bug in the Y-axis scaling. See the attached PS file. The Y-axis > scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). Instead it is > zeros. Anyone having experience with the scaling code want to fix this? > > For those interested, this is a section of the far ultraviolet spectrum of the > variable star SS Cygni (SS Cyg for short) taken by NASA's Far Ultraviolet > Spectroscopic Explorer (FUSE for short). Well, I actually tried to see it but gv (Fedora Core 2) chokes on the file: CPU utilization goes to 100% after displaying the axes, labels, and a tiny bit of the graph. I killed it after a while. Are there known problems with the Postscript generated by matplotlib? Can it produce EPS directly (better for publication)? Cheers, f
Paul Barrett wrote: > Yes, I have the same problem with ggv. However, it prints fine on a PS printer, > so I think it's ghostview. Mmh. It still might be worth looking into. Even if it's a ghostview problem, it might be possible to generate 'friendlier' PS code that doesn't kill ghostview so badly. As people start using matplotlib for generating EPS plots which will go into papers, the "if you can't preview it just print it" answer is going to make quite a few unhappy campers, I suspect. I know it sucks to code around the bugs of other code, but given that ghostview is the near-universally available tool (I checked the problem against RedHat 9, Fedora 1 and Fedora 2), matplotlib might want to bow a bit in this case :) Just a suggestion. Best, f
>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes: Fernando> Well, I actually tried to see it but gv (Fedora Core 2) Fernando> chokes on the file: CPU utilization goes to 100% after Fernando> displaying the axes, labels, and a tiny bit of the Fernando> graph. I killed it after a while. I had the same problem with ggv (but I converted it with ps2pdf and viewed it as pdf). What are you using as a PS viewer Paul? One thing that concerns about embedding truetype fonts in PS figures is that they don't look very good in standard viewers (xdvi, ggv) though they seem to print fine, at least on the printers I've tried. It may be that the viewers don't have very good truetype rendering algorithms. I'm on the fence about whether we should revert to the afm fonts for plain text in PS, and just use truetype for mathtext and if explicitly requested using a yet-to-be-determined mechanism. These certainly look better in the PS viewers I've tried. Of course the truetype fonts offer the same look and feel across backends, which is why I am on the fence. Any opinions here? Fernando> Are there known problems with the Postscript generated Fernando> by matplotlib? Can it produce EPS directly (better for Fernando> publication)? EPS: yes - just save as *.eps from just about any backend. The only reported problem I've heard was a post from Flavio Coelho While on the same topic, I had some problems inserting matplotlib generated PS plots into TeXMacs, although they open normally in gv, for instance. have you have seen any compatibility issues for the PS files and other PS viewing programs? Running ps2ps on the matplotlib PS files resolved the problem. However I wanted to use TexMacs as a frontend to use matplotlib interactively... Paul, so we could help narrow this problem with gv and your figure, could you try generating it with 0.60.2 (which uses AFM if I recall correctly) to see if it is related to the new font handling in PS? Thanks, JDH
John Hunter wrote: >>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes: > > > > Fernando> Well, I actually tried to see it but gv (Fedora Core 2) > Fernando> chokes on the file: CPU utilization goes to 100% after > Fernando> displaying the axes, labels, and a tiny bit of the > Fernando> graph. I killed it after a while. > > I had the same problem with ggv (but I converted it with ps2pdf and > viewed it as pdf). What are you using as a PS viewer Paul? GGV (i.e. Gnome ghostview) > One thing that concerns about embedding truetype fonts in PS figures > is that they don't look very good in standard viewers (xdvi, ggv) > though they seem to print fine, at least on the printers I've tried. > It may be that the viewers don't have very good truetype rendering > algorithms. It might also be the standard fonts that we use. In other words, there might be other truetype fonts that render better with freetype2. > I'm on the fence about whether we should revert to the afm fonts for > plain text in PS, and just use truetype for mathtext and if > explicitly requested using a yet-to-be-determined mechanism. These > certainly look better in the PS viewers I've tried. Of course the > truetype fonts offer the same look and feel across backends, which is > why I am on the fence. Any opinions here? I don't see a gain here, since PS output is mainly for printing where the fonts look fine. Maybe we should invest more effort in a PDF backend, which displays better in a viewer and also does the conversion to PS. Or switch to TTF that render better in a viewer, such as the core MS TT fonts. > Fernando> Are there known problems with the Postscript generated > Fernando> by matplotlib? Can it produce EPS directly (better for > Fernando> publication)? > > EPS: yes - just save as *.eps from just about any backend. > > The only reported problem I've heard was a post from Flavio Coelho > > While on the same topic, I had some problems inserting matplotlib > generated PS plots into TeXMacs, although they open normally in gv, > for instance. have you have seen any compatibility issues for the PS > files and other PS viewing programs? Running ps2ps on the > matplotlib PS files resolved the problem. However I wanted to use > TexMacs as a frontend to use matplotlib interactively... > > Paul, so we could help narrow this problem with gv and your figure, > could you try generating it with 0.60.2 (which uses AFM if I recall > correctly) to see if it is related to the new font handling in PS? I'll take a look at it. However, I suspect the fonts are not the problem, since each font only increases the size of the PS file by about 60 kBs. I suspect it is the size of the data and the rendering code that is causing the problem. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
Fernando Perez wrote: > Paul Barrett wrote: > >> I found a bug in the Y-axis scaling. See the attached PS file. The >> Y-axis scale should go from 0. to 2.0e-11 (in ergs/cm**2/s/Angstrom). >> Instead it is zeros. Anyone having experience with the scaling code >> want to fix this? >> >> For those interested, this is a section of the far ultraviolet >> spectrum of the variable star SS Cygni (SS Cyg for short) taken by >> NASA's Far Ultraviolet Spectroscopic Explorer (FUSE for short). > > > Well, I actually tried to see it but gv (Fedora Core 2) chokes on the > file: CPU utilization goes to 100% after displaying the axes, labels, > and a tiny bit of the graph. I killed it after a while. > > Are there known problems with the Postscript generated by matplotlib? > Can it produce EPS directly (better for publication)? OK, I've created a patch to work around the 'gv' problem for dense line plots. Attached is a PS file created from this patch. Please test to see if it solves your problem. If it does, I'll commit the patch to CVS. It worked for me on 'ggv'. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> OK, I've created a patch to work around the 'gv' problem for Paul> dense line plots. Attached is a PS file created from this Paul> patch. Please test to see if it solves your problem. If it Paul> does, I'll commit the patch to CVS. It worked for me on Paul> 'ggv'. Works for me (also ggv) - what did you do, break up paths longer than a certain size into multiple paths? I need to do the same for agg to fix Jin-chung's bug. JDH
John Hunter wrote: >>>>>>"Paul" == Paul Barrett <ba...@st...> writes: > > > Paul> OK, I've created a patch to work around the 'gv' problem for > Paul> dense line plots. Attached is a PS file created from this > Paul> patch. Please test to see if it solves your problem. If it > Paul> does, I'll commit the patch to CVS. It worked for me on > Paul> 'ggv'. > > Works for me (also ggv) - what did you do, break up paths longer than > a certain size into multiple paths? I need to do the same for agg to > fix Jin-chung's bug. Yes. Paths are divided into mutiple paths of 1000 points (except for the last path with can contain upto 1001 points to prevent the last point from being orphaned). This path size seemed like a reasonable number. I didn't do any tests to determine the optimum path size. From the way gv behaves on my Linux box, it appears that 5000 points may be the limit. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
Paul Barrett wrote: > OK, I've created a patch to work around the 'gv' problem for dense line plots. > Attached is a PS file created from this patch. Please test to see if it solves > your problem. If it does, I'll commit the patch to CVS. It worked for me on 'ggv'. Works OK now with gv on Fedora Core 2. Thanks, f
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> I found a bug in the Y-axis scaling. See the attached PS Paul> file. The Y-axis scale should go from 0. to 2.0e-11 (in Paul> ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having Paul> experience with the scaling code want to fix this? Darren Dale posted a small fix related to ticking for exponentially formatted data to the users list today - you may want to see if that helps. Otherwise, if you can send me a tarball which has a script and some data so I can replicate the bug, I'll take a look. These bugs are easier to fix if you have something to test against. JDH Paul> For those interested, this is a section of the far Paul> ultraviolet spectrum of the variable star SS Cygni (SS Cyg Paul> for short) taken by NASA's Far Ultraviolet Spectroscopic Paul> Explorer (FUSE for short). Paul> -- Paul Paul> -- Paul Barrett, PhD Space Telescope Science Institute Paul> Phone: 410-338-4475 ESS/Science Software Branch FAX: Paul> 410-338-4767 Baltimore, MD 21218
John Hunter wrote:
>>>>>>"Paul" == Paul Barrett <ba...@st...> writes:
>
>
> Paul> I found a bug in the Y-axis scaling. See the attached PS
> Paul> file. The Y-axis scale should go from 0. to 2.0e-11 (in
> Paul> ergs/cm**2/s/Angstrom). Instead it is zeros. Anyone having
> Paul> experience with the scaling code want to fix this?
>
> Darren Dale posted a small fix related to ticking for exponentially
> formatted data to the users list today - you may want to see if that
> helps.
No, the latest CVS still shows the bug.
> Otherwise, if you can send me a tarball which has a script and some
> data so I can replicate the bug, I'll take a look. These bugs are
> easier to fix if you have something to test against.
Attached is the data (FITS) file and the following are the commands that I use
to plot the data. You may need to download the pyfits module to access the file.
>>> import pyfits
>>> from matplotlib.matlab import *
>>> fits = pyfits.open('C05302010011alif4ttagfcal.fit')
>>> data = fits[1].data.field
>>> plot(data('wave'), data('flux'))
[<matplotlib.lines.Line2D instance at 0x40da5c4c>]
>>> show()
Thanks for taking a look at this.
-- Paul
--
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> No, the latest CVS still shows the bug. I haven't included his changes yet so you would have had to add the code yourself. I can take a look later though. >> Otherwise, if you can send me a tarball which has a script and >> some data so I can replicate the bug, I'll take a look. These >> bugs are easier to fix if you have something to test against. Paul> Attached is the data (FITS) file and the following are the Paul> commands that I use to plot the data. You may need to Paul> download the pyfits module to access the file. I don't think your data file came through properly. You may want to upload it to http://nitace.bsd.uchicago.edu:8080/files/share Paul> Thanks for taking a look at this. No problem... JDH
John Hunter wrote: >>>>>>"Paul" == Paul Barrett <ba...@st...> writes: > > > > Paul> No, the latest CVS still shows the bug. > > I haven't included his changes yet so you would have had to add the > code yourself. I can take a look later though. OK. I made the changes that Darren Dale suggested and the plot now looks good. > >> Otherwise, if you can send me a tarball which has a script and > >> some data so I can replicate the bug, I'll take a look. These > >> bugs are easier to fix if you have something to test against. > > Paul> Attached is the data (FITS) file and the following are the > Paul> commands that I use to plot the data. You may need to > Paul> download the pyfits module to access the file. > > I don't think your data file came through properly. You may want to > upload it to http://nitace.bsd.uchicago.edu:8080/files/share Done. The file is uploaded. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218
>>>>> "Paul" == Paul Barrett <ba...@st...> writes: Paul> OK. I made the changes that Darren Dale suggested and the Paul> plot now looks good. Great, I take it you'll commit these to CVS.... Paul> Done. The file is uploaded. OK, thanks. I'll see if I can get any insight into the PS bug. It may be, as you suggest, a line size issue. That looked like a pretty dense spectrum you plotted. If you were following the user list, Jin-chung found a pathological case where the agg renderer runs out of ink for extremely long dense paths that cover over 4 Mega-pixels with ink. His problem can be solved by breaking up really long paths into separate paths (not implemented yet). It may be that the same thing is needed in backend_ps to accommodate gv. JDH