Dear all, I am working on sending vibration results to two plots: subplot(211) and subplot(212). I have the following questions: 1. How to define the size of the figure? I will eventually import the figure into Microsoft Word, and I hope I can fit the figure into one page. 2. If I want to make both the subplots square sized, how do I achieve it? Thanks! Cheng-Kong ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
Cheng-Kong Wu wrote:
> Dear all,
>
> I am working on sending vibration results to two
> plots: subplot(211) and subplot(212). I have the
> following questions:
>
> 1. How to define the size of the figure? I will
> eventually import the figure into Microsoft Word, and
> I hope I can fit the figure into one page.
fig = pylab.figure(figsize=(6,10), dpi=96)
[...]
pylab.savefig("filename.eps", dpi=96)
,where figsize in the figure size in inches.
> 2. If I want to make both the subplots square sized,
> how do I achieve it?
xylims = (-10,10) # set your axis limits here
pylab.gca().set_xlim(xylims)
pylab.gca().set_ylim(xylims)
pylab.gca().set_aspect('equal')
That's the quick-and-easy way. If the limits differ, you can create your
own new axes instance, have a look at axes_demo.py in the examples.
Manuel
> Thanks!
> Cheng-Kong
>
>
> ____________________________________________________________________________________
> Never miss a thing. Make Yahoo your home page.
> http://www.yahoo.com/r/hs
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
On 2008年1月28日, Manuel Metz apparently wrote:
> fig = pylab.figure(figsize=(6,10), dpi=96)
> [...]
> pylab.savefig("filename.eps", dpi=96)
A couple questions.
1. The help for figure says that the dpi argument
determines the "resolution". Suppose I am producing
a PNG file for screen display: what am I changing
when I change the dpi argument (from the point of
view of the file, and from the point of viewer of
the person viewing the file onscreen). More generally,
are there standard setting recommended for onscreen
PNG figure display?
2. EPS is a vector format, and the fig has a size.
What role does the dpi argument play here?
Thank you,
Alan Isaac
Alan:
The figure size determines the eventual size of the figure where it will
be displayed. You should set that with "figsize=(x,y)" before you
actually plot. Then, and very importantly, you should set the DPI for
the medium where you are viewing the figure. A computer display will
probably be between 75 and 100 DPI. Then for good print quality, you
should specify a DPI larger than that, say 300 or 350 or for some
purists even to 800 when you use "savefig(...)". Then the actual number
of pixels is determined which will give the original figure size on the
chosen display medium. Note that more DPI means more pixels and a
larger file. This didn't work for me with an earlier version of mpl and
after I posted that here, it was fixed so you should be using the latest
version for the above to work.
HTH and cheers,
Wayne
Alan G Isaac wrote:
> On 2008年1月28日, Manuel Metz apparently wrote:
>
>> fig = pylab.figure(figsize=(6,10), dpi=96)
>> [...]
>> pylab.savefig("filename.eps", dpi=96)
>>
>
> A couple questions.
>
> 1. The help for figure says that the dpi argument
> determines the "resolution". Suppose I am producing
> a PNG file for screen display: what am I changing
> when I change the dpi argument (from the point of
> view of the file, and from the point of viewer of
> the person viewing the file onscreen). More generally,
> are there standard setting recommended for onscreen
> PNG figure display?
>
> 2. EPS is a vector format, and the fig has a size.
> What role does the dpi argument play here?
>
> Thank you,
> Alan Isaac
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
On 2008年1月30日, "Wayne E. Harlan" apparently wrote: > The figure size determines the eventual size of the figure > where it will be displayed. You should set that with > "figsize=(x,y)" before you actually plot. Then, and very > importantly, you should set the DPI for the medium where > you are viewing the figure. So, to take an example, suppose I set the figsize=(6,4.5) and dpi = 80. Then I will get a 480px by 360px figure. So if this displays on a 120 dpi monitor it will display as roughly 4" by 3". And if I print it unmodified to a 300 dpi printer, it will only be about 1.6" by 1.2". Is that about right? Thank you, Alan Isaac
On Jan 31, 2008 9:09 AM, Alan G Isaac <ai...@am...> wrote: > So, to take an example, suppose I set the figsize=(6,4.5) > and dpi = 80. Then I will get a 480px by 360px figure. > So if this displays on a 120 dpi monitor it will display > as roughly 4" by 3". And if I print it unmodified to a 300 > dpi printer, it will only be about 1.6" by 1.2". > > Is that about right? Probably not. It will depend on the backend. For example, if you save in PS or EPS, the dpi is ignored and the vector graphics will be sent to the printer and should print in true figure sizes. If you print png to the printer, I suspect what happens will depend on the software you are using to print and the printer driver, since the png will have to be converted into some language the printer understands.
> On Jan 31, 2008 9:09 AM, Alan G Isaac <ai...@am...> wrote: >> So, to take an example, suppose I set the figsize=(6,4.5) >> and dpi = 80. Then I will get a 480px by 360px figure. >> So if this displays on a 120 dpi monitor it will display >> as roughly 4" by 3". And if I print it unmodified to a 300 >> dpi printer, it will only be about 1.6" by 1.2". >> Is that about right? On 2008年1月31日, John Hunter apparently wrote: > Probably not. It will depend on the backend. For example, if you > save in PS or EPS, the dpi is ignored and the vector graphics will be > sent to the printer and should print in true figure sizes. If you > print png to the printer, I suspect what happens will depend on the > software you are using to print and the printer driver, since the png > will have to be converted into some language the printer understands. But is the first part right? (That the PNG would print at 4" by 3" on a 120dpi monitor.) That seems to match everything said so far on this thread. This is actually what I need to have a good feel for right now. Thank you, Alan Isaac
Alan G Isaac wrote:
> On 2008年1月28日, Manuel Metz apparently wrote:
>> fig = pylab.figure(figsize=(6,10), dpi=96)
>> [...]
>> pylab.savefig("filename.eps", dpi=96)
>
> A couple questions.
>
> 1. The help for figure says that the dpi argument
> determines the "resolution". Suppose I am producing
> a PNG file for screen display: what am I changing
> when I change the dpi argument (from the point of
> view of the file, and from the point of viewer of
> the person viewing the file onscreen). More generally,
> are there standard setting recommended for onscreen
> PNG figure display?
For screen display, whether in interactive mode or when displaying a png
file, if you use a dpi value that matches the actual dpi of your screen,
then when you specify figsize in inches, your figure will actually
appear that size, fonts will be the right size, etc. If you use too
small a dpi value, the figure will be smaller than it should.
Screens vary. The screen on my laptop has about 130 dpi. Desktop flat
panels will usually have a smaller value than that. For example, an old
"15-inch" flat panel with 1024/768 pixels is actually about 12 inches
wide, so dpi=85. The mpl default 'figure.dpi' of 80 is low; I doubt
many modern screens come close to that. If I were recommending a
default, I would probably pick 100 or 110 as a middle-of-the-road match
to the range of modern screens, but I have not looked into it carefully.
>
> 2. EPS is a vector format, and the fig has a size.
> What role does the dpi argument play here?
Some information, such as images, must be encoded as pixels. The dpi
value in this case determines the resolution of an image, not the
physical size in inches. Using a large value will yield better
resolution at the cost of a larger file and slower rendering.
Eric
On Jan 31, 2008 12:54 AM, Eric Firing <ef...@ha...> wrote: > Screens vary. The screen on my laptop has about 130 dpi. Desktop flat > panels will usually have a smaller value than that. For example, an old > "15-inch" flat panel with 1024/768 pixels is actually about 12 inches > wide, so dpi=85. The mpl default 'figure.dpi' of 80 is low; I doubt And it is not unusual to have a different DPI in the horizontal and vertical directions. In order to support true physical sizes on the screen, we would need to support different dpis in the two directions. JDH
On 2008年1月31日, John Hunter apparently wrote: > And it is not unusual to have a different DPI in the > horizontal and vertical directions. In order to support > true physical sizes on the screen, we would need to > support different dpis in the two directions. Does that mean that one should expect font-shape distortion when PNGs are displayed onscreen? And maybe even that a square figure will not display as square? If not, why not? I've never had to think about this before: it seems an odd nightmare for some kinds of online publication (e.g., scientific journals using HTML based publication formats). Thank you, Alan Isaac
John Hunter wrote: > On Jan 31, 2008 12:54 AM, Eric Firing <ef...@ha...> wrote: > >> Screens vary. The screen on my laptop has about 130 dpi. Desktop flat >> panels will usually have a smaller value than that. For example, an old >> "15-inch" flat panel with 1024/768 pixels is actually about 12 inches >> wide, so dpi=85. The mpl default 'figure.dpi' of 80 is low; I doubt > > And it is not unusual to have a different DPI in the horizontal and > vertical directions. In order to support true physical sizes on the > screen, we would need to support different dpis in the two directions. Does any other software actually do this? I have never seen anything with more than a single dpi setting. What is an example of a display with non-square pixels? And how non-square are they? I suspect this is not something that Alan really needs to worry about. Eric
Eric: I have never seen any software which dealt with non uniform DPI settings, although that is always a possibility. And all the displays I have ever worked on/with have been the same for both H and V. ( I am a display engineer with over 25 years experience in CRT displays and a bit in flat panel). From what I have seen, the RGB trio in any display is set up so that the horizontal pitch is the same as the vertical pitch. In a flat panel the R, G and B are 3 times taller than they are wide so that when you place R, G and B together they form a square. I don't think that Matplotlib or Alan needs to worry about anything outside those boundaries. Wayne Eric Firing wrote: > John Hunter wrote: > >> On Jan 31, 2008 12:54 AM, Eric Firing <ef...@ha...> wrote: >> >> >>> Screens vary. The screen on my laptop has about 130 dpi. Desktop flat >>> panels will usually have a smaller value than that. For example, an old >>> "15-inch" flat panel with 1024/768 pixels is actually about 12 inches >>> wide, so dpi=85. The mpl default 'figure.dpi' of 80 is low; I doubt >>> >> And it is not unusual to have a different DPI in the horizontal and >> vertical directions. In order to support true physical sizes on the >> screen, we would need to support different dpis in the two directions. >> > > Does any other software actually do this? I have never seen anything > with more than a single dpi setting. What is an example of a display > with non-square pixels? And how non-square are they? I suspect this is > not something that Alan really needs to worry about. > > Eric > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >