 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't remember if this has been discussed before, but the new gamma
handling might cause headaches when using color maps and other interpolated
maps. For example, consider this scene:
//global_settings { assumed_gamma 2.2 }
camera { location -z*4 look_at 0 angle 35 }
plane
{ -z,0
pigment
{ spherical color_map
{ [0 rgb 0]
[1 rgb 1]
}
}
finish { ambient 1 }
}
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 that if one wants to replicate the "non-gamma-corrected"
look of pov3.6 with this specific pigment, there is no way, other than
making the entire scene assume gamma 2.2, which will then affect *all*
colors. You can't insert a "gamma 2.2" anywhere in that color map to make
it work. (And adding "[0.5 rgb 0.5 gamma 2.2]" will obviously not work.
Try it if you want, without the assumed_gamma.)
I fear that most people will simply learn to always write the magical
line "global_settings { assumed_gamma 2.2 }" at the beginning of every
scene (or whatever will end up being the proper way in the final version),
making the whole gamma correction thing rather moot.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> wrote:
> I don't remember if this has been discussed before, but the new gamma
> handling might cause headaches when using color maps and other interpolated
> maps.
Here's an actual scene where I used the pattern in question:
http://warp.povusers.org/images/glassblob1.jpg
http://warp.povusers.org/images/glassblob2.jpg
Both of the images were rendered with pov3.7 beta. The difference is
that in the first one I used 'assumed_gamma 2.2', while in the second
one I instead applied 'gamma 2.2' to the individual colors and default
ambient.
The gamma correction doesn't only affect the color gradient on the
floor, but naturally also the shading on the spheres. The end result
is that the second image ends up being much brighter (because the
color gradient on the floor is much brighter) and having much less
saturation/contrast than the first one, making it duller and "washed
out", even after all the used colors are matched with the proper gamma
correction. The transition between the illuminated and dark sides of
the spheres is also much more abrupt (due to gamma correction).
The brightness increase is not necessarily all that problematic, but
the visible reduction in saturation/contrast is. It makes the image much
less vivid. The first image may be significantly darker, but the higher
saturation/contrast makes it vivid and lively.
Obviously it's basically impossible to replicate the first image in
pov3.7 without using 'assumed_gamma 2.2', which will then affect all
colors. This may be a problem for many.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 19.12.2010 21:09, Warp wrote:
> I don't remember if this has been discussed before, but the new gamma
> handling might cause headaches when using color maps and other interpolated
> maps.
It has been stated numerous times that assumed_gamma should not be used
for artistic purpose. What you actually want is a non-linear gradient
and there are quite a lot possibilities for this e.g.
pigment {
spherical
poly_wave 2
color_map {
[0 rgb 0]
[1 rgb 1]
}
}
or use a different wave function or write your own function or do
whatever you like but it isn't - and never was - a good idea to misuse
assumed_gamma for such a purpose.
And you did read the message that assumed_gamma is deprecated?
> I fear that most people will simply learn to always write the magical
> line "global_settings { assumed_gamma 2.2 }" at the beginning of every
> scene (or whatever will end up being the proper way in the final version),
> making the whole gamma correction thing rather moot.
>
And I'm well aware that a lot of POV-Ray users (among them some of the
most well known) did in past 3.6 times always write
global_setting {assumed_gamma 1.0}
into the scene file. No trouble for them.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <"ive### [at] lilysoftorg"> wrote:
> On 19.12.2010 21:09, Warp wrote:
> > I don't remember if this has been discussed before, but the new gamma
> > handling might cause headaches when using color maps and other interpolated
> > maps.
> It has been stated numerous times that assumed_gamma should not be used
> for artistic purpose.
You write as if I didn't know that.
The problem is: If you wanted the same vivid high-contrast renders as
you get with assumed_gamma 2.2, but without "abusing" it, how do you do
it in pov3.7? Adjusting individual colors is not going to do it because
it doesn't change gradients, shading and other such interpolated values.
> What you actually want is a non-linear gradient
> and there are quite a lot possibilities for this e.g.
> pigment {
> spherical
> poly_wave 2
> color_map {
> [0 rgb 0]
> [1 rgb 1]
> }
> }
That makes it look closer to the image with assumed_gamma 2.2, but it's
still brighter, for some reason. Compare:
http://warp.povusers.org/images/glassblob1.jpg
http://warp.povusers.org/images/glassblob3.jpg
(Both rendered with pov3.7, the first one uses assumed_gamma 2.2, in the
second one the individual colors have been adjusted, and the poly_wave
function applied to the color map of the floor.)
Of course without the poly_wave specifier, that second image looks like
this:
http://warp.povusers.org/images/glassblob2.jpg
Now tell me, from glassblob2.jpg and glassblob3.jpg, which one of the
circular gradients looks more linear?
Mind you, on my CRT "rgb 0.5", as rendered by pov3.7 without
"assumed_gamma 2.2" (or "gamma 2.2" specified in the color) *does* give
an almost perfect 50% gray, when compared to a test pattern (of
alternating horizontal black and white lines). However, the circular
pattern in the glassblob2.jpg still looks very non-linear, like most of
the circle was an almost even shade of gray, only very slowly darkening
towards the edges, and then abruptly fading to black.
The same is true for the colored spheres: The visible area between
the highlight and the shadow looks almost uniformly colored, with only
a very slow darkening towards the far side of the sphere, and then there's
a quite abrupt transition from that color to the dark shade of the
shadowed part of the sphere. In glassblob1.jpg the darkening is much
more pronounced, giving an impression of higher contrast and saturation.
"assumed_gamma 2.2" might not be intended for artistic purposes, but
can you give an alternative solution to get the same contrast and vivid
saturation of glassblob1.jpg with pov3.7?
What I fear is that the new gamma handling will be mostly abhorred by
people, and everybody will simply turn it off in all of their scenes.
I know that I will most probably do so, the more I use it.
> And you did read the message that assumed_gamma is deprecated?
Of course you could also specify "#version 3.6" to get the same effect,
but I'm not sure if it will affect something else as well.
> > I fear that most people will simply learn to always write the magical
> > line "global_settings { assumed_gamma 2.2 }" at the beginning of every
> > scene (or whatever will end up being the proper way in the final version),
> > making the whole gamma correction thing rather moot.
> >
> And I'm well aware that a lot of POV-Ray users (among them some of the
> most well known) did in past 3.6 times always write
> global_setting {assumed_gamma 1.0}
> into the scene file. No trouble for them.
If people want some type of behavior from povray, shouldn't that behavior
be officially supported in some way, rather than people being forced to do
it via a deprecated method which is officially frowned upon?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> > What you actually want is a non-linear gradient
> > and there are quite a lot possibilities for this e.g.
> > pigment {
> > spherical
> > poly_wave 2
> > color_map {
> > [0 rgb 0]
> > [1 rgb 1]
> > }
> > }
> That makes it look closer to the image with assumed_gamma 2.2, but it's
> still brighter, for some reason.
Should have figure out that to match the assumed_gamma 2.2 version,
I should use "poly_wave 2.2", of course. Now the gradient matches, as
it should, but my other points still stand.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> If people want some type of behavior from povray, shouldn't that behavior
> be officially supported in some way, rather than people being forced to do
> it via a deprecated method which is officially frowned upon?
>
Well-said, and I've lately been having the same thoughts. What bothers me isn't
so much the 'new' gamma handling (which I admit I haven't played around with
yet, because I'm still having great fun with v3.6.1--and assumed_gamma 2.2), but
rather the 'dogmatic' (and somewhat condescending) tone of some of the comments
here and elsewhere, concerning the 'right' or 'wrong' way of dealing with gamma.
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.
It's one thing to *suggest* to us that we should ween ourselves away from gamma
2.2, for legitimate technical reasons; but it's quite another to *impose* it
upon us, especially when accompanied by an annoying 'I'm right, you're wrong'
attitude. If using anything other than assumed_gamma 1.0 is considered 'abuse
for purely artistic reasons', I say "Guilty as charged!" Happily so.
Yet I readily admit that the updated wiki section on gamma is a wonder to
behold--it's a fantastic resource that really makes me *think* about the issue.
And I may yet see the light ;-) *IF* my eyes can convince me.
As to the issue of deprecating assumed_gamma 2.2: Given(?) that it's considered
an 'artistic deviation' by some here, then let us have free reign to use it as
such! I would recommend *removing* the deprecated status (with a warning caveat
of some kind, if necessary.) I really see no harm in this philosophy; POV-Ray is
a *great* artistic tool, a 'Swiss army knife' for scene design and rendering.
Why 'deprecate' a still-useful part of the knife? Not every artist works the
same way with the same tools.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
