Subplot Questions

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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

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

···

On Mon, 28 Jan 2008, Manuel Metz apparently wrote:

fig = pylab.figure(figsize=(6,10), dpi=96)
[...]
pylab.savefig("filename.eps", dpi=96)

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 Mon, 28 Jan 2008, 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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Alan G Isaac 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 Mon, 28 Jan 2008, Manuel Metz 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.

JDH

···

On Jan 31, 2008 12:54 AM, Eric Firing <efiring@...202...> 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

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

···

On Thu, 31 Jan 2008, 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.

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 Wed, 30 Jan 2008, "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.

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 <aisaac@...310...> 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?

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

···

On Jan 31, 2008 9:09 AM, Alan G Isaac <aisaac@...310...> 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 Thu, 31 Jan 2008, 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.

John Hunter wrote:

···

On Jan 31, 2008 12:54 AM, Eric Firing <efiring@...202...> 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 <efiring@...202...> 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
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options