Hi there,

first of all: some background informations. I not a designer or graphics artist.
I am working with an simulation software that has an option to export the
simulation as a video. Therefor it creates 25 pictures per second and saves them
as .pov.

For me Pov-Ray is a blackbox. I put in the .pov files and get out an .jpg.

My problem is, that scaling up the cpu count of my render machine the pure
render time decreases. BUT parsing still takes "forever". In my case parsing
takes about 10 minutes per picture while the render process takes less than a
minute.

Is this a normal phenomen?

I am using the windows version of pov-ray.

While parsing the console all over shows the following message:
"Possible Parse Error: PNG input image default gamma handling has changes for
pre POV-Ray 3.7 scenes; results may diffe from original intention. see the
documentation for more details."

Would it maybe help even help to stop logging this error to the console every
time? If yes how can i do this? Or how can I solve the error itself?

Thanks for you help!

Post a reply to this message

On 12/4/2015 1:59 PM, ILM wrote:
> Hi there,
>
> first of all: some background informations. I not a designer or graphics artist.
> I am working with an simulation software that has an option to export the
> simulation as a video. Therefor it creates 25 pictures per second and saves them
> as .pov.
>
> For me Pov-Ray is a blackbox. I put in the .pov files and get out an .jpg.
>
> My problem is, that scaling up the cpu count of my render machine the pure
> render time decreases. BUT parsing still takes "forever". In my case parsing
> takes about 10 minutes per picture while the render process takes less than a
> minute.
>
> Is this a normal phenomen?
>
> I am using the windows version of pov-ray.
>
> While parsing the console all over shows the following message:
> "Possible Parse Error: PNG input image default gamma handling has changes for
> pre POV-Ray 3.7 scenes; results may diffe from original intention. see the
> documentation for more details."
>
> Would it maybe help even help to stop logging this error to the console every
> time? If yes how can i do this? Or how can I solve the error itself?
>
> Thanks for you help!
>
>
>
>

Hi and welcome.

It all depends what the scene is, how many objects are in it and what 
type of objects. So if you could post one of the files that might help.

Actually you might need to post more than one file if the .pov file 
includes other files, meshes and image files.
Which program is exporting the pov file?

Switching off the messages will not speed things up very much, I would 
think.

-- 

Regards
     Stephen

Post a reply to this message

HI Stephen,

I will see if I can organize a file, that I may upload here. Maybe on Monday.

Until then: It is a logistic simulation tool. Here you can find a final version
of a video provided by the software developers:
https://www.youtube.com/watch?v=Nm3Txr5DRIA

Regarding the log
1) While Parsing the file the CPU usage is only about 30%
2) Do you know how to disable the log just to try it? I tried the -GA command
but it did not work as intended. (the final conclusion disappeard, but the error
messages stayed)
3) What exactly is the error about? Can I fix it?

Regarding the file
1) It is a nearly 10 MB .pov file.

Post a reply to this message

Am 04.12.2015 um 14:59 schrieb ILM:
> Hi there,
> 
> first of all: some background informations. I not a designer or graphics artist.
> I am working with an simulation software that has an option to export the
> simulation as a video. Therefor it creates 25 pictures per second and saves them
> as .pov.
> 
> For me Pov-Ray is a blackbox. I put in the .pov files and get out an .jpg.
> 
> My problem is, that scaling up the cpu count of my render machine the pure
> render time decreases. BUT parsing still takes "forever". In my case parsing
> takes about 10 minutes per picture while the render process takes less than a
> minute.
> 
> Is this a normal phenomen?

Parsing times of 10 minutes are not unheard of; it all depends on how
complex the .pov file is.

I guess that the best way to speed up parsing times is:

(1) Put the .pov files on the fastest drive you have available
(preferably an SSD) and render them from there.

(2) Run multiple renders in parallel. You will need to make sure that
"Options -> Keep Single Instance" is turned off, and then open multiple
POV-Ray windows. (Keep an eye on memory consumption!)

Also, make sure that input images don't have an excessively high
resolution, and that the geometry you're rendering does not have an
excessively high level of detail.


That said, the piece of software you're using to generate the .pov files
may be doing a poor job at creating good, fast-parsing .pov files.

Most notably, POV-Ray provides two different ways of representing
meshes: The older "mesh" format, in which the vertex coordinates and
normal vectors of each triangle are specified directly as explicit
coordinates; and the newer "mesh2" format, in which the vertices and
normal vectors are instead specified indirectly via indices into a table
of the actual vertex and normal vector coordinates. The latter parses
noticeably faster, especially for large meshes -- not only because the
notation is considerably more compact, but also because it is closer to
the data structure POV-Ray uses internally, and therefore some
preprocessing steps can be skipped.

Also, if multiple objects use the same texture properties, maybe the
generating software explicitly writes those properties over and over
again, instead of defining those properties only once and then just
referencing them wherever they are used -- which not only speeds up
parsing time, but can also reduce memory consumption during the render.
This is especially true if the texture properties include input image
files like image maps or bump maps.


> While parsing the console all over shows the following message:
> "Possible Parse Error: PNG input image default gamma handling has changes for
> pre POV-Ray 3.7 scenes; results may diffe from original intention. see the
> documentation for more details."
> 
> Would it maybe help even help to stop logging this error to the console every
> time? If yes how can i do this? Or how can I solve the error itself?

This is unlikely to have any major impact on parsing time: It is output
at most once per PNG input file read from disk, and reading a PNG file
typically takes considerably more time than writing the log message to
the console.

However, if you really get spammed by this message even though you only
have a comparatively small number of input images, it would be an
indication that there's room for optimization in your software that is
generating the .pov files.

Post a reply to this message

> (1) Put the .pov files on the fastest drive you have available
> (preferably an SSD) and render them from there.

Unfortunately this is not an Option right now. but it might be in the future.
>
> (2) Run multiple renders in parallel. You will need to make sure that
> "Options -> Keep Single Instance" is turned off, and then open multiple
> POV-Ray windows. (Keep an eye on memory consumption!)

I will try this.


> Also, make sure that input images don't have an excessively high
> resolution, and that the geometry you're rendering does not have an
> excessively high level of detail.
>
>
> That said, the piece of software you're using to generate the .pov files
> may be doing a poor job at creating good, fast-parsing .pov files.
>
> Most notably, POV-Ray provides two different ways of representing
> meshes: The older "mesh" format, in which the vertex coordinates and
> normal vectors of each triangle are specified directly as explicit
> coordinates; and the newer "mesh2" format, in which the vertices and
> normal vectors are instead specified indirectly via indices into a table
> of the actual vertex and normal vector coordinates. The latter parses
> noticeably faster, especially for large meshes -- not only because the
> notation is considerably more compact, but also because it is closer to
> the data structure POV-Ray uses internally, and therefore some
> preprocessing steps can be skipped.
>
> Also, if multiple objects use the same texture properties, maybe the
> generating software explicitly writes those properties over and over
> again, instead of defining those properties only once and then just
> referencing them wherever they are used -- which not only speeds up
> parsing time, but can also reduce memory consumption during the render.
> This is especially true if the texture properties include input image
> files like image maps or bump maps.

Unfortunately this is nothing we are able to change.


> > While parsing the console all over shows the following message:
> > "Possible Parse Error: PNG input image default gamma handling has changes for
> > pre POV-Ray 3.7 scenes; results may diffe from original intention. see the
> > documentation for more details."
> >
> > Would it maybe help even help to stop logging this error to the console every
> > time? If yes how can i do this? Or how can I solve the error itself?
>
> This is unlikely to have any major impact on parsing time: It is output
> at most once per PNG input file read from disk, and reading a PNG file
> typically takes considerably more time than writing the log message to
> the console.
>
> However, if you really get spammed by this message even though you only
> have a comparatively small number of input images, it would be an
> indication that there's room for optimization in your software that is
> generating the .pov files.

There are only 19 png files from 2 up to 100KB. So you are probably right, that
the Software adresses those files over and over again instead of loading them
once at the beginning.

As the files are really small I still would like to try hiding the error
message. Even this will probably not change anything. This might be the easiest
way to test for. So is there any way to stop the the console printout of the
errors?

Post a reply to this message

On 12/4/2015 5:27 PM, ILM wrote:
> As the files are really small I still would like to try hiding the error
> message. Even this will probably not change anything. This might be the easiest
> way to test for. So is there any way to stop the the console printout of the
> errors?

 From the Help documentation
> 3.2.7.4 Warning Level


> Warning_Level=n 	Allows you to turn off classes of warnings.
> +WLn 			Same as Warning_Level=n


-- 

Regards
     Stephen

Post a reply to this message

Am 04.12.2015 um 17:54 schrieb ILM:

> 3) What exactly is the error about? Can I fix it?

This warning is generated because POV-Ray detected that the .pov file...

- seems to have been designed for POV-Ray 3.6 or older,
- enables gamma handling, and
- loads a PNG as an input image file.

In POV-Ray 3.6, gamma handling did not extend to input image files,
except for /some/ flavours of the PNG format.

Gamma handling has been improved significantly in 3.7, and part of the
improvement includes gamma handling for all input image files; this is a
breaking change, meaning that scenes origially designed for 3.6 would no
longer render as expected, so 3.7 provides a backward compatibility mode
to mimick 3.6's behaviour.

However, due to fundamental architectural changes in 3.7 it would have
been unreasonably difficult to mimick 3.6's input file gamma handling
(or absence thereof) to every little detail, including the
inconsistencies in the handling of PNG images. Instead, POV-Ray 3.7
outputs the warning you are seeing, whenever it is in 3.6 compatibility
mode with active gamma handling and a PNG input image file is loaded, to
indicate that backward compatibility cannot be guaranteed for this case.

To disable the warning, you'd have to modify the .pov file.


Gamma handling is the compensation for a certain quirk of how we
represent colours in computer graphics. In a nutshell, the values stored
for each colour channel typically don't represent brightness levels in a
linear fashion; for instance, when using numeric values of 0 to 255, a
value of 127 (about half the maximum value) typically corresponds to a
brightness level of just about 20% on a linear scale (which happens to
be _perceived_ as about half as bright as the maximum, but physically it
isn't).

The relationship between stored values and the represented linear
brightness levels can be expressed by a formula:

    brightness = f(value/max_value)

Traditionally, the formula used to be a power law, typically written as:

             γ
    f(x) = x

(In case you're having trouble with international symbols, the "γ" above
should be the lower case greek letter gamma.)

Also traditionally, there was no global standard for the gamma parameter
in this formula, and the management of multiple differing standards for
this parameter became known as "gamma handling".

Modern standards for colour representation use a different formula, but
the term is still used in its more general sense of managing different
encoding schemes for brightness levels.

In POV-Ray, gamma handling is of particularly great importance, as the
generation of physically realistic results requires that its internal
computations operate on linear values, while users will typically expect
all material coming into and out of POV-Ray to be non-linearly encoded.
And while the common non-linear encoding schemes are at least somewhat
similar, the difference to linear encoding is significant.


> Regarding the file
> 1) It is a nearly 10 MB .pov file.

That's not a trivial scene, but I've seen .pov files four times that
size parse in less than a minute. My current guess would be that your
.pov file loads an excessive number of PNG files -- or, possibly more to
the point, that it loads a reasonable number of PNG files an excessive
number of times.

Post a reply to this message

Am 04.12.2015 um 19:40 schrieb Stephen:
> On 12/4/2015 5:27 PM, ILM wrote:
>> As the files are really small I still would like to try hiding the error
>> message. Even this will probably not change anything. This might be
>> the easiest
>> way to test for. So is there any way to stop the the console printout
>> of the
>> errors?
> 
> From the Help documentation
>> 3.2.7.4 Warning Level
> 
> 
>> Warning_Level=n     Allows you to turn off classes of warnings.
>> +WLn             Same as Warning_Level=n

I'm a bit surprised that -GA has no effect.

Post a reply to this message

On 12/4/2015 7:43 PM, clipka wrote:
> Am 04.12.2015 um 19:40 schrieb Stephen:
>> On 12/4/2015 5:27 PM, ILM wrote:
>>> As the files are really small I still would like to try hiding the error
>>> message. Even this will probably not change anything. This might be
>>> the easiest
>>> way to test for. So is there any way to stop the the console printout
>>> of the
>>> errors?
>>
>>  From the Help documentation
>>> 3.2.7.4 Warning Level
>>
>>
>>> Warning_Level=n     Allows you to turn off classes of warnings.
>>> +WLn             Same as Warning_Level=n
>
> I'm a bit surprised that -GA has no effect.
>

Yes, it still gives warnings. Warnings have always been shown as long as 
I can remember.

> Preset INI file is 'C:\Users\Stephen\Documents\POV-Ray\v3.7\ini\quickres.ini',
section is '[1024x768, AA 0.3]'.
> Preset source file is 'F:\Graphics\B3D Data\Scenes\Pov Scenes\wax02.pov'.
> Rendering using command line '-ga'.
> Rendering with 12 threads.
> Parse Warning: Linear prism not closed. Closing it.
> Parse Warning: Illegal Value: Scale X by 0.0. Changed to 1.0.
> Parse Warning: Illegal Value: Scale Z by 0.0. Changed to 1.0.
> POV-Ray finished
> -
> CPU time used: kernel 0.55 seconds, user 2.01 seconds, total 2.56 seconds.
> Elapsed time 1.55 seconds, CPU vs elapsed time ratio 1.65.
> Render averaged 508688.23 PPS (307390.32 PPS CPU time) over 786432 pixels.
> ----------------------------------------------------------------------------

Preset INI file is 
'C:\Users\Stephen\Documents\POV-Ray\v3.7\ini\quickres.ini', section is 
'[1024x768, AA 0.3]'.
Preset source file is 'F:\Graphics\B3D Data\Scenes\Pov Scenes\wax02.pov'.
Rendering using command line '-GW'.
Rendering with 12 threads.
Parser Options
   Input file: F:\Graphics\B3D Data\Scenes\Pov Scenes\wax02.pov
   Remove bounds........On
   Split unions.........Off
   Library paths:
     F:\Graphics\B3D Data\Scenes\Pov Scenes
     C:\Users\Stephen\Documents\POV-Ray\v3.7\include\df3prox-0.95
     C:\Users\Stephen\Documents\POV-Ray\v3.7\include
     C:\Windows\Fonts
   Clock value:    0.000  (Animation off)
Image Output Options
   Image resolution.....1024 by 768 (rows 1 to 768, columns 1 to 1024).
   Output file..........F:\Graphics\B3D Data\Scenes\Pov 
Scenes\wax02.png, 24 bpp PNG
   Dithering............Off
   Graphic display......On  (gamma: sRGB)
   Mosaic preview.......Off
   Continued trace......Off
Information Output Options
   All Streams to console..........On
   Debug Stream to console.........On
   Fatal Stream to console.........On
   Render Stream to console........On
   Statistics Stream to console....On
   Warning Stream to console.......Off
Parse Warning: Linear prism not closed. Closing it.
Parse Warning: Illegal Value: Scale X by 0.0. Changed to 1.0.
Parse Warning: Illegal Value: Scale Z by 0.0. Changed to 1.0.



-- 

Regards
     Stephen

Post a reply to this message

On 12/4/2015 4:54 PM, ILM wrote:
> HI Stephen,
>
> I will see if I can organize a file, that I may upload here. Maybe on Monday.
>
Remember to compress it and upload it in a binaries group such as:
povray.binaries.scene-files


> Until then: It is a logistic simulation tool. Here you can find a final version
> of a video provided by the software developers:
> https://www.youtube.com/watch?v=Nm3Txr5DRIA
>

And that tool generates PovRay code. I am surprised. I work in SAP 
logistics (PM &CS). Nice animation.

> Regarding the log
> 1) While Parsing the file the CPU usage is only about 30%
Parsing uses only one core.

> 2) Do you know how to disable the log just to try it? I tried the -GA command
> but it did not work as intended. (the final conclusion disappeard, but the error
> messages stayed)

There is a problem there. I think Clipka will be looking at it.

> 3) What exactly is the error about? Can I fix it?
>

It is not an error but a warning. So don't worry about it.

> Regarding the file
> 1) It is a nearly 10 MB .pov file.
>

See my first comment. Pov files compress very well.

BTW If you are a German speaker. There is an international group on this 
server and Clipka is a bilingual native German speaker.


-- 

Regards
     Stephen

Post a reply to this message