Re: Window size, image size and animations
Cleon Teunissen <cleon <at> castel.nl>
2007-10-25 17:13:15 GMT
Cleon Teunissen wrote:
> > What would have happened if the Graph window would have been rectangular,
> > for example 600 high and 700 wide, and that I would have specified as image
> > dimensions: height 700, width 700
> > Presumably Graph preserves the aspect ratio of the drawing, and just adds
> > 50 pixels of white space to both the top and the bottom. Can you confirm
> > this?
Ivan Johansen <graph <at> padowan.dk> wrote:
> It should create a 700x700 pixels image if that is what you specify. It
> shouldn't add any white space, and it doesn't do that either when I try it.
Here's what I am curious about:
Suppose I do the following:
I define the X-axis as running from -1 to 1
I define the Y-axis as running from -1 to 1
I use a parametric or polar function to draw a circle with a radius of 0.9
coordinate units.
Suppose the drawing secton of the Graph window is 1000 pixels high, and 1100
pixels wide.
What will the onscreen shape of the circle be? Will it be a perfect circle, or
will it be distorted to an ellipse, due to the ratio of 1000 to 1100? What I
expect is that under those circumstances graph will draw a perfect circle with
a diameter of 900 pixels.
I also expect/assume that when I specify certain image dimensions (when using
the 'save as image' option), say 2000x2000 pixels, then Graph will not simply
dump the screen contents, but will recalculate the drawing, yielding a circle
with a diameter of 1800 pixels.
In other words, how does Graph handle the X and Y axis? Do you stretch/contract
each separate axis to fill up the available space, or are the X-axis and Y-axis
locked in a 1-to-1 ratio?
(Of course I can find these things out by just trying different combinations of
Graph settings, but I rather use Graph for graphs and animations, and not for
testing Graph itself.)
> > When using Graph 4.2 with a 1280x1024 monitor resolution, the Graph
> > coordinate system section was 902 pixels high, and I carefully adjusted the
> > width to match that. Hence when I want to save as image I can choose
> > between the screen size 902x902 or I can choose the custom size. However,
> > when I choose to generate an animation, I'm presented with: width=902 and
> > height=844 Why has the height dropped from 902 to 844, and will that affect
> > the shape of the objects in the animation?
> The reason is to make sure the animation player can fit on the screen.
> But maybe I shouldn't have made that limitation. I will try to improve
> it. The change in the height will affect the shape, so if you want a
> square animation you can use 844x844.
This leads to a feature request:
Can you add an option: 'maintain aspect ratio'. When checked, the ratio of
width and height remains locked.
> > there is mention of storing an image in
> > the grf files 'to make preview and thumbnails faster'. I frequenly open the
> > grf files in a text-editor, because I can work faster that way.
> I actually never got the time to finish implementing that. It was a
> mistake that it got into the history, and it was later removed again.
If you finish implementing that in a later stage, will it interfere with the
ability to open the files in a text-editor? From my point of view that would be
a loss of flexibility.
> > Feature request: can you possibly add an option to save the frames of an
> > animation as consecutively numbered image-files?
> Yes, that should be easy enough. I will try to implement it one of the
> next days. Some day I hope to also make it possible to save as animated
> gif, but currently only avi files are supported.
A robust way of numbering consecutive files may be trickier than it looks.
When I store 12 consecutive frames they are numbered as follows: 00 01 02 03 04
05 06 07 08 09 10 11. That way animation software puts the frames automatically
in the correct order
Irfanview has an excellent facility for batch (re)naming of a collection of
files. The user specifies the starting point, the increment, and the naming
pattern. The naming pattern is # or ## or ### or #### and so on. If the user
specifies naming pattern ###, and starting point 0, and increment 1, then the
first file will be called 000, the second file will be called 001, etc.
It seems to me that the scheme adopted by Irfanview is the only one that is
robust.
I tried to extract the individual frames from the avi. I use Irfanview for
extracting the frames from gif-animations. Irfanview can also extract frames
from avi-files, but it couldn't extract the frames from the avi-file that Graph
had generated. Possibly some information neccessary for the frame extraction is
not present in the avi-file.
For saving individual frames, PNG-files are the best. I use optimisation
software to manage the size of the gif-animations. Often a palette of 16
entries suffices, which corresponds to 4 bits per color in the palette, rather
than 8 bits per color. GIF optimisation software allows me to define a custom
palette, and other efficiency measures. In other words, I recommend that you
put gif-animations low on the priority list. I expect that users who want to
make GIF-animations from Graph files already have GIF animation software.
> > All my animations are cyclic animations. When I want to make a 60 frame
> > animation, then in the "Animate dialog box" I specify:
> > From: 0
> > To: 59*2pi/60
> > Step: pi/60
> I am glad to hear that you like it and find it useful.
The reason for the 59/60 is of course to ensure smooth looping. Without it the
first and the last frame of the cyclic animation would be identical.
POV-ray has the following implementation of animation rendering: the default
range is from 0 to 1. The user specifies the range and the number of frames,
and POV-ray then calculates the steps. In addition, the user can choose between
'cyclic' and 'non-cyclic'.
Thankfully it is possible in Graph to enter an expression that evaluates to a
number. If the Animate dialog box would only accept numbers then specifying the
range and the step would be very cumbersome.
Cleon Teunissen
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
RSS Feed