 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 20.12.2010 12:38, schrieb Kenneth:
> I think it's presumptuous to assume that I (and undoubtedly others) who use this
> 2.2 method are simply 'not getting it' or that we're 'abusing' gamma for
> artistic purposes simply out of ignorance (or whatever.) Personally, I give this
> topic *much* thought--always comparing what I see in real-life to what I see (or
> think I should see) on a computer screen and in images that I make. It's an
> on-going process for me--and I'm still open to 'correcting' my behavior...but in
> the final analysis, it's my *eyes* that I trust, not technical jargon or dogma.
A similar on-going process happens on the other side of the fence, btw.
Fact is, the pre-3.6 gamma handling (which was actually a non-handling,
based on pure naive ignorance of the issue) was physically wrong, with
no way whatsoever to get it right; "assumed_gamma" was an approach to
fix that (and its intentions were no more than that; it always was
intended as a technical tool, not an artistic one).
Fact is also, the 3.6 assumed_gamma mechanism got deprecated not (or at
least not primarily) because it was wrong (it wasn't; it was incomplete,
and the implementation was partially inconsistent, but as a concept it
would have been a step in the right direction) or still allowed for
"abuse", but due to internal architectural changes - the separation into
a "front-end" and a "back-end", which is a necessary step towards
networked rendering (and also greatly helped to implement multithreaded
rendering). The separation between the two ends was deemed to run right
through the assumed_gamma mechanism.
Another fact is that 3.7 gamma handling originally started out as indeed
effectively forcing "assumed_gamma 1.0" on all new scenes, plus a
differentiating between the File_Gamma and Display_Gamma keywords. That
was all 3.7 gamma handling originally did.
Since then, shortcomings of this approach have been identified and
addressed, such as how to deal with gamma pre-corrected input image
files (which are by far the majority), and how to make life easier for
people who prefer to enter colors in gamma pre-corrected format because
it feels more natural.
Other objective or subjective shortcomings have been identified by now
which will /not/ be addressed in 3.7.0 proper:
- Even with the "gamma" keyword, entering gamma pre-corrected colors is
more cumbersome than would be appropriate (my personal opinion is that
they should be just about as easy to enter as linear colors). However,
they /can/ be entered by now using what I deem a pretty good syntax, so
it was decided to not do anything about this for 3.7.0 (which we can
realistically hope to release soon), and postpone the issue to a later
version.
- Gradients have been on my agenda for quite a while already, but I
hadn't found the time to investigate; nor was I aware that more
"natural-feeling" gradients can be achieved using "poly_wave 2.2". While
being more cumbersome than I'd like, again it /can/ be done, and I still
have it on my personal agenda for a later version.
- Spotlights are another topic, but with those I presume that the
tightness parameter provides enough artistic freedom already.
- Likewise, the smoothness of diffuse illumination on curved surfaces
can be enhanced beyond what's typically realistic simply by using the
brilliance keyword. In a similar manner, the appearance of highlights
can be adjusted via the roughness and phong_size parameters.
- Using gamma adjustment to simulate photographic film non-linearity is
also on my agenda, and for this there is indeed no replacement ATM; but
this clearly falls into the category of post-processing steps, for which
POV-Ray currently has a policy of not doing those. (There are currently
signs that this position may be given up, but in that case there will be
a mechanism to which gamma tweaking is just one of many uses.)
What I'm saying here is that the advocates of the old pre-3.6 model are
not forgotten, and some of their points are (and have already been)
taken quite seriously. The direction will not be to retain assumed_gamma
though, but rather to complement the new gamma handling model with
features to easily achieve the effects asked for.
Finally, here is one more fact: For some file formats (like PNG, OpenEXR
and Radiance HDR), it is to the best of my knowledge /impossible/ to
achieve a well-defined behaviour regarding gamma that suits both
technical and artistic use of a single gamma-handling mechanism. Thus we
/need/ a purely technical gamma handling mechanism if we want to support
physical realim at all, and where this does not fit the needs of people
who prefer artistic freedom we need to find other ways to give back that
freedom.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Render it with pov3.7 without and with the assumed_gamma, and you'll see
> the clear difference. Even though the mid-gray might technically speaking
> be a truly 50% gray, the gradient doesn't still look linear (what is
> supposed to be a smooth gradient fading linearly from white in the center
> to black in the border looks almost like a sphere).
The problem is it's mostly just coincidence that the traditional gamma
2.2 better matches the human perception of "brightness" (IIRC it's
nearer 3 than 2.2 for humans) than no gamma (ie 1.0). This means that
smooth gradients interpolated in gamma 2.2 space will *look* a lot more
"linear" to humans than those interpolated in linear colour space.
There are other colour spaces designed specifically to match the human
response (eg CIELAB), so I think the ideal solution would be for there
to be a keyword to tell POV to use a "human-linear" colour space. This
would then work regardless of gamma setting (which shouldn't be abused
to get a linear looking gradient, because it will mess up the other
lighting calculations).
Anyway without such a feature, POV should be flexible enough to get what
you want without resorting to messing about with gamma settings.
(assuming your goal is a photorealistic scene, if not by all means
fiddle with gamma if it gives you what you want)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> Am 20.12.2010 12:38, schrieb Kenneth:
>
> > Personally, I give this topic *much* thought--always comparing what I see
> > in real-life to what I see (or think I should see) on a computer screen and
> > in images that I make. It's an on-going process for me...
> A similar on-going process happens on the other side of the fence, btw.
No doubt! ;-) It can't be easy, trying to reconcile what might be considered an
'oil and water mix' of different philosophies and requests.
>
> Finally, here is one more fact: For some file formats (like PNG, OpenEXR
> and Radiance HDR), it is to the best of my knowledge /impossible/ to
> achieve a well-defined behaviour regarding gamma that suits both
> technical and artistic use of a single gamma-handling mechanism. Thus we
> /need/ a purely technical gamma handling mechanism if we want to support
> physical realism at all...
Yes, I do see the need for that--having to work by necessity with raw linear
lighting values, AFAIU, and over a *very* large numerical range. (In fact, it's
these particular issues that are driving me toward buying a new high-end camera,
to start experimenting with HDRI in POV-Ray.)
BTW, my ranting screed was most definitely not aimed in your direction, rest
assured. (Sorry if it sounded that way.) Keep those great ideas coming! ;-)
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> - Gradients have been on my agenda for quite a while already, but I
> hadn't found the time to investigate; nor was I aware that more
> "natural-feeling" gradients can be achieved using "poly_wave 2.2". While
> being more cumbersome than I'd like, again it /can/ be done, and I still
> have it on my personal agenda for a later version.
I think that the problem with gradients not looking anywhere even close
to linear by default showcases a more fundamental problem.
When you specify eg. a color_map, without any fine-tuning parameters,
the *default* result should be a color map that looks linear (eg. when
applied to a gradient pattern). Only if you wanted a non-linear mapping
would you specify parameters such as poly_wave with a value different
from 1.0 (the default value of "poly_wave 1.0" means linear mapping).
The problem with the current pov3.7 is that such a gradient is not
looking even close to linear, even with monitors where 'rgb 0.5' is
truly 50% bright, as compared to a test pattern. I don't know why this
is so, but it just isn't.
And it's not just a question of it looking slightly off. Like if you
took an image with a linear gradient created by pov3.6 and looked at it
in different CRT and LCD displays and comparing them to each other
side-by-side, you would probably see slight variations, and you could
make an estimate of which one of them looks the most linear transition,
hence making the others just slightly off. Different people would most
probably choose a different display which they thought produced the most
linear-looking gradient.
No, it's nothing like that. The gradient produced by pov3.7 is very
*clearly* non-linear looking. It's *way* off. It looks very pronouncedly
logarithmic in nature. If you show the gradients created by pov3.6 and
pov3.7 to any random person, there will be no doubt in their choice (yes,
I have actually tested this with a friend).
As said, I don't really know *why* this is so. As I have mentioned,
with my CRT a 'rgb 0.5' as produced by pov3.7 by default looks about
50% gray when compared to a test pattern, so *in theory* a linear
gradient produced by pov3.7 should look linear. But it just doesn't.
A linear pattern produced pov3.6 looks significantly more linear (and,
as I also said, it's not just me, as I have actually tested this with
another person, looking at the same images on the same display).
Anyways, whatever the reason might be, it's undeniable that a problem
exists. What should be producing a linear gradient isn't doing so.
A suggestion like "use 'poly_wave 2.2' in your color map" is not the
correct solution to the problem. It's simply counter-acting the effects
of the gamma correction. What "poly_wave 2.2" is saying is "make the
color transition pronouncedly non-linear, by a power of 2.2" (which is
quite a significant deviation from linear mapping; just compare the
functions "x" and "x^2.2", which is what this is exactly doing).
A suggestion of "use a non-linear mapping to achieve a linear-looking
gradient" is contradictory and shouldn't be the correct answer. A linear
looking gradient should be *the default*.
And it's not just color gradients that are affected by this. It's any
transition from one color to another which should look linear. This
happens in surface lighting, shadow borders when using area lights,
and so on and so forth. (Note that surface lighting very rarely looks
literally linear because the cosine of the angle between the surface
normal and the direction of the light seldom changes linearly, but if
you devised such a surface, it *should* in that case look linear, but
with pov3.7 it won't.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> As said, I don't really know *why* this is so. As I have mentioned,
> with my CRT a 'rgb 0.5' as produced by pov3.7 by default looks about
> 50% gray when compared to a test pattern, so *in theory* a linear
> gradient produced by pov3.7 should look linear.
No it shouldn't - your eye/brain does not see light in a linear fashion.
50% actual brightness from something (as measured in cd/m^2 or
whatever) will *not* look half as bright as 100%. It's no different to
a real scene, light bulbs, or an image on your monitor. It's just the
way your eye/brain works.
An analogy is hearing, a sound with twice the physical power (in Watts)
does not sound twice as loud to a human.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> > As said, I don't really know *why* this is so. As I have mentioned,
> > with my CRT a 'rgb 0.5' as produced by pov3.7 by default looks about
> > 50% gray when compared to a test pattern, so *in theory* a linear
> > gradient produced by pov3.7 should look linear.
> No it shouldn't - your eye/brain does not see light in a linear fashion.
> 50% actual brightness from something (as measured in cd/m^2 or
> whatever) will *not* look half as bright as 100%. It's no different to
> a real scene, light bulbs, or an image on your monitor. It's just the
> way your eye/brain works.
> An analogy is hearing, a sound with twice the physical power (in Watts)
> does not sound twice as loud to a human.
I suppose the fundamental question would then be: "If I say to povray
to produce a linear gradient, should it produce a gradient which is
linear according to light intensity, or according to the perceived
linearity as seen by people?"
What I'm getting at is that when people specify a linear gradient,
they expect to get a gradient that *looks* linear (rather than a gradient
that might be linear as measured by some device that measures light
intensity).
As for whether eg. surface shading looks more realistic with the new
gamma handling or the old one, it would be interesting to see some
actual comparisons with photographs. (Note that I'm *not* saying here
that in my opinion pov3.6 is producing the more closer-to-reality
result while pov3.7 is producing something which is way off. I'm
completely honestly interested in actual comparisons with real-life
photographs, to see which one gets closer, if that would be possible.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I suppose the fundamental question would then be: "If I say to povray
> to produce a linear gradient, should it produce a gradient which is
> linear according to light intensity, or according to the perceived
> linearity as seen by people?"
Agreed, as I wrote already it might be a good idea for an additional
keyword (to be used in colour maps) that specifies whether you want
physical linear interpolation (which will "look" non-linear) or some
other interpolation type suited to the human visual system. This would
be totally separate to any gamma settings, as it has nothing to do with
gamma.
For grey-scales you can already simply use something like "poly_wave 3"
to get a more natural gradient, but once colours are involved it's going
to look wrong without some more sophisticated interpolation algorithm.
> As for whether eg. surface shading looks more realistic with the new
> gamma handling or the old one, it would be interesting to see some
> actual comparisons with photographs.
The problem with that kind of test is that you are also testing the
surface lighting equations used in POV (which are a simplification of
real surfaces). I wasn't aware there was any doubt as to whether the
new gamma was more accurate (you can simply test it with a black/white
checkerboard next to 50% grey).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.12.2010 12:00, schrieb scott:
> Agreed, as I wrote already it might be a good idea for an additional
> keyword (to be used in colour maps) that specifies whether you want
> physical linear interpolation (which will "look" non-linear) or some
> other interpolation type suited to the human visual system. This would
> be totally separate to any gamma settings, as it has nothing to do with
> gamma.
Not sure whether I mentioned it here or not, but such a mechanism has
already been on my agenda for a while (it will not make it into 3.7.0
proper though); the syntax would be something along the lines of
pigment {
gradient y
color_map {
perceptual
[0.0 rgb 0]
[0.5 rgb 1]
[1.0 rgb 0.5]
}
}
(The example also showcases the problem with the poly_wave workaround
you mention, which only works for gradients running from [0.0 rgb 0] to
[1.0 Some_Color].)
Pigment maps will need the same mechanism, btw. I also thought about
whether it would make sense in texture maps, but I guess that's too
complicated to implement, for too little gain.
>> As for whether eg. surface shading looks more realistic with the new
>> gamma handling or the old one, it would be interesting to see some
>> actual comparisons with photographs.
>
> The problem with that kind of test is that you are also testing the
> surface lighting equations used in POV (which are a simplification of
> real surfaces). I wasn't aware there was any doubt as to whether the new
> gamma was more accurate (you can simply test it with a black/white
> checkerboard next to 50% grey).
There's also the problem that photographs may be non-linear as well;
digital cameras aren't typically calibrated, and photographic paper has
non-linearities, too.
A typical reference image would be the Cornell Box (see
http://www.graphics.cornell.edu/online/box/).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Not sure whether I mentioned it here or not, but such a mechanism has
> already been on my agenda for a while (it will not make it into 3.7.0
> proper though);
OOC did you decide already which algorithm to use for this? Will it
give more linear looking gradients between different colours too?
> the syntax would be something along the lines of
>
> pigment {
> gradient y
> color_map {
> perceptual
> [0.0 rgb 0]
> [0.5 rgb 1]
> [1.0 rgb 0.5]
> }
> }
That's exactly the sort of thing I was thinking of. Maybe Warp will
argue that the default should be "perceptual" though, and we need a
"linear" keyword to revert to the existing behaviour.
> There's also the problem that photographs may be non-linear as well;
> digital cameras aren't typically calibrated, and photographic paper has
> non-linearities, too.
I have no idea how well consumer-grade cameras are made, but my camera
has an option for sRGB or Adobe RGB colour space, so I imagine it can't
be that far off either one when selected. Photographic film is probably
worse, IDK.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 21.12.2010 14:45, schrieb scott:
>> Not sure whether I mentioned it here or not, but such a mechanism has
>> already been on my agenda for a while (it will not make it into 3.7.0
>> proper though);
>
> OOC did you decide already which algorithm to use for this? Will it give
> more linear looking gradients between different colours too?
I expect so.
When interpolating between two colors, POV-Ray currently computes
something along the lines of:
q = 1-p;
result = p * color1 + q * color2;
For a "perceptually linear" gradient, the formula would be changed to:
q = 1-p;
temp1 = pow(color1, 1/gamma);
temp2 = pow(color2, 1/gamma);
tempR = p * color1 + q * color2;
result = pow(tempR, gamma);
where gamma would be a value around 2.5.
> That's exactly the sort of thing I was thinking of. Maybe Warp will
> argue that the default should be "perceptual" though, and we need a
> "linear" keyword to revert to the existing behaviour.
... except that he'd even argue that "linear" would be the wrong keyword
for that purpose.
I'll just let him argue then. I'm not reading his newsgroup postings
anyway, as it would ultimately result in the two of us getting mad at
each other. Never put two zealots adhering to contradicting dogmata in
the same room. Fortunately (for me) I'm not in a position of needing to
be heard to get my will.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
