Am 03.11.2016 um 01:22 schrieb omniverse:
> Warp <war### [at] tagpovrayorg> wrote:
>> I would like to know your opinion on these as well:
>>
>> 1) Which one of these images do you think looks more realistic?
>>
>> http://koti.kapsi.fi/warp/media/pov37_test1.png
>> http://koti.kapsi.fi/warp/media/pov37_test2.png
>>
>>
>> 2) Currently, when using assumed_gamma 1 in povray 3.7 mode, default
>> color values in things like the ambient finish do not get adjusted in
>> terms of srgb, but remain in their rgb values (for example, the default
>> ambient finish is "rgb 0.1"), which means that a change in assumed_gamma
>> will affect their brightness.

I would like to add that this has always been the case when using
assumed_gamma 1, so it is not specific to the 3.7 mode, but rather to
the assumed_gamma 1, which had been around in 3.6 already.

>> The second image above was rendered by explicitly specifying the default
>> ambient finish (using the #default directive in the scene file) using
>> "srgb". Without this explicit setting, ie. using the default value, the
>> image looks like this:
>>
>> http://koti.kapsi.fi/warp/media/pov37_test4.png
>>
>> (It's essentially impossible to get any shades are darker than that due to
>> the default ambient finish.)

That is not entirely true: Darkening can also be effected by...

- Setting the "ambient_light" to a lower value, or

- Reducing the pigment colour, and cranking up the illumination of the
portions intended to be brighter.

Also, using radiosity obviously eliminates the problem, and gives more
realistic results anyway.

I don't mean to dispute the fact that the assumed_gamma 1 mode
effectively uses different defaults for ambient than the 3.6 default
mode (in a nutshell, assumed_gamma 1 uses a factor of 0.1, whereas the
3.6 default effectively used a factor of 0.0064 in otherwise pitch black
regions), but I mean to get all the facts on the table.


BTW, some other facts I consider worth mentioning:

- The actual effective ambient factor in 3.6 default mode depended on
various other conditions (thanks to the mathematically incorrect
internal colour computations): In total shadows, and with a white
pigment, the effective factor would indeed be around 0.0064. However,
with a non-white pigment the factor could drop even further (e.g. 0.0027
for an rgb 0.5 pigment), while in brightly lit portions of the image it
could climb to as high as 0.19 instead.

- In 3.6 default mode, the ambient brightness even varied across
operating systems: The effective factor of 0.0064 under standard
conditions given above is true for Windows and, IIRC, Unix machines; on
pre-OS X Mac machines however, the factor would be 0.016 instead.


>> So my question is: Should POV-Ray define default colors (eg. in the ambient
>> finish, and anywhere else where there are default colors) in terms of srgb
>> (which would result in the second image by default, without having to
>> explicitly set those defaults), or is the current functionality ok (which
>> by default results in the third image).

I don't think this style of question is of any help in providing the dev
team with any guidance whatsoever, for various reasons:

- It is not clear to the user whether they are expected to give feedback
on their personal preferences (i.e. ease of use), or whether they are
expected to put them in the dev team's shoes to make a decision.

- Consequently, we don't know what type of feedback the user actually
intends to give.

- Besides, even if we knew a user intends to give feedback on how they
would decide, we have no way of knowing how well-informed that decision
is: We know neither what portion of the entire picture they actually do
have, nor what portion of the picture they're aware they don't have, let
alone what portion of the picture they're entirely unaware of.

You did present the positive effects a change in the defaults would have
on the ease of use, but we must expect the average user to be pretty
much in the dark regarding all other areas to consider, such as how easy
it would be to implement, what pitfalls are to be expect in the process,
what alternative routes could be taken, or even what negative side
effects a change in the defaults might have.


> I must ask, was the scene absolutely identical other than srgb replacing rgb?

As far as http://koti.kapsi.fi/warp/media/pov37_test2.png and
http://koti.kapsi.fi/warp/media/pov37_test4.png are concerned, the info
given by Warp sounds plausible enough for me.

> That reflection on the red and white ball changes drastically from first image.
> Guessing radiosity was not used...?

Even that doesn't seem entirely unreasonable to me.

Just like what is happening with ambient, a similar effect should also
be seen for reflection (and diffuse and highlights) when the parameters
happen to not be set to either 0 or 1.

As mentioned above, in the old 3.6 default mode the effective ambient
factor is boosted unnaturally wherever the scene is illuminated by other
means; in the same manner, reflection should also be boosted unnaturally
wherever the scene is already bright for other reasons.

Therefore, in http://koti.kapsi.fi/warp/media/pov37_test1.png we should
see reflections less drowned out by diffuse than would be realistic.

I'm a bit surprised about the strength of the effect, but it still seems
plausible to me.


> Something that comes to mind about the ambient change is what about emission
> srgb instead of rgb? Wouldn't that be needed as well?

Not really; emission defaults to 0.0, which is one of the two parameter
values entirely unaffected by gamma (the other being 1.0).

But we should theoretically also overhaul the default value for diffuse,
even though it doesn't take a colour; and if we take the issue serious,
all the default include files' finish settings should also be changed
with regard to ambient (or emission), diffuse, specular, phong, and
reflection. Obviously that's non-trivial, since we would want to
continue using the old values in scenes using 3.6 default mode or
assumed_gamma 2.2.


One possible way to bypass the entire issue of default values might be
to add a simple short default include file, say, "linear.inc",
containing something like this:

    #ifndef(LINEAR_INC_TEMP)
    #define LINEAR_INC_TEMP = version;
    #version 3.6;

    #define LINEAR_MODE = on;
    global_settings { assumed_gamma 1.0 }
    default {
      ambient pow(0.1, 2.2)
      diffuse pow(0.7, 2.2)
    }

    #version LINEAR_INC_TEMP;
    #end

Instead of specifying "global_settings { assumed_gamma 1.0 }", users
would then just specify:

    #include "linear.inc"

Default include files could then test for LINEAR_MODE, in which case
they could provide alternative finish definitions to better match
assumed_gamma 1 mode.

This way we could address the problem without even touching the POV-Ray
source code, while at the same time solving problems we couldn't
reasonably address by source code changes alone.

In the include file we could also define a macro or function to
encapsulate pow(x,2.2) for ease of use.


I guess in an ideal world POV-Ray would have always used different
default values in assumed_gamma 1 mode (and yes, Warp, maybe even
various other gamma-related semantic differences), but given that our
timeline branched off that ideal world as early as the release of
POV-Ray 3.6.0, I think the best we can do is go for a reasonable compromise.

Post a reply to this message