Kenneth wrote:
> That's true; but as I read it, POV's discusion of that keyword treats it
> more as a "special effect" than as a fundamental tool for adjusting the
> surface reflectance of lighting on an object (actually, it would have to be
> ALL objects) in a scene.

That's because that's what it is. POV-Ray's default diffuse reflection 
calculation (with brilliance 1) is based on a (simplified) physical 
model (that says "of the total light power incident on every small 
surface piece, a constant fraction is absorbed, and the rest is 
uniformly reflected in all directions"). The physical interpretation of 
a surface with only diffuse reflection and a brilliance greater than 1 
on the other hand would be that less light is reflected (i.e. absorption 
is stronger) for shallow incidence than near normal incidence, and I 
doubt that's a property than many real-world surfaces have. Brilliance 
was introduced as an artistic tool, without any claims of physically 
based "realism". (If near-specular reflection, i.e. highlights, are 
taken into account, however, it may indeed be that the reflective 
properties of some surfaces are best approximated by a brilliance 
different from 1. Say, a diffusely reflecting surface beneath a thin 
varnish coat that specularly reflects more light at shallow angles 
(Fresnel reflection), leaving less for the diffuse reflector below.)

Applying such a feature indifferently to all surfaces in a scene, no 
matter what material, makes no sense IMO, if the goal is realism. You 
can still do it if you like by adjusting the default texture (see 
<http://www.povray.org/documentation/view/3.6.1/239/>):

#default { finish { brilliance 1.7 } }

> The interesting thing to me is that the default value is 1.0 (the
> value used when it isn't specified.) I'm guessing this is because
> assumed_gamma is recommended to be 1.0 as well. And when it is, then
> making brilliance equal to display_gamma (or system/monitor
> gamma)..as you suggested...does indeed produce "realistic" 
> light/object interaction (the way I like to see it, anyway.)

That's purely a coincidence. I still haven't checked the source to see 
how brilliance works exactly (the documentation doesn't mention it), but 
the easiest way to do it would be a power function. Since a power 
function with exponent 1 is identity, using 1.0 has the same effect as 
if the feature didn't exist at all. And since assumed_gamma (by 
coincidence) is used in the exponent of a power function as well, 
brilliance is able to cancel its effect.

> Ah, this is where we "see" things fundamentally differently. :-) Based on
> how light seems (to me) to interact with objects I look at, I think that
> assumed_gamma of 1.0 actually DOESN'T create "an approximation to
> real-world surfaces"--without using the various SDL  tweaks so far
> discussed, anyway. (And I'm not totally convinced that ALL the "anomolies"
> I see can be completely eliminated this way; don't know.)  It's
> strange--yet interesting!--that we have such a different take on this.

Yes, that's interesting. I have to say that Ard's first sample image 
doesn't look nearly as wrong to me as it seems to look to you. If I 
imagine standing in a completely darkened room with one bright point 
light source and a dull white painted ball, I indeed expect to see 
something more like the upper than the lower image. Or consider the 
first-quarter moon. It's approximately a diffusely reflecting sphere 
illuminated from a single direction in an otherwise dark space - and 
doesn't it look more like the upper image than the lower one?

> But I have to assume that (many?) others are in your camp, so to
> speak. (This is why I was hoping to have a sort of "roundtable
> discussion" of lots of users' opinions of Ard's two images.) I
> wonder--is the POV community equally divided on this particular
> issue, or am I one of the few wandering madmen??

I'd be interested in that too - I'd guess the latter, not because I 
consider you a madman :), but because I think POV-Ray's "numerical" user 
interface (as opposed to the "graphical" way other 3D applications work) 
appeals more to "scientist" types than to "artist" types.

>>>Photoshop is, in effect, insulating me from the need to worry
>>>about gamma correction. A beautiful, intuitive way of working!!
>>Right, but I suspect this is more by accident than by design.
> That's, I believe, a feature BY design, in order for it to be an
> easy-to-use, intuitive WYSIWYG graphics program...one of its big original
> selling points.

I disagree. The habit of encoding intensity by a power function rather 
than linearly (I call this "gamma encoding") was there before Photoshop. 
It originated from the fact that it approximately models the response of 
a CRT to the applied voltage. The video hardware of the first computer 
displays just linearly converted 127 to "half the voltage", and with 
that voltage the CRT phosphors happened to glow with about 20% of full 
intensity, which happens to be about "half the perceived brightness". 
That's a nice coincidence, and it's the reason why we still use gamma 
encoding even though nobody does a straight linear conversion from video 
memory values to CRT voltage anymore.

>>>...and then re-massaged THOSE values before spitting them back to the
>>>monitor, so that they appeared perceptually correct in the user's
>>>chosen gamma environment?
>>
>>POV-Ray already does that (if you use assumed_gamma 1).
> 
> Hmm. Again, I think (?) we're possibly coming at that from two different
> perspectives...your's physically-based, mine artistically (or perceptully)
> based. I disagree, using my "linear-value" grey-band test scene as a prime
> example.

I think you're misunderstanding me. I'm talking about what POV-Ray does 
at the output end, assuming that you feed it what it expects at the 
input end. Unlike other points in our discussion, there's no place for 
disagreement here. These are facts.

POV-Ray interprets the 0.5 in the middle of your gray-band as "half the 
intensity" (that's not what you meant it to be, but that's just the way 
POV-Ray works). It then calculates 255*0.5^(assumed_gamma/display_gamma) 
= 186 (assuming that your display_gamma is 2.2 and assumed_gamma is 1) 
and writes that value to the output file. When the file is displayed, 
that value is copied into video memory and makes your screen pixels glow 
with (186/255)^2.2 = 0.5 of full intensity (assuming your display is 
properly calibrated to a gamma of 2.2). That's the correct value, given 
what was input at the beginning, even though it's not "half the 
perceptual brightness".

Of course, in the gray band test, if you pretend that POV-Ray interprets 
0.5 as "half the perceptual brightness" and use assumed_gamma = 
display_gamma, the correct result (a pixel glowing with "half the 
perceptual brightness") comes out too - but as soon as any physical 
lighting calculations have to be done, such as in the sphere test, their 
results will be incorrect, because linear-to-perceived-brightness 
numbers are put into formulas intended for linear-to-intensity numbers. 
(But you seem to like the incorrect results better than the correct 
ones, and I can't argue with that.)

>>>(Of course, my own use of assumed_gamma of 2.0 mimics that behavior!
>>>But as has been pointed out, that's not the correct way of working.
>>>A real conundrum.)

It just occurs to me that the assumed_gamma feature (whose purpose I've 
never really understood, given that there's only one correct value for 
it in my view of POV-Ray as a light physics simulator) may have been 
introduced just for what you're trying to do - making POV-Ray interpret 
the numbers it's given not as linear-to-intensity, but as something 
else, e.g. linear-to-perceived-brightness. Unfortunately that just 
doesn't work correctly the way it's currently implemented. Such a 
feature should affect the input end (before the physical calculations 
are done), while the current implementation affects the output end 
(after the calculations).

> A most interesting discussion!!

I agree - but it's starting to take way too much of my time :). I'll try 
hard to keep my further answers a bit shorter. But I think most of the 
points I wanted to make have been made by now anyway.

  -Christian

Post a reply to this message