Warp <war### [at] tagpovrayorg> wrote:
>   There is a practical example which, while not extremely common, is
> nevertheless very plausible: Rendering a widescreen DVD video.
....
>   Another practical example is a 4:3 monitor with a non-4:3 resolution
....

Yes, I didn't want to go into detail on these. To the best of my knowledge
you're perfectly right on these issues, and a good deal of them is already
mentioned in the FAQ.


> > * Frame Count:
>
> > Instead of using the 0.00-to-1.00 clock, animations may instead use the
> > frame_number for timing reference. In that case, it may be desirable to specify
> > the number of frames not on the command line, but in the SDL file, either to be
> > warned if different values are specified on the command line, or to always
> > override those values.
>
>   I think that causes problems with the frontend-backend division in
> POV-Ray 3.7. The backend, ie. the rendering engine, cannot affect the
> rendering settings (such as animation settings). It's the frontend which
> determines these settings.
>
>   The reason for this is, among other things, support for distributed
> rendering. Distributing, for example, an animation among different machines
> is a duty of the frontend. The frontend cannot do that if the animation
> settings are determined in the SDL file (possibly inside complex scripting,
> which can only be determined by parsing and interpreting the entire file).

This may be true when we're talking about overriding the values; however, even
then it would still allow for checking and *warning* about mismatches in scene
vs. command line / .ini file settings.

Post a reply to this message

clipka wrote:

> Of course, virtually every OS provides *some* way of batch processing. However,
> it would be desirable if this could be done in a way that works with all
> platforms on which POV runs.

It would be really cool to integrate this into SDL itself ;)

#declare MY_TEXTURE = scene
{
   camera {orthographic ...}
   light_source {...}
   plane {...}
}

#declare MY_SCENE = scene
{
   camera {...}
   light_source {...}
   sphere {0,1 pigment {image_map "foo.png"}}
}

render
{
   scene {MY_TEXTURE}
   width  1024
   height 1024
   output_file_name "foo.png"
}

render
{
   scene {MY_SCENE}
   width  1024
   height 768
   output_file_name "myscene.png"
}

This also allows for variables which persist across multiple frames
in animations (done manually using a #while loop). And just imagine
what you can do with macros. Well, better not to hold my breath ;)

Post a reply to this message

=?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
>  Actually, it's almost *never* a 4:3 ratio. Typical formats include:
> 720x576 (PAL), 640x576 (PAL), 480x576 (PAL), 720x480 (NTSC), 640x480
> (NTSC, the only 4:3 format here) and 480x480 (NTSC).

Actually, PAL and NTSC have nothing to do with resolution or aspect ratios -
they're just standards for color encoding in analog TV signals.

(The DVD-formats often maldesignated as PAL and NTSC are in fact EIA 525/60
(NTSC) or CCIR 625/50 (PAL), respectively.)

With Analog TV in turn, it doesn't make *any* sense at all to speak about
horizontal resolution. They only have a certain number of lines per "field",
and a nominal aspect ratio - which as a matter of fact has *always* been 4:3
for *all* non-widescreen formats (even pre-WW2 experimental TV systems often
used 4:3, although 7:3 seems to have been used surprisingly often, too).

Film, on the other hand, has been using a wide variety of formats since its
birth, both for stills and movies: 4:3, 11:8, 5:3, 2:1, 3:2, and probably some
more odds & ends.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> I was thinking about the separation between SDL and command line parameters
> for a few things: ...

This time, clipka, you aren't *enlightened me immensely*.
For this, sorry! :-D

Frankly, the *Image & Pixel Aspect Ratio*, I think it unnecessary, even for a
*Beginner*.

About "Frame Count" and "Batch Render" I am in *loud silence*, for now.


--
Carlo

Post a reply to this message

"Carlo C." <nomail@nomail> wrote in message
news:web.49c35e68a38ff5307cb988ed0@news.povray.org...
> Frankly, the *Image & Pixel Aspect Ratio*, I think it unnecessary, even
for a
> *Beginner*.

Thanks Carlo for speaking up .... I read clipka's post several times and I
kept thinking isn't that what the 'right' keyword is for?

I use this in my camera definition:
right x*image_width/image_height

then all I have to do is  +w1024 +w768 or even +w1600 +900 and bingo!!!

What have I missed?

Jim

Post a reply to this message

Jim Holsenback <jho### [at] hotmailcom> wrote:
> Thanks Carlo for speaking up .... I read clipka's post several times and I
> kept thinking isn't that what the 'right' keyword is for?

> I use this in my camera definition:
> right x*image_width/image_height

> then all I have to do is  +w1024 +w768 or even +w1600 +900 and bingo!!!

> What have I missed?

  You get all the problems inherent with it. They are mentioned in the Q&T
list.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Jim Holsenback <jho### [at] hotmailcom> wrote:
> > Thanks Carlo for speaking up .... I read clipka's post several times and I
> > kept thinking isn't that what the 'right' keyword is for?
>

Thanks for what, Jim?
I am the "last of the last", here. :-D


> > I use this in my camera definition:
> > right x*image_width/image_height
>
> > then all I have to do is  +w1024 +w768 or even +w1600 +900 and bingo!!!
>
> > What have I missed?
>
>   You get all the problems inherent with it. They are mentioned in the Q&T
> list.
>
> --
>                                                           - Warp

Here?
http://tag.povray.org/povQandT/languageQandT.html#aspectratio

--
Carlo

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:49c3918c@news.povray.org...
>   You get all the problems inherent with it. They are mentioned in the Q&T
> list.

Ok ... get it now. There was a passage in the unix help on this subject ....
worded slightly different from the link that Carlo posted.

Warp .... you must be mellowing. With the rookie sounding question like I
posted I should have gotten a RTFM response ;-)

Cheers

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

clipka wrote:
> =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger@free.fr> wrote:
>>  Actually, it's almost *never* a 4:3 ratio. Typical formats include:
>> 720x576 (PAL), 640x576 (PAL), 480x576 (PAL), 720x480 (NTSC), 640x480
>> (NTSC, the only 4:3 format here) and 480x480 (NTSC).
> 
> Actually, PAL and NTSC have nothing to do with resolution or aspect ratios -
> they're just standards for color encoding in analog TV signals.
> 
	Yes, I know that those resolutions aren't in the PAL or NTSC
standards. However, those are the resolutions used by digital TV
(whether DVD or broadcast) when targeting PAL or NTSC displays
respectively.

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknD7Q4ACgkQd0kWM4JG3k82mACeOkIknqWsgEfrPeOvfM8eOQ77
9xQAoK+VaQDCWBKcwg3BvOjTBXNH10rp
=P3Tn
-----END PGP SIGNATURE-----

Post a reply to this message

"Carlo C." <nomail@nomail> wrote:
> This time, clipka, you aren't *enlightened me immensely*.
> For this, sorry! :-D
>
....
>
> About "Frame Count" and "Batch Render" I am in *loud silence*, for now.

I think I need to install some special codec before I can make any sense of
these sentences: I must confess I don't have the slightest clue what you want
to say with either of them.

Post a reply to this message