 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10-9-2011 18:58, Alain wrote:
>
> Almost all colour pickers, like the ones in Gimp or Paint, work in sRGB
> space. They assume a source encoded in sRGB space and return a value
> that is assumed to be used in the sRGB space.
> Just try picking colour for 25%, 50% and 75% grays and see the actual
> results...
I must admit that the whole issue is very confusing to me.
Not using grays in my example, but picking the following vector in Gimp:
<213, 127, 79>/255 and rendered in POV-Ray as rgb or srgb give
different results from the original (see image in p.b.i.). So, what is
correct? My gamma settings are not an issue as they are correctly set by
the way.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
> Not using grays in my example, but picking the following vector in Gimp:
> <213, 127, 79>/255 and rendered in POV-Ray as rgb or srgb give
> different results from the original (see image in p.b.i.). So, what is
> correct? My gamma settings are not an issue as they are correctly set by
> the way.
What are your gamma settings in POV-Ray?
If you want the color <213, 127, 79>/255 to correspond to the on-screen
pixel value <213, 127, 79>, you'll have to use an assumed_gamma of 2.2
(which is the default).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11-9-2011 9:37, Warp wrote:
> What are your gamma settings in POV-Ray?
>
> If you want the color<213, 127, 79>/255 to correspond to the on-screen
> pixel value<213, 127, 79>, you'll have to use an assumed_gamma of 2.2
> (which is the default).
>
Display_Gamma = sRGB
global_settings {assumed_gamma 1.0}
I understand from the documentation that this last one should always be
kept at 1 "for maximum realism" which is what I want. Using 2.2 or srgb
instead make the colors darker, but if the image is loaded in Gimp for
example, the colors do not match up with the initial ones. Neither with
assumed_gamma 1 I must add. So, fundamentally, something is changed in
between...
I give up. The matter is really going way beyond my understanding... :-(
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
> I understand from the documentation that this last one should always be
> kept at 1 "for maximum realism" which is what I want.
Well, the subject is quite complicated.
The "maximum realism" comes from how lighting is calculated. When, for
example, light reflects from surfaces, the amount of reflection (which
depends, among other things, on the angle between the surface and the
incoming light) affects the amount of energy that reflects from the surface.
In other words, if the surface reflects 50% of the incoming light (due to
the surface properties and the angle of incidence), it will reflect 50% of
the incoming energy (measured in watts).
This is different from what the human eye *perceives*. You see, 50% of
light (as measured in watts) does *not* look half as bright to the human
eye. This is because the visual perception of light is far from linear
with respect to the amount of watts that hit the eye. Instead, it looks
much brighter (the perceived brightness is more like 70% than 50% of the
original).
On the other hand, display devices aren't linear with respect to brightness
either. This means that a pixel value of (128,128,128) does *not* send half
the watts as a pixel value of (255,255,255). The relation between pixel values
and the amount of watts that the display emits isn't linear either.
Curiously (although I don't know if coincidentally), the brightness curve
of displays (at least those with a gamma of 2.2) is relatively close to the
perception curve of the human eye. This means that a pixel value of
(128,128,128) *looks* to the human eye approximately half as bright as a
pixel value of (255,255,255).
That means that if you want "rgb 0.5" to *look* about 50% gray, then the
proper assumed_gamma is 2.2. This will cause povray to generate pixel values
of about (128,128,128) for that color (plus whatever modification lighting
causes to it, of course). Your monitor won't be emitting 50% of the watts
compared to pure white (which can be corroborated by comparing to an image
pattern that does, on average, send 50% of the watts), but your visual
perception of those pixels will be about 50% of that full white.
The technical problem with using assumed_gamma 2.2 is that now surfaces
will reflect the wrong amount of light. (This is, AFAIK, a common problem
in all renderers, except perhaps the very accurate unbiased ones.)
In most cases this isn't really a huge problem, though. The human eye is
very forgiving of such deviations from reality.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 10:14, schrieb Thomas de Groot:
>> If you want the color<213, 127, 79>/255 to correspond to the on-screen
>> pixel value<213, 127, 79>, you'll have to use an assumed_gamma of 2.2
>> (which is the default).
>>
Nonsense!
> Display_Gamma = sRGB
> global_settings {assumed_gamma 1.0}
>
Yes. Thats definitely how it should be when you are aiming for a
(photo)realistic render.
> I understand from the documentation that this last one should always be
> kept at 1 "for maximum realism" which is what I want. Using 2.2 or srgb
> instead make the colors darker, but if the image is loaded in Gimp for
> example, the colors do not match up with the initial ones. Neither with
> assumed_gamma 1 I must add. So, fundamentally, something is changed in
> between...
>
A precise description what these color patches are actually representing
would be helpful. Currently I have no idea what they are and how you
would expect them to look like.
> I give up. The matter is really going way beyond my understanding... :-(
Don't do this. Actually this isn't a complicated matter. What makes it
appear complicated is the amount of wrong informations and even worse
half true statements as sadly frequently given within this newsgroup.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Not using grays in my example, but picking the following vector in
> Gimp: <213, 127, 79>/255 and rendered in POV-Ray as rgb or srgb give
> different results from the original (see image in p.b.i.). So, what
> is correct? My gamma settings are not an issue as they are correctly
> set by the way.
>
> Thomas
>
Hmmm... I usually get confused with these matter too, so I just did
use my best skill: trial&error. I've created a simple scene with :
background{rgb <213,127,79>/255}
Rendered with +FN, I got a png which I loaded it into the Gimp to pick
the color: <213,127,79>. :O
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <ive### [at] lilysoft org> wrote:
> Am 11.09.2011 10:14, schrieb Thomas de Groot:
> >> If you want the color<213, 127, 79>/255 to correspond to the on-screen
> >> pixel value<213, 127, 79>, you'll have to use an assumed_gamma of 2.2
> >> (which is the default).
> >>
> Nonsense!
It isn't. This is actually very easy to verify. Just use a very simple
scene like this:
global_settings { assumed_gamma 2.2 }
background { rgb <213, 127, 79>/255 }
When I rendered that, the image file ended up full of pixels with the
value (214, 128, 78) (granted, not *exactly* the original values, but a
difference of one isn't exactly large, and accounted for by rounding errors).
In contrast this:
global_settings { assumed_gamma 1.0 }
background { rgb <213, 127, 79>/255 }
produces an image full of pixels with the value (253, 187, 151).
Gamma correction is a bit wonky like that.
> > Display_Gamma = sRGB
> > global_settings {assumed_gamma 1.0}
> >
> Yes. Thats definitely how it should be when you are aiming for a
> (photo)realistic render.
It's just that if you do that, you'll have to pre-gamma-correct all your
input colors if you are choosing them from an external program. The external
program will use raw pixel values, and they will have to be pre-gamma-corrected
with the gamma factor 2.2 if you want them to look the same in povray with an
assumed gamma of 1.0.
Also, linear gradients won't look linear (at least not currently).
(They are linear in terms of the energy they emit, but not in their
perceived brightness.) This can be a bit of a problem when designing
textures which should have a certain *look*, rather than having a certain
emission function. (The relationship between emitted energy and perceived
brightness is roughly logarithmic, and the exponent is approximately 2.2,
which happens to coincide with most displays.)
> Don't do this. Actually this isn't a complicated matter. What makes it
> appear complicated is the amount of wrong informations and even worse
> half true statements as sadly frequently given within this newsgroup.
It *is* a complicated subject, and there indeed is a lot of misinformation
out there. A common misunderstanding is the relationship between absolute
brightness (the amount of energy that a pixel with a certain value emits,
mesured in watts) and the *perceived* brightness (which is what it looks
like to the human eye). This relationship is far from linear.
The question is: Do you want "rgb 0.5" to emit half of the energy than
"rgb 1.0" (in which case you should use assumed_gamma 1.0), or do you want
"rgb 0.5" to *look* half as bright as "rgb 1.0" (in which case you should
use assumed_gamma 2.2)?
You can make "0.5" to look half-gray even with an assumed_gamma of 1.0
by pre-gamma-correcting it (in which case you would have to use
pow(0.5, 2.2) = 0.218), and in theory all the surface lighting will be
more accurate (because they will deal with the absolute light energy,
rather than perceived brightness), but as said, you will stumble across
problems when designing textures (eg. because linear gradients won't look
linear) and other such things related to colors.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jaime Vives Piqueres <jai### [at] ignoranciaorg> wrote:
> Hmmm... I usually get confused with these matter too, so I just did
> use my best skill: trial&error. I've created a simple scene with :
> background{rgb <213,127,79>/255}
> Rendered with +FN, I got a png which I loaded it into the Gimp to pick
> the color: <213,127,79>. :O
POV-Ray 3.7 uses (now) a default assumed_gamma of 2.2, which perfectly
explains that.
If you specified an assumed_gamma of 1.0 you would get a completely
different result (namely <236, 187, 151>, plusminus one).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> In contrast this:
> global_settings { assumed_gamma 1.0 }
> background { rgb <213, 127, 79>/255 }
> produces an image full of pixels with the value (253, 187, 151).
Typo. Should have been (236, 187, 151).
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 13:40, schrieb Warp:
> Ive<ive### [at] lilysoftorg> wrote:
>> Am 11.09.2011 10:14, schrieb Thomas de Groot:
>
>>>> If you want the color<213, 127, 79>/255 to correspond to the on-screen
>>>> pixel value<213, 127, 79>, you'll have to use an assumed_gamma of 2.2
>>>> (which is the default).
>>>>
>> Nonsense!
>
> It isn't. This is actually very easy to verify. Just use a very simple
> scene like this:
>
> global_settings { assumed_gamma 2.2 }
> background { rgb<213, 127, 79>/255 }
>
> When I rendered that, the image file ended up full of pixels with the
> value (214, 128, 78) (granted, not *exactly* the original values, but a
> difference of one isn't exactly large, and accounted for by rounding errors).
>
> In contrast this:
>
> global_settings { assumed_gamma 1.0 }
> background { rgb<213, 127, 79>/255 }
>
> produces an image full of pixels with the value (253, 187, 151).
>
> Gamma correction is a bit wonky like that.
>
I'm really tired of this. When you wish to feed POV-Ray with sRGB values
then use srgb <whatever color> no need to *try* it.
>>> Display_Gamma = sRGB
>>> global_settings {assumed_gamma 1.0}
>>>
>> Yes. Thats definitely how it should be when you are aiming for a
>> (photo)realistic render.
>
> It's just that if you do that, you'll have to pre-gamma-correct all your
> input colors if you are choosing them from an external program. The external
> program will use raw pixel values, and they will have to be pre-gamma-corrected
> with the gamma factor 2.2 if you want them to look the same in povray with an
> assumed gamma of 1.0.
>
You do not have to *pre*-gamma-correct you have to *de*-gamma-correct
and this is not nitpicking, this is a completely different meaning.
As I've already have stated: when you wish to feed POV-Ray with sRGB
values then use srgb <whatever color> and POV-Ray will de-gamma-correct
it for you.
I for one do *never* use (and I do not think) in 8bit gamma-corrected
values, I'm a human and I do not see any reason to imagine colors in a
way that was practical for computers in the 90ies of the last century.
And, more important, I like to mix colors (like e.g. rgb Pink*0.9 +
Skyblue*0.1) and this works only (as I do expect it to work) when colors
are linear defined otherwise the result of this kind of calculation is
already mathematical wrong - and looks wrong.
If you do not know what I mean:
0.3 + 0.5 = 0.8
BUT
pow(0.3, 2) + pow(0.5, 2) != pow(0.8, 2)
And (again) the argument that human perception is not linear is
completely irrelevant because we're talking about a raytracer that tries
to simulate the real world and light intensities there behave linear.
And I like to use color macros (like e.g. lightsysIV) and they also
expect *linear* colors (again otherwise already the math would be wrong).
And I own a spectrophotometer for measurement of diffuse reflectance and
this gives me colors in linear space (actually it gives me a spectrum
but this does not matter here).
And my Photoshop (CS5) setup is done in a way that it shows rgb values
in linear space (internal P'shop works in linear space anyway).
But well, maybe I *am* the only one who prefers it this way...
> Also, linear gradients won't look linear (at least not currently).
> (They are linear in terms of the energy they emit, but not in their
> perceived brightness.) This can be a bit of a problem when designing
> textures which should have a certain *look*, rather than having a certain
> emission function. (The relationship between emitted energy and perceived
> brightness is roughly logarithmic, and the exponent is approximately 2.2,
> which happens to coincide with most displays.)
>
>> Don't do this. Actually this isn't a complicated matter. What makes it
>> appear complicated is the amount of wrong informations and even worse
>> half true statements as sadly frequently given within this newsgroup.
>
> It *is* a complicated subject, and there indeed is a lot of misinformation
> out there. A common misunderstanding is the relationship between absolute
> brightness (the amount of energy that a pixel with a certain value emits,
> mesured in watts) and the *perceived* brightness (which is what it looks
> like to the human eye). This relationship is far from linear.
>
> The question is: Do you want "rgb 0.5" to emit half of the energy than
> "rgb 1.0" (in which case you should use assumed_gamma 1.0), or do you want
> "rgb 0.5" to *look* half as bright as "rgb 1.0" (in which case you should
> use assumed_gamma 2.2)?
>
> You can make "0.5" to look half-gray even with an assumed_gamma of 1.0
> by pre-gamma-correcting it (in which case you would have to use
> pow(0.5, 2.2) = 0.218), and in theory all the surface lighting will be
> more accurate (because they will deal with the absolute light energy,
> rather than perceived brightness), but as said, you will stumble across
> problems when designing textures (eg. because linear gradients won't look
> linear) and other such things related to colors.
>
This is all irrelevant. How something *looks* has to do with the
lighting condition. Without lights everything *looks* black.
And when you prefer to use POV-Ray as a "painting-tool" where you expect
50% gray to be half as bright as white feel free to do so, I do this
also sometimes, with ambient set to 1 and diffuse to 0, BUT THIS IS A
DIFFERENT MATTER. Yes this has to be shouted.
When you use POV-Ray to simulate real world lighting where (simplified)
a color is the result of the diffuse reflection of light the whole talk
about *perceived* brightness simply does not matter.
Finally, it is NOT complicated:
For anything that tries to be photo-realistic use assumed_gamma 1.
Feed POV-Ray with *linear* values or when you prefer to do so use sRGB
values and define colors with the srgb keyword. Since version 3.7 there
is no more need to care about image maps, they work like a charm.
Thats all.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
