 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10-9-2011 14:23, Ive wrote:
> Well, assuming you are *not* talking about HDR values but actually mean
> "<213,127,79> / 255" what is wrong with using the functions given within
> my very first reply?
>
> #macro scRGB_to_sRGB(Color)
> rgb <sRGB_Gamma(Color.red),
> sRGB_Gamma(Color.green),
> sRGB_Gamma(Color.blue)>
> #end
No HDR! I shall try this indeed.
>
> if you need the inverse transformation or actually want to input values
> in 8bit (0..255) range I'll leave it up to you to write these macro as
> an exercise ;)
<grin> I am not really good at this. I am even awfully moronic to tell
the truth ;-)
>
> But what I do not get is why you do not simply type srgb <whatever
> values> when you are actually using sRGB values (e.g. from a color
> picker) and rgb <whatever values> when using linear values.
Well mainly because color pickers give values as rgb. If I want to use
that same shade as srgb, for example in Poseray, I do not know what the
corresponding values are. However, your functions may help me with that
indeed! Thanks!!
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 10-9-2011 14:23, Ive wrote:
>> Well, assuming you are *not* talking about HDR values but actually mean
>> "<213,127,79> / 255" what is wrong with using the functions given within
>> my very first reply?
>>
>> #macro scRGB_to_sRGB(Color)
>> rgb <sRGB_Gamma(Color.red),
>> sRGB_Gamma(Color.green),
>> sRGB_Gamma(Color.blue)>
>> #end
>
> No HDR! I shall try this indeed.
>
>>
>> if you need the inverse transformation or actually want to input values
>> in 8bit (0..255) range I'll leave it up to you to write these macro as
>> an exercise ;)
>
> <grin> I am not really good at this. I am even awfully moronic to tell
> the truth ;-)
>
>>
>> But what I do not get is why you do not simply type srgb <whatever
>> values> when you are actually using sRGB values (e.g. from a color
>> picker) and rgb <whatever values> when using linear values.
>
> Well mainly because color pickers give values as rgb. If I want to use
> that same shade as srgb, for example in Poseray, I do not know what the
> corresponding values are. However, your functions may help me with that
> indeed! Thanks!!
>
> Thomas
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...
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
