In POV-Ray for Windows, is is possible to 'access'  command-line settings in
some automatic way, to use later for another purpose? Basically, I would like to
(somehow) #read those settings for subsequent math manipulation or whatever. I
don't mean a simple copy-and-paste routine, manually pasting the parameters into
a scene-- that would be cumbersome for the idea I have-- but rather, some kind
of automatic mechanism that can access the information that's there. I don't see
any particular commands or keywords in the documentation that do such a thing--
i.e., *returning* the information-- but that could be due to my own ignorance
;-)

If the information *is* available via some in-built variable or keyword (similar
to clock or frame_number or etc), then I could simply use the variable in my
scene code-- with no need to copy-and-paste. That's the basic idea, anyway.

Here's the scenario I have in mind: In the render window (after a successful
render), a user can outline a 'partial' rectangular section of the image with
the mouse for a future render. When also using the shift key, this 'creates'
some command-line information and brings up the Command Line Dialog pane, where
the rectangular coordinates can be 'saved' without actually starting the new
render yet.  Those coordinates are what I want for the subsequent render (with
some additional manipulation!) But the command-line info isn't actually 'saved'
anywhere, that I know of, other than on the command line. (The 'save' button
just means 'set but don't render', AFAIK.)

Manually choosing and entering the rectangular coordinates into the command-line
first (as opposed to using the mouse to create them) would defeat the whole
purpose of my idea, which needs to be streamlined and efficient. I want to
create a macro or include file that can be used in any scene, with no need for
hands-on intervention.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> In POV-Ray for Windows, is is possible to 'access'  command-line settings in
> some automatic way, to use later for another purpose?

I would have say that the answer is NO.
Perhaps in a future version, but heck, right now you can't even get the camera
position without going all meta.

And this is yet another reason it would be great to be able to write custom
metadata info to the file header, if the format supports it.

Now - here's an interesting tidbit:

When rendering a subset of columns (+sc/+ec) and/or rows (+sr/+er), POV-Ray
generates a full width image and fills the not rendered columns with black
pixels. This should not be a problem for any image reading program no matter
what file format is used. Earlier versions of POV-Ray had problems when a subset
of rows (+sr/+er) was rendered. The full height information was written into the
image file header but it only wrote image data for those lines that were
actually rendered. This made output files that were incompatible with various
image processing tools. In version 3.7 this is no longer the case.

So, maybe if you set the version back, you'd get the same behaviour?
Or maybe do the experiment in an old version?

Perhaps there's a way to get the start/end columns and rows by looking at that
data.

That's the best I've got at the moment.

Post a reply to this message

Whoops - I was hasty (as usual) and should have kept reading:
(The last paragraph is the key part)

3.2.2.5 Resuming Options
Continue_Trace=bool  Sets continued trace on/off
+C  Sets continued trace on
-C  Sets continued trace off
Create_Ini=file  Generate an INI file to file
Create_Ini=true  Generate file.ini where file is scene name.
Create_Ini=false  Turn off generation of previously set file.ini
+GIfile  Same as Create_Ini=file

If you abort a render while it is in progress or if you used the End_Row option
to end the render prematurely, you can use Continue_Trace=on or +C option to
continue the render later at the point where you left off. This option reads in
the previously generated output file, displays the partial image rendered so
far, then proceeds with the ray-tracing. This option cannot be used if file
output is disabled with Output_to_file=off or -F.

The Continue_Trace option may not work if the Start_Row option has been set to
anything but the top of the file, depending on the output format being used.
Also POV-Ray cannot continue the file once it has been opened and saved again by
any program.

POV-Ray tries to figure out where to resume an interrupted trace by reading any
previously generated data in the specified output file. All file formats contain
the image size, so this will override any image size settings specified. Some
file formats (namely TGA and PNG) also store information about where the file
started (i. e. +SCn and +SRn options), alpha output +UA, and bit-depth +FNn,
which will override these settings. It is up to the user to make sure that all
other options are set the same as the original render.

The Create_Ini option or +GI switch provides an easy way to create an INI file
with all of the rendering options, so you can re-run files with the same
options, or ensure you have all the same options when resuming. This option
creates an INI file with every option set at the value used for that rendering.
This includes default values which you have not specified. For example if you
run POV-Ray with...

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

>
> Earlier versions of POV-Ray had problems when a subset
> of rows (+sr/+er) was rendered. The full height information was written into the
> image file header but it only wrote image data for those lines that were
> actually rendered...
>
> So, maybe if you set the version back, you'd get the same behaviour?
> Or maybe do the experiment in an old version?
>
> Perhaps there's a way to get the start/end columns and rows by looking at that
> data.
>

Strangely enough, I actually read that section in the docs this afternoon,
before posting-- but I didn't 'see' the implications you're talking about.

Yes, it's quite an interesting experiment to try. Until you mentioned it, it
didn't occur to me that POV-Ray might be able to actually #read an image's
header information-- which I assume is just some lines of text? (Although, I
just tried 'loading' a 'typical' JPEG image into POV-Ray, to see what would
happen; all I see are four strange-looking symbols, beginning with what looks
like a y. Maybe the 'true' header info isn't visible?)

For the 'old' behavior of POV-ray, per the new docs, it appears that the header
information may not even be usable anyway ("The FULL height information was
written into the image file header but it only wrote image DATA for those lines
that were actually rendered.") Sounds like one of those pieces of data was
correct, but not the other(?).

I do remember some partial-render problems from the old days, having to do with
such .png images not being viewable in other apps.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Whoops - I was hasty (as usual) and should have kept reading:
> (The last paragraph is the key part)--
>
> The Create_Ini option or +GI switch provides an easy way to create an INI file
> with all of the rendering options... This option
> creates an INI file with every option set at the value used for that rendering.

YES, that will give me what I want. Thanks! I didn't realize that the created
INI file actually included the row and column information of a *partial* render
(the rectangle.) The values are in the 'percentage' format, but I can easily
change those to actual pixel positions later, with some math. (I'll be #read-ing
those values out of the INI file, to stick into a macro.) I haven't used the
#read directive in awhile, so this will be a good opportunity to brush up on
some of my old techniques.

Now I just need to figure out the rest of my code idea!

Thanks again for the important insight.

Post a reply to this message

I wish we could write to file headers too. I make so many test renders 
with small changes, it would be great to be able to document important 
variables.

An alternative would be to write arbitrary text to the screen and have 
it overlay the render. Sort of like #debug, except it shows up in the image.


Mike

Post a reply to this message

On 01/08/2018 08:08, Mike Horvath wrote:
> An alternative would be to write arbitrary text to the screen and have 
> it overlay the render. Sort of like #debug, except it shows up in the 
> image.

screen.inc is what you want, I think.

-- 

Regards
     Stephen

Post a reply to this message

On 2018-08-01 03:08 AM (-4), Mike Horvath wrote:
> An alternative would be to write arbitrary text to the screen and have
> it overlay the render. Sort of like #debug, except it shows up in the
> image.

I do this all the time.  I often write an ad hoc macro incorporating 
screen.inc's Screen_Object() and a text{} or caption.inc object (from 
the Object Collection) to make multiple annotations easier and more uniform.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> The Continue_Trace option may not work if the Start_Row option has been set to
> anything but the top of the file, depending on the output format being used.
> Also POV-Ray cannot continue the file once it has been opened and saved again by
> any program.
>
> POV-Ray tries to figure out where to resume an interrupted trace by reading any
> previously generated data in the specified output file. All file formats contain
> the image size, so this will override any image size settings specified. Some
> file formats (namely TGA and PNG) also store information about where the file
> started (i. e. +SCn and +SRn options), alpha output +UA, and bit-depth +FNn,
> which will override these settings. It is up to the user to make sure that all
> other options are set the same as the original render.

This section in the docs is outdated and not valid for 3.7. The partial image
writing was buggy and not compatible with parallel block-based rendering. In 3.7
the image file isn't written partially. Instead, an intermediate file is used to
hold all rendered blocks and POV-Ray is able to figure out which blocks are
missing and render all those. It doesn't parse any image file format header,
which, btw, are not what you think they are anyway.

Post a reply to this message

On 03/08/2018 18:01, Thorsten Froehlich wrote:
> which, btw, are not what you think they are anyway.


And?...  :)


-- 

Regards
     Stephen

Post a reply to this message