 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Is it possible one way or another, to determine/calculate the srgb
equivalent of a given rgb vector? and vice-versa of course?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
> Is it possible one way or another, to determine/calculate the srgb
> equivalent of a given rgb vector? and vice-versa of course?
Try the method described here: http://en.wikipedia.org/wiki/SRGB
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.09.2011 16:27, schrieb Thomas de Groot:
> Is it possible one way or another, to determine/calculate the srgb
> equivalent of a given rgb vector? and vice-versa of course?
>
This is surely possible but the way it is done depends on what you
actually mean by 'rgb'.
Assuming you mean the rgb color space that is using the same primaries
as sRGB but is in linear space (i.e scRGB) all you need is a gamma
transformation like:
#declare sRGB_Gamma = function(C) {
select(C-0.0031308, C*12.92 : 1.055*pow(C,1/2.4)-0.055)
}
and the inverse for sRGB -> scRGB:
#declare sRGB_GammaInverse = function(C) {
select(C-0.04045, C/12.92, pow((C+0.055)/1.055,2.4))
}
Assuming both input and output within 0.0 - 1.0 range.
Now just write macros that do handle the 3 color channels with these
functions but keep filter and transmit values untouched.
Otherwise (when you are not referring to scRGB) you'll need to transform
it via CIE xyz color space where my CIE.inc file should come in handy.
-Ive
P.S. untested code as I do not have POV-Ray available atm.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thank you Warp and Ive. Let me try to be a bit more explicit. It boils
down to the need of having a real srgb color picker, as was already
discussed/wished in these ng's some time ago. All color pickers (like
Sven's for instance) that I know of use (linear) rgb as far as I am aware.
As a user of Poser and Poseray, I often like to tone the skin of the
human figures. The latest Poseray version does this nicely with some
added macros where you just have to put in the tone's srgb values.
However, that is where my problem arises: I can define those tones in my
ancient PSP or in the latest Gimp, but those give the values in linear
space. So, to get the result I want I have to correct the Poseray output
just by changing 'srgb' into 'rgb' where necessary. If not, the result
is way to dark in general. This works but is a bit fastidious. Better
would be to have the 'real' srgb values of the tones from start. I hope
I made myself clear...
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.09.2011 09:50, schrieb Thomas de Groot:
> All color pickers (like
> Sven's for instance) that I know of use (linear) rgb as far as I am aware.
While I'm not aware of any that *does* use *linear* rgb values (don't
know about "Sven's" though).
> As a user of Poser and Poseray, I often like to tone the skin of the
> human figures. The latest Poseray version does this nicely with some
> added macros where you just have to put in the tone's srgb values.
> However, that is where my problem arises:
> I can define those tones in my
> ancient PSP or in the latest Gimp, but those give the values in linear
> space.
I really doubt that.
> So, to get the result I want I have to correct the Poseray output
> just by changing 'srgb' into 'rgb' where necessary. If not, the result
> is way to dark in general. This works but is a bit fastidious. Better
> would be to have the 'real' srgb values of the tones from start.
Sorry, but I've got the feeling that there is some fundamental
misconception on your side. sRGB is by definition gamma corrected
(composed of two functions as shown in my last post) and the linear
variant of it is called scRGB and this *linear* rgb space should be used
for *any* kind of math applied to colors (that is why POV-Ray
internally always assumes linear rgb values). But I don't know what
FlyerX actually does as I'm just using PoseRay's geometry output in
combination with my own textures.
Actually I'm not using PoseRay anymore as it does not work on my machine
(x64 with AMD OpenGL drivers) but this is a different story...
> I hope I made myself clear...
...nope :(
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10-9-2011 11:06, Ive wrote:
> Am 10.09.2011 09:50, schrieb Thomas de Groot:
>> All color pickers (like
>> Sven's for instance) that I know of use (linear) rgb as far as I am
>> aware.
>
> While I'm not aware of any that *does* use *linear* rgb values (don't
> know about "Sven's" though).
Right. I see I have got it all wrong obviously... ;-) What I mean is
simply the use of rgb (as in POV-Ray) versus srgb (as in POV-Ray too).
>
>> As a user of Poser and Poseray, I often like to tone the skin of the
>> human figures. The latest Poseray version does this nicely with some
>> added macros where you just have to put in the tone's srgb values.
>> However, that is where my problem arises:
>> I can define those tones in my
>> ancient PSP or in the latest Gimp, but those give the values in linear
>> space.
>
> I really doubt that.
I am sure you do :-)
>
>> So, to get the result I want I have to correct the Poseray output
>> just by changing 'srgb' into 'rgb' where necessary. If not, the result
>> is way to dark in general. This works but is a bit fastidious. Better
>> would be to have the 'real' srgb values of the tones from start.
>
> Sorry, but I've got the feeling that there is some fundamental
> misconception on your side. sRGB is by definition gamma corrected
> (composed of two functions as shown in my last post) and the linear
> variant of it is called scRGB and this *linear* rgb space should be used
> for *any* kind of math applied to colors (that is why POV-Ray internally
> always assumes linear rgb values). But I don't know what FlyerX actually
> does as I'm just using PoseRay's geometry output in combination with my
> own textures.
What I see in POV-Ray is that, e.g. rgb <213,127,79> does not render
identical to srgb <213,127,79>. I would like to know what srgb values
correspond to the given rgb ones. This is independent, I assume, of what
Poseray does...
>> I hope I made myself clear...
>
> ...nope :(
<sigh> I was not surprised...
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10-9-2011 13:20, Thomas de Groot wrote:
> What I see in POV-Ray is that, e.g. rgb <213,127,79> does not render
> identical to srgb <213,127,79>. I would like to know what srgb values
> correspond to the given rgb ones. This is independent, I assume, of what
> Poseray does...
>
obviously: rgb <213,127,79>/255 and srgb <213,127,79>/255
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10.09.2011 13:20, schrieb Thomas de Groot:
> What I see in POV-Ray is that, e.g. rgb <213,127,79> does not render
> identical to srgb <213,127,79>.
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
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 ;)
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.
-Ive
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011/09/10 10:47, Thomas de Groot a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
El 11/09/11 09:06, Thomas de Groot escribió:
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
El 11/09/11 15:45, Ive escribió:
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
El 11/09/11 16:48, Ive escribió:
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
El 11/09/11 16:28, Jaime Vives Piqueres escribió:
> 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:
> El 11/09/11 16:48, Ive escribió:
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2011/09/11 04:14, Thomas de Groot a écrit :
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11-9-2011 13:15, Jaime Vives Piqueres wrote:
> background{rgb <213,127,79>/255}
I think that is where my setup is *wrong* (and I apologize) because I
use a colored object within a white sphere with finish {emission 1} (no
light source). I understand now from the explanations by Warp and Ive,
that the sphere's color influences the object's color. Obvious, but I am
not always thinking straight ;-)
Remains my question: when to use the term 'srgb' in POV-Ray code?
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11-9-2011 23:44, Alain wrote:
>
> You can use: pigment{srgb<213, 127, 79>/255}
Yes, but that gives a totally different color. As I asked elsewhere here
in answer to Jaime: I am unsure when you need to use the terms 'rgb'
(which seems to be almost always) or the term 'srgb'in POV-Ray code.
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11-9-2011 15:37, Ive wrote:
> 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.
Aha! This answers my puzzle! So, what you are saying is that it is a
matter of (personal) choice: use the 'rgb' term in the POV-Ray code and
all is well for most if not all cases, and if one wants (for whatever
reason) to de-gamma the colors, use 'srgb' and adapt in consequence.
Very well! This makes my life much simpler ;-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.09.2011 09:10, schrieb Thomas de Groot:
> On 11-9-2011 23:44, Alain wrote:
>>
>> You can use: pigment{srgb<213, 127, 79>/255}
>
> Yes, but that gives a totally different color. As I asked elsewhere here
> in answer to Jaime: I am unsure when you need to use the terms 'rgb'
> (which seems to be almost always) or the term 'srgb'in POV-Ray code.
>
<sigh> you *use* 'srgb' when the color value you specify *is* in sRGB
color space. E.g. when taken from some color picker, translated from
HTML colors or you simply prefer to "think" of colors as sRGB colors.
And (as it was not yet mentioned within this thread), changing the gamma
(using gamma correction for brightness adjustment on a per color or
whole scene basis) or using 'wrong' gamma (rgb versus srgb) does NOT
ONLY change the brightness, it also changes the hue.
And (more or less unrelated and not meant do add more confusion)
personally I do avoid sRGB like hell simply because I'm meanwhile used
to the AdobeRGB color primaries and one nice thing about POV-Ray is
because it has no defined inbuilt color space (with some exceptions)
this works like a charm.
And yes, I own a monitor that is actually calibrated for AdobeRGB and
yes, this makes a difference. But I do convert my final images to sRGB
when I show them somewhere in the web.
But when it comes to questions about color spaces things get indeed a
bit complicated while I still think the gamma issue is trivial and the
whole reason for confusion there is the huge amount of half-true
information that is spread around.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-9-2011 10:28, Ive wrote:
> And (more or less unrelated and not meant do add more confusion)
> personally I do avoid sRGB like hell simply because I'm meanwhile used
> to the AdobeRGB color primaries and one nice thing about POV-Ray is
> because it has no defined inbuilt color space (with some exceptions)
> this works like a charm.
I can perfectly understand this! I shall do the same! Thanks for all
your efforts to make me understand :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 15:37, schrieb Ive:
> 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.
Always glad to hear that :-)
But I suggest everyone to calm down a bit; There are two approaches to
working with colors in POV-Ray: (1) Using assumed_gamma 1.0 for
photorealism, and (2) using assumed_gamma 2.2 (or something alike) for
more pleasant brightness gradients in color_map and the like. Warp has
always been a proponent of the latter, while you and I are proponents of
the former, but at present it must be conceded that both have their
benefits.
@Thomas: Don't listen to Warp in this matter - it'll only get you all
the more confused.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.09.2011 09:23, schrieb Thomas de Groot:
> On 11-9-2011 15:37, Ive wrote:
>
>> 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.
>
> Aha! This answers my puzzle! So, what you are saying is that it is a
> matter of (personal) choice: use the 'rgb' term in the POV-Ray code and
> all is well for most if not all cases, and if one wants (for whatever
> reason) to de-gamma the colors, use 'srgb' and adapt in consequence.
> Very well! This makes my life much simpler ;-)
Um... actually it's just the other way round: Use "rgb" if your color
values are already linear - which typically they are NOT if you use
external color pickers, so in that case use "srgb" (and divide by 255)
if you take colors from somewhere else, to de-gamma them for POV-Ray.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 15:45, schrieb Ive:
> 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.
Warp is right: It does.
Unless you specify a #version statement of 3.7 or higher, that is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 11.09.2011 17:50, schrieb 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.
... and that's what it is. To be precise, in the absence of a #version
statement, RC3 defaults to "assumed_gamma sRGB" rather than
"assumed_gamma 2.2". (Likewise, File_Gamma defaults to "sRGB" as well.)
The combination
#version 3.7;
global_settings{assumed_gamma 2.2}
background{rgb <213,127,79>/255}
with
File_Gamma=2.2
should give you <213,127,79> in Gimp as well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 12.09.2011 09:08, schrieb Thomas de Groot:
> On 11-9-2011 13:15, Jaime Vives Piqueres wrote:
>> background{rgb <213,127,79>/255}
>
> I think that is where my setup is *wrong* (and I apologize) because I
> use a colored object within a white sphere with finish {emission 1} (no
> light source). I understand now from the explanations by Warp and Ive,
> that the sphere's color influences the object's color. Obvious, but I am
> not always thinking straight ;-)
>
> Remains my question: when to use the term 'srgb' in POV-Ray code?
That question has a very, very simple answer in 3.7:
-----------------------------------------
Use "srgb" whenever you get a color value
from an external application(*).
-----------------------------------------
(*unless you know what you are doing)
And yes, it's really that straightforward; no caveats regarding
assumed_gamma or #version in this context.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-9-2011 11:41, clipka wrote:
> Am 12.09.2011 09:08, schrieb Thomas de Groot:
>> Remains my question: when to use the term 'srgb' in POV-Ray code?
>
> That question has a very, very simple answer in 3.7:
>
> -----------------------------------------
> Use "srgb" whenever you get a color value
> from an external application(*).
> -----------------------------------------
>
> (*unless you know what you are doing)
>
> And yes, it's really that straightforward; no caveats regarding
> assumed_gamma or #version in this context.
Yes, that is finally also the conclusion I have reached after reading
this thread. Fair enough and thanks for the info and the patience :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> But I suggest everyone to calm down a bit; There are two approaches to
> working with colors in POV-Ray: (1) Using assumed_gamma 1.0 for
> photorealism, and (2) using assumed_gamma 2.2 (or something alike) for
> more pleasant brightness gradients in color_map and the like. Warp has
> always been a proponent of the latter, while you and I are proponents of
> the former, but at present it must be conceded that both have their
> benefits.
The major problem I see with assumed_gamma 1.0 is that designing textures
becomes more complicated, because textures are usually designed by how they
should look rather than what their absolute irradiance values are.
If you are only specifying individual colors, then using 'srgb' takes
care of that. However, patterns present a problem. Usually you want
patterns to interpolate linearly from one color to another (with what
I mean that the interpolation should *look* linear).
As a simple example, one would expect
color_map { [0 srgb 0][0.5 srgb 0.5][1 srgb 1] }
to look identical to
color_map { [0 srgb 0][1 srgb 1] }
(With assumed_gamma 2.2 it does, but obviously not with assumed_gamma 1.0.)
The problem is that with assumed_gamma 1.0 the gradient will be linear
in terms of irradiance rather than in terms of perceived brightness.
I understand that some work will be done to alleviate this problem.
Optimally one should be able to define entire textures with an "assumed
gamma" other than 1.0, which would make those gradients look linear.
Until that time using assumed_gamma 2.2 is just more convenient in many
cases, even if it technically speaking produces an incorrect rendering.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> That question has a very, very simple answer in 3.7:
> -----------------------------------------
> Use "srgb" whenever you get a color value
> from an external application(*).
> -----------------------------------------
Actually I would use it otherwise as well. For example, if I want a
50% gray, I'd specify "srgb 0.5" because it's more convenient than
calculating the proper rgb with a formula.
Or is there are more "kosher" way of getting a 50% gray color?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 20:55, Warp wrote:
> The major problem I see with assumed_gamma 1.0 is that designing textures
> becomes more complicated, because textures are usually designed by how they
> should look rather than what their absolute irradiance values are.
>
> If you are only specifying individual colors, then using 'srgb' takes
> care of that. However, patterns present a problem. Usually you want
> patterns to interpolate linearly from one color to another (with what
> I mean that the interpolation should *look* linear).
Unless I completely misunderstand the workings of gamma, I believe this
macro should be able to help you:
--- START CODE ---
#declare noWrap=function(x) {max(min(x,1),0)}
#macro pigmentDegamma(Pigment,Gamma)
#local PigmentFunction=function {pigment {Pigment}}
#local Result=pigment {
function {noWrap(PigmentFunction(x,y,z).transmit)}
pigment_map {
[0
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0]
[1 red 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0]
[1 green 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0]
[1 blue 1]
}
poly_wave Gamma
]
}
]
[1
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0 transmit 1]
[1 red 1 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0 transmit 1]
[1 green 1 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0 transmit 1]
[1 blue 1 transmit 1]
}
poly_wave Gamma
]
}
]
}
}
Result
#end
--- END CODE ---
To be used as:
#local Pigment=pigment { [your pigment] }
object {YourObject pigment {pigmentDegamma(Pigment,2.2)}}
Limitations:
- only works with pigments that don't need any surface information (eg:
aoi will not work)
- "filter" isn't taken into account yet, but that should actually be
rather easy to fix.. but since I almost never use filter, I didn't
bother fixing it :)
- only works with pigments with colors in the 0-1 range. I have no idea
how easy it would be to fix that, as just dividing the original colors
before degamma'ing them, and then multiplying them again by that same
value would not give the correct colors
But still, it might be useful :)
cu!
--
ZK
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 12/09/2011 20:55, Warp wrote:
>> The major problem I see with assumed_gamma 1.0 is that designing textures
>> becomes more complicated, because textures are usually designed by how
>> they
>> should look rather than what their absolute irradiance values are.
>>
>> If you are only specifying individual colors, then using 'srgb' takes
>> care of that. However, patterns present a problem. Usually you want
>> patterns to interpolate linearly from one color to another (with what
>> I mean that the interpolation should *look* linear).
Fun fact: With assumed_gamma 2.2, visually pleasing /brightness/
gradients are easy to accomplish, but /color/ gradients may be
excessively difficult to get right (depending on the colors involved),
while those are a piece of cake with assumed_gamma 1.0.
As an example, try the following gradient:
[0.0 color srgb <1,0,0> ]
[0.5 color srgb <0,0.8,0> ]
[1.0 color srgb <1,0,0> ]
With assumed_gamma 2.2, the transition features a significant ditch in
brightness between the two colors. Not so with assumed_gamma 1.0, which
maintains roughly the same brightness level throughout the whole transition.
So to make it easy to achieve visually pleasing gradients for both
brightness /and/ color gradients, a new feature needs to be added to
POV-Ray anyway, to get the best of both worlds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 22:15, Zeger Knaepen wrote:
> [0 red 0]
> [1 red 1]
that should of course be "red 3", and the same for green and blue...
corrected code:
--- START CODE ---
#declare noWrap=function(x) {max(min(x,1),0)}
#macro pigmentDegamma(Pigment,Gamma)
#local PigmentFunction=function {pigment {Pigment}}
#local Result=pigment {
function {noWrap(PigmentFunction(x,y,z).transmit)}
pigment_map {
[0
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0]
[1 red 3]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0]
[1 green 3]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0]
[1 blue 3]
}
poly_wave Gamma
]
}
]
[1
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0 transmit 1]
[1 red 3 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0 transmit 1]
[1 green 3 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0 transmit 1]
[1 blue 3 transmit 1]
}
poly_wave Gamma
]
}
]
}
}
Result
#end
--- END CODE ---
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-9-2011 23:33, clipka wrote:
> So to make it easy to achieve visually pleasing gradients for both
> brightness /and/ color gradients, a new feature needs to be added to
> POV-Ray anyway, to get the best of both worlds.
LOL
So if only for that, this discussion has been quite useful! ;-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
> So if only for that, this discussion has been quite useful! ;-)
>
> Thomas
Found this discussion really helpfull. Been wondering for years why POVRay
output always looks so blown on the white side. Only thing, does anyone know how
to do the same to an image map? Should you save the file with a linear RGB color
profile? How would you do this?
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Grim Reaper wrote:
> Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
>> So if only for that, this discussion has been quite useful! ;-)
>>
>> Thomas
>
> Found this discussion really helpfull. Been wondering for years why POVRay
> output always looks so blown on the white side. Only thing, does anyone know how
> to do the same to an image map? Should you save the file with a linear RGB color
> profile? How would you do this?
Actually, if you use a file format such as PNG that is gamma aware
the results should already be correct in 3.7. For other file formats,
or to override this behavior, you can use the gamma keyword in the
image_map.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.09.2011 23:59, schrieb Grim Reaper:
> Found this discussion really helpfull. Been wondering for years why POVRay
> output always looks so blown on the white side. Only thing, does anyone know how
> to do the same to an image map? Should you save the file with a linear RGB color
> profile? How would you do this?
For POV-Ray 3.6, you would indeed need to convert image maps to a linear
RGB color profile (unless you're using "assumed_gamma 2.2"), or convert
to Radiance HDR and use MegaPOV. To preserve the full dynamic range of
the original material, I'd recommend using 16 bit per color channel.
With POV-Ray 3.7, and presuming you're using a "#version 3.7" directive,
most image maps should be fine "as is". PNG files are handled
automatically (provided they have a proper gAMA and/or sRGB chunk), same
goes for OpenEXR and Radiance HDR (which are linear by definition); for
any other files, POV-Ray 3.7 will presume that they're sufficiently
close to the sRGB profile. In the rare event of POV-Ray 3.7's
automatisms failing, you can override them by using the "gamma"
statement in the image_map.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
