 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tag povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 13:45, schrieb Warp:
> POV-Ray 3.7 uses (now) a default assumed_gamma of 2.2, which perfectly
> explains that.
>
No, it doesn't. At least RC3 does not.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Am 11.09.2011 13:45, schrieb Warp:
>> POV-Ray 3.7 uses (now) a default assumed_gamma of 2.2, which
>> perfectly explains that.
>>
>
> No, it doesn't. At least RC3 does not.
Just tested it, and that's only true if you explicitly set #version to
3.7, if not it uses 2.2.
Anyhow, using assumed_gamma 1.0 and srgb gives the correct result, the
same as when using assumed_gamma 2.2 and rgb. So, I think something is
wrong with Thomas setup... it should be giving him the correct results
for the right sRGB color on the image he posted, and the left color
should be also different (236,187,151).
Regards,
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 16:28, schrieb Jaime Vives Piqueres:
> Just tested it, and that's only true if you explicitly set #version to
> 3.7, if not it uses 2.2.
>
ah, well ;) I guess that's the reason I write #version 3.7 AND
global_settings {assumed_gamma 1.0} (just to be sure) automatic into
every new scene file before doing anything else.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Guys!
I am coming back tomorrow to see this more in detail!
Great stuff you are producing. Thanks a lot!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Am 11.09.2011 16:28, schrieb Jaime Vives Piqueres:
>> Just tested it, and that's only true if you explicitly set #version to
>> 3.7, if not it uses 2.2.
>>
>
> ah, well ;) I guess that's the reason I write #version 3.7 AND
> global_settings {assumed_gamma 1.0} (just to be sure) automatic into
> every new scene file before doing anything else.
>
> -Ive
>
Curiosly, I noticed that
#version 3.7;
global_settings{assumed_gamma 2.2}
background{rgb <213,127,79>/255}
gives a slighty different result than just:
background{rgb <213,127,79>/255}
The last gives back the correct <213,127,79>, while the former gives
<214,128,78>. ?!?!?
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So, I think something is wrong with Thomas setup... it should be
> giving him the correct results for the right sRGB color on the image
> he posted, and the left color should be also different
> (236,187,151).
>
And I can't seem to be able to reproduce his results just by mangling
with my gamma settings... looks like a bad gamma setup would not
de-saturate the colors in that way. I really can't figure out what's
wrong there...
--
Jaime Vives Piqueres
La Persistencia de la Ignorancia
http://www.ignorancia.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 17:01, schrieb Jaime Vives Piqueres:
>> Am 11.09.2011 16:28, schrieb Jaime Vives Piqueres:
>>> Just tested it, and that's only true if you explicitly set #version to
>>> 3.7, if not it uses 2.2.
>>>
>>
>> ah, well ;) I guess that's the reason I write #version 3.7 AND
>> global_settings {assumed_gamma 1.0} (just to be sure) automatic into
>> every new scene file before doing anything else.
>>
>> -Ive
>>
>
> Curiosly, I noticed that
>
> #version 3.7;
> global_settings{assumed_gamma 2.2}
> background{rgb <213,127,79>/255}
>
> gives a slighty different result than just:
>
> background{rgb <213,127,79>/255}
>
> The last gives back the correct <213,127,79>, while the former gives
> <214,128,78>. ?!?!?
>
looks pretty much like the difference between a simple power 2.2 and the
sRGB gamma response curve (composed of two functions and just 'close' to
2.2) to me.
-Ive
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
You can use: pigment{srgb<213, 127, 79>/255}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
