The only difference is the setting of the version and presence or not of
assumed_gamma.

Notice that there is a real difference between 3.7g2 and 3.6. Small, but
it exists.
What is interesting is that in compatibility mode, binary of 3.7 can
match the real 3.6

(the extra letter in 3.6 file name are for 3.7 in 3.6 mode, shorter
version are done by the true 3.6.1 )




#default{ finish { ambient 1 diffuse 0 reflection 0} }
camera { orthographic location -20*z
up 14*y
right 14*x
look_at 0
}

text{ ttf "verdana"  TEX 1,0 texture { pigment { color rgb 1 } }
translate <-6,5,-5> no_shadow }
light_source { <-10,30,-50>*10, 2/3 }
light_source { <-30,10,-50>*10, 1/3 }
#declare FIRST=1;
#declare SECOND=2/3;
#declare THIRD=1/3;
sphere { -3*x,1 texture { pigment { color rgb <1,0.25,0.5>*FIRST } }
translate +3*y }
sphere { -3*x,1 texture { pigment { color rgb <1,0.25,0.5>*SECOND } } }
sphere { -3*x,1 texture { pigment { color rgb <1,0.25,0.5>*THIRD } }
translate -3*y }
sphere { 0,1 texture { pigment { color rgb <0.25,0.5,1>*FIRST } }
translate +3*y }
sphere { 0,1 texture { pigment { color rgb <0.25,0.5,1>*SECOND } } }
sphere { 0,1 texture { pigment { color rgb <0.25,0.5,1>*THIRD } }
translate -3*y }
sphere { 3*x,1 texture { pigment { color rgb <0.5,1,0.25>*FIRST } }
translate +3*y }
sphere { 3*x,1 texture { pigment { color rgb <0.5,1,0.25>*SECOND } } }
sphere { 3*x,1 texture { pigment { color rgb <0.5,1,0.25>*THIRD } }
translate -3*y }

sphere { -6*x,1 texture { pigment { color rgb <1,0.5,0.25>*FIRST } }
translate +3*y }
sphere { -6*x,1 texture { pigment { color rgb <1,0.5,0.25>*SECOND } } }
sphere { -6*x,1 texture { pigment { color rgb <1,0.5,0.25>*THIRD } }
translate -3*y }
sphere { 6*x,1 texture { pigment { color rgb <0.5,0.25,1>*FIRST } }
translate +3*y }
sphere { 6*x,1 texture { pigment { color rgb <0.5,0.25,1>*SECOND } } }
sphere { 6*x,1 texture { pigment { color rgb <0.5,0.25,1>*THIRD } }
translate -3*y }

sphere { -6*y,1 texture { pigment { color rgb <0.25,1,0.5>*FIRST } }
translate +3*x }
sphere { -6*y,1 texture { pigment { color rgb <0.25,1,0.5>*SECOND } } }
sphere { -6*y,1 texture { pigment { color rgb <0.25,1,0.5>*THIRD } }
translate -3*x }

sphere { 6*y,1 texture { pigment { color rgb 1*FIRST } } translate +3*x }
sphere { 6*y,1 texture { pigment { color rgb 1*SECOND } } }
sphere { 6*y,1 texture { pigment { color rgb 1*THIRD } } translate -3*x }

sphere { -4.5*x,0.5 texture { pigment { color rgb <1,1,0>*FIRST } }
translate +3*y }
sphere { -4.5*x,0.5 texture { pigment { color rgb <1,1,0>*SECOND } }  }
sphere { -4.5*x,0.5 texture { pigment { color rgb <1,1,0>*THIRD } }
translate -3*y }

sphere { -1.5*x,0.5 texture { pigment { color rgb <1,0,1>*FIRST } }
translate +3*y }
sphere { -1.5*x,0.5 texture { pigment { color rgb <1,0,1>*SECOND } }  }
sphere { -1.5*x,0.5 texture { pigment { color rgb <1,0,1>*THIRD } }
translate -3*y }

sphere {  1.5*x,0.5 texture { pigment { color rgb <0,1,1>*FIRST } }
translate +3*y }
sphere {  1.5*x,0.5 texture { pigment { color rgb <0,1,1>*SECOND } }  }
sphere {  1.5*x,0.5 texture { pigment { color rgb <0,1,1>*THIRD } }
translate -3*y }

sphere { 4.5*x,0.5 texture { pigment { color rgb <1,0,0>*FIRST } }
translate +3*y }
sphere { 4.5*x,0.5 texture { pigment { color rgb <1,0,0>*SECOND } }  }
sphere { 4.5*x,0.5 texture { pigment { color rgb <1,0,0>*THIRD } }
translate -3*y }

sphere {  1.5*y,0.5 texture { pigment { color rgb <0,1,0>*FIRST } }
translate +3*x }
sphere {  1.5*y,0.5 texture { pigment { color rgb <0,1,0>*SECOND } } }
sphere {  1.5*y,0.5 texture { pigment { color rgb <0,1,0>*THIRD } }
translate -3*x }

sphere { -1.5*y,0.5 texture { pigment { color blue 1*FIRST } } translate
+3*x }
sphere { -1.5*y,0.5 texture { pigment { color blue 1*SECOND } } }
sphere { -1.5*y,0.5 texture { pigment { color blue 1*THIRD } } translate
-3*x }

Post a reply to this message

Attachments:
Download 'col37g235.png' (52 KB) Download 'col36g1s.png' (54 KB) Download 'col36a.png' (48 KB) Download 'col37g1.png' (54 KB) Download 'col36g1.png' (54 KB) Download 'col37.png' (53 KB) Download 'col36.png' (49 KB)

Preview of image 'col37g235.png'

Preview of image 'col36g1s.png'

Preview of image 'col36a.png'

Preview of image 'col37g1.png'

Preview of image 'col36g1.png'

Preview of image 'col37.png'

Preview of image 'col36.png'

Am 18.10.2016 um 22:35 schrieb Le_Forgeron:
> The only difference is the setting of the version and presence or not of
> assumed_gamma.
> 
> Notice that there is a real difference between 3.7g2 and 3.6. Small, but
> it exists.

I would expect those differences to be the result of not having
explicitly specified "File_Gamma".

"File_Gamma" was introduced to allow for more flexibility in output
generation, namely to create output files with a different gamma
pre-correction or gamma encoding than the "Dispaly_Gamma".

Rather than having "File_Gamma" default to "Display_Gamma", it was
decided to have it default to the official recommendation for whatever
file format is chosen. Since this is sRGB for all modern file formats
supported by POV-Ray 3.6, and Display_Gamma would typically be set to
2.2, the difference is typically minute and was therefore considered
acceptable, especially since explicitly setting "File_Gamma" identical
to "Display_Gamma" easily achieves the traditional behaviour.

Post a reply to this message

Seeing this I began trying to find out if the File_Gamma=srgb I just began using
recently was making a difference from File_Gamma=2.2 I had been using prior to
that.

Well, that wasn't the thing that caused me a tremendous surprise because I was
only seeing a real change if using assumed_gamma=1 for global_settings instead
of srgb I also started using for that. A brightened image, as expected, which is
why I had trouble with the idea of the necessity of adding it to all my scene
files the many years ago now.

However in the process of changing these I also added the INI option
Antialias_Gamma for the first time. I didn't know about it, or ignored it, until
reading here and C. Lipka I think mentioned it.

By using Antialias_Gamma=1 in my povray.ini the rendering I was testing all this
with went from over a minute (plus 3 to 10 seconds) to only 20 seconds!!!

I put 2 of those images together or overlayed, one with and one without that
option, applied as differences between them and it didn't show anything. No
differences visible.

So I must ask, is that to be expected?

In the meantime I'm going to be trying longer renders in the hopes it might
reduce all their times to 1/3!

Post a reply to this message

Didn't tell version being used here, sorry.

3.7.1-alpha.8820458+av228.msvc14.win64

Checked another scene, potential pattern blob scene file I was testing a few
days ago, and found half the render time for it.
Once again, this is with Antialias_Gamma=1 added to the povray.ini, and I'm also
using srgb for File_Gamma and assumed_gamma, along with that keyword for all
colors. Just in case that matters.

Post a reply to this message

Am 19.10.2016 um 07:13 schrieb omniverse:

> Seeing this I began trying to find out if the File_Gamma=srgb I just began using
> recently was making a difference from File_Gamma=2.2 I had been using prior to
> that.
> 
> Well, that wasn't the thing that caused me a tremendous surprise because I was
> only seeing a real change if using assumed_gamma=1 for global_settings instead
> of srgb I also started using for that. A brightened image, as expected, which is
> why I had trouble with the idea of the necessity of adding it to all my scene
> files the many years ago now.

This is to be expected /if/ you were using PNG output.

Most image file formats require that the generating software encodes the
image data to match the viewing system's gamma. This is what is known as
"gamma pre-correction". If the generating software encodes for a
different gamma, the viewing system will display the image differently.

The PNG file format, on the other hand, allows the generating software
to choose an encoding gamma independently, and store the chosen gamma in
the file header; it is then up to the viewing system to read that gamma
information, and decode the data accordingly. Provided the decoding
software supports this mode of operation, it can therefore properly
display the image data in the same manner no matter the encoding gamma.


> By using Antialias_Gamma=1 in my povray.ini the rendering I was testing all this
> with went from over a minute (plus 3 to 10 seconds) to only 20 seconds!!!
> 
> I put 2 of those images together or overlayed, one with and one without that
> option, applied as differences between them and it didn't show anything. No
> differences visible.
> 
> So I must ask, is that to be expected?

I'm a bit surprised about the magnitude, but I consider it possible, as
changing "Antialias_Gamma" also changes the effective anti-aliasing
threshold, though the effect also depends on the absolute brightness of
the colours.

However, with the symptoms observed you should be able to get about the
same speedup in render times by choosing a higher anti-aliasing
threshold, also without loss of quality.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 19.10.2016 um 07:13 schrieb omniverse:
>
> > Seeing this I began trying to find out if the File_Gamma=srgb I just began using
> > recently was making a difference from File_Gamma=2.2 I had been using prior to
> > that.
> >
> > Well, that wasn't the thing that caused me a tremendous surprise because I was
> > only seeing a real change if using assumed_gamma=1 for global_settings instead
> > of srgb I also started using for that. A brightened image, as expected, which is
> > why I had trouble with the idea of the necessity of adding it to all my scene
> > files the many years ago now.
>
> This is to be expected /if/ you were using PNG output.
>
> Most image file formats require that the generating software encodes the
> image data to match the viewing system's gamma. This is what is known as
> "gamma pre-correction". If the generating software encodes for a
> different gamma, the viewing system will display the image differently.
>
> The PNG file format, on the other hand, allows the generating software
> to choose an encoding gamma independently, and store the chosen gamma in
> the file header; it is then up to the viewing system to read that gamma
> information, and decode the data accordingly. Provided the decoding
> software supports this mode of operation, it can therefore properly
> display the image data in the same manner no matter the encoding gamma.
>
>
> > By using Antialias_Gamma=1 in my povray.ini the rendering I was testing all this
> > with went from over a minute (plus 3 to 10 seconds) to only 20 seconds!!!
> >
> > I put 2 of those images together or overlayed, one with and one without that
> > option, applied as differences between them and it didn't show anything. No
> > differences visible.
> >
> > So I must ask, is that to be expected?
>
> I'm a bit surprised about the magnitude, but I consider it possible, as
> changing "Antialias_Gamma" also changes the effective anti-aliasing
> threshold, though the effect also depends on the absolute brightness of
> the colours.
>
> However, with the symptoms observed you should be able to get about the
> same speedup in render times by choosing a higher anti-aliasing
> threshold, also without loss of quality.

Hadn't thought about the file format being a factor I always used PNG though,
sometimes JPG.

Post a reply to this message