 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Do light sources in POV 3.7 use srgb or rgb? Do the colors need to be
adjusted to the new system? For instance:
light_source
{
-z * 40960
<pow(light_color.red,2.2),pow(light_color.green,2.2),pow(light_color.blue,2.2)>
rotate -x * 60
rotate +y * 45
parallel
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 15-08-31 11:55, Mike Horvath a écrit :
> Do light sources in POV 3.7 use srgb or rgb? Do the colors need to be
> adjusted to the new system? For instance:
>
> light_source
> {
> -z * 40960
> <pow(light_color.red,2.2),pow(light_color.green,2.2),pow(light_color.blue,2.2)>
> rotate -x * 60
> rotate +y * 45
> parallel
> }
By default, they use rgb unless you explicitely use srgb.
light_source{Location rgb<1,0.5,0.4>} use the rgb colour space.
light_source{Location srgb<1,0.5,0.4>} use the srgb colour space.
Your sample don't translate from rgb to srgb but, instead, adjust for a
gamma of 2.2.
You should use assumed_gamma 1 in your global_settings section and set
display_gamma 2.2 in the master .ini file. Once it's done, you should
never need to perform that kind of gamma "magic" in your scenes.
By the way, rotate<-60, 45> or rotate<-60, 45, 0> will give you exactly
the same result as your pair of rotates.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/31/2015 4:04 PM, Alain wrote:
> Your sample don't translate from rgb to srgb but, instead, adjust for a
> gamma of 2.2.
But switching to srgb instead of rgb fixes most of my gamma problems.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.08.2015 um 22:04 schrieb Alain:
> You should use assumed_gamma 1 in your global_settings section and set
> display_gamma 2.2 in the master .ini file. Once it's done, you should
> never need to perform that kind of gamma "magic" in your scenes.
Personally, I'd recommend trying to calibrate the display for sRGB and
use "Display_Gamma=srgb". At any rate, the setting should of course
match the display system's effective gamma, so a generic recommendation
of setting Display_Gamma to 2.2 falls a bit short.
> By the way, rotate<-60, 45> or rotate<-60, 45, 0> will give you exactly
> the same result as your pair of rotates.
Personally, I prefer Mike's approach of using separate "rotate"
statements, as I think it makes it a bit easier for the reader to see
what's happening; it'll also allow you to always use the same pattern
for sequences of rotations, regardless of whether or not they match the
standard X-Y-Z ordering.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 31.08.2015 um 17:55 schrieb Mike Horvath:
> Do light sources in POV 3.7 use srgb or rgb?
The question is a bit poorly worded, so instead of trying to guess your
own understanding of that question, I'll try to provide you with
information that should enable you to anwer it yourself:
Light source colours in all versions of POV-Ray are specified in the
very same manner as any other colours in that particular version.
Now first, let's look at what this means for POV-Ray 3.6:
* By default, POV-Ray 3.6 did not do any gamma handling; this can be
interpreted in two ways:
(a) According to the design and implementation, and although this was
certainly unintentional, POV-Ray 3.6 interpreted all colour expressions
as colour coordinates in a linear RGB colour space, expected all input
images to be in that same colour space, and generated output images in
that same colour space. In this sense, POV-Ray 3.6 did everything right,
but colour in- and output were in an uncommon format, a fact that was
entirely unknown to most (if not all) users; as a result, users would
create scenes that did not match what they wanted, and got results they
wouldn't have wanted but, when misinterpreted in the most typical way,
"happened" to look pretty much exactly like what they wanted.
(b) According to the users' experience, it would seem that POV-Ray 3.6
interpreted all colour expressions as colour coordinates in an RGB
colour space gamma pre-corrected for the user's display system, expected
all input images to be in that same colour space, and generated output
images in that same colour space. In this sense, POV-Ray 3.6's colour
handling matched user expectations, but (again entirely unknown to most
users) it got a variety of colour computations outright wrong.
Most (if not all) legacy scenes (POV-Ray 3.6 scenes without explicit
"assumed_gamma") would be written specifying all colours in sRGB
coordinates (or something very close), but using the "rgb" family of
keywords to specify them (the "srgb" keyword wasn't available back then).
* Alternatively, POV-Ray 3.6 already supported the "assumed_gamma"
keyword. Back then, its only effect was on file output, and was a way to
tell POV-Ray whether the above interpretation (a) or (b) was desired (by
setting assumed_gamma to either 1.0 or 2.2), but forcing POV-Ray to
generate output images with properly gamma pre-corrected colours in
either case. (There was also the possibility to choose a value in
between, or even larger or smaller, but I won't go into detail about that.)
Many "semi-legacy" scenes (POV-Ray 3.6 scenes with explicit
"assumed_gamma") would be written specifying all colours in something
somewhat close to sRGB coordinates ("assumed_gamma 2.2"), but using the
"rgb" keyword to specify them, just like in legacy scenes; others would
be written specifying all colours in linear RGB coordinates
("assumed_gamma 1.0"), also using the "rgb" keyword to specify those,
much like modern scenes.
Now let's examine POV-Ray 3.7:
* If you specify "#version 3.6", POV-Ray 3.7's colour handling is
virtually the same as that of POV-Ray 3.6.
* If you specify "#version 3.7", POV-Ray 3.7 defaults to "assumed_gamma
1.0", but other than that there is /still/ no fundamental difference to
the behaviour of POV-Ray 3.6, except that you get some /extensions/ to
complement the "assumed_gamma" mechanism:
- When using the "rgb" family of keywords, the colour expression's
interpretation will /still/ depend on the assumed_gamma setting; using
the "srgb" family of keywords, however, will cause the colour expression
to /always/ be interpreted as a colour coordinate in sRGB space. (This
feature is even available when "#version 3.6" is specified.)
- POV-Ray will no longer expect input image files to be in the same
colour space as colours specified using the "rgb" family of keywords;
instead, POV-Ray will do its best to auto-detect what gamma the image
data is pre-corrected for, and convert the data accordingly. (There's
also a syntax to override the auto-detection.)
It is highly recommended that modern (POV-Ray 3.7) scenes use
"assumed_gamma 1.0", and use the "srgb" family of keywords wherever
colour coordinates in sRGB space are known, while using the "rgb" family
of keywords where it is necessary or desired to supply colour
coordinates in linear colour space.
> Do the colors need to be
> adjusted to the new system? For instance:
>
> light_source
> {
> -z * 40960
> <pow(light_color.red,2.2),pow(light_color.green,2.2),pow(light_color.blue,2.2)>
>
> rotate -x * 60
> rotate +y * 45
> parallel
> }
Presuming that you're trying to migrate a legacy POV-Ray 3.6 scene
without assumed_gamma setting, or trying to migrate a scene with
"assumed_gamma 2.2" to "assumed_gamma 1.0", I recommend that you use the
"srgb" family of keywords in the /definition/ of light_color. If you do
that, there should be no need to perform any color conversions in the
light source definition itself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/2/2015 9:43 AM, clipka wrote:
> Presuming that you're trying to migrate a legacy POV-Ray 3.6 scene
> without assumed_gamma setting, or trying to migrate a scene with
> "assumed_gamma 2.2" to "assumed_gamma 1.0", I recommend that you use the
> "srgb" family of keywords in the /definition/ of light_color. If you do
> that, there should be no need to perform any color conversions in the
> light source definition itself.
>
I'm still sort of confused. For a brand new scene designed from scratch
in 3.7 and not needing to migrate from 3.6, should I aim to use "srgb"
or "rgb" in the light color definition?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.11.2016 um 04:02 schrieb Mike Horvath:
> On 9/2/2015 9:43 AM, clipka wrote:
>> Presuming that you're trying to migrate a legacy POV-Ray 3.6 scene
>> without assumed_gamma setting, or trying to migrate a scene with
>> "assumed_gamma 2.2" to "assumed_gamma 1.0", I recommend that you use the
>> "srgb" family of keywords in the /definition/ of light_color. If you do
>> that, there should be no need to perform any color conversions in the
>> light source definition itself.
>>
>
> I'm still sort of confused. For a brand new scene designed from scratch
> in 3.7 and not needing to migrate from 3.6, should I aim to use "srgb"
> or "rgb" in the light color definition?
You should be using "assumed_gamma 1.0" if you want physical realism.
Whether you're using `rgb` or `srgb` is irrelevant. You can either specify
rgb <R,G,B>
or
srgb <Rp,Gp,Bp>
where Rp=f(R), Gp=f(G) and Bp=f(B), with f(x) being a special function
defined in the sRGB colour space specification. The rendering results
are the same either way.
In the former case you're specifying the light source colour and
brightness in terms of linear light intensity values. In the latter case
you're specifying the light source colour and brightness in terms of
something closer to how the human eye perceives the values.
For example, you can either specify
rgb <0.0, 0.214, 1.0>
or
srgb <0.0, 0.5, 1.0>
without any difference in the render result. Whatever floats your boat.
There's a caveat though when performing mathematical operations in
conjunction with `srgb`; for instance,
rgb <0.0, 0.214, 1.0> * 100
is equivalent to
rgb <0, 21.4, 100>
which is equivalent to
srgb <0, 3.726, 7.133>
which is equivalent to
srgb <0.0, 0.522, 1.0> * 7.133
and thus results in a different hue than
srgb <0.0, 0.5, 1.0> * 7.133
so if you're using `srgb` notation you'll need to take care when trying
to adjust the bightness of light sources without changing the hue; the
following should work:
(srgb <0.0, 0.5, 1.0>) * 100
So my personal recommendation would be to prefer `rgb` over `srgb`.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Horvath <mik### [at] gmail com> wrote:
> I'm still sort of confused. For a brand new scene designed from scratch
> in 3.7 and not needing to migrate from 3.6, should I aim to use "srgb"
> or "rgb" in the light color definition?
If you get your colors from a 3rd party color picker, use 'srgb' (whether for a
light source or a pigment). If you get your colors from Lightsys IV, use 'rgb'.
Aside from those, I don't think it matters. You know what you want the color to
look like.
For light sources, especially with inverse square attenuation, you'll often want
to do math on the color, so be sure heed CLipka's warning about doing math with
'srgb'. I tend to assign the base color to a variable, and then do whatever
math I need on that variable. (Once a color is assigned to a variable, it
doesn't matter which keyword was used to define it.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks, guys, that really cleared up things for me.
On 11/17/2016 10:54 PM, clipka wrote:
> Whether you're using `rgb` or `srgb` is irrelevant. You can either specify
>
> rgb <R,G,B>
>
> or
>
> srgb <Rp,Gp,Bp>
>
> where Rp=f(R), Gp=f(G) and Bp=f(B), with f(x) being a special function
> defined in the sRGB colour space specification. The rendering results
> are the same either way.
Does the f(x) mentioned above exist in one of POV-Ray's include files
somewhere? Would it be a good idea to include it?
Also, are there any plans for the future to support CIELAB, CIELUV,
L*C*h(uv), HCL, etc. when specifying colors?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.11.2016 um 07:11 schrieb Mike Horvath:
> Thanks, guys, that really cleared up things for me.
>
>
> On 11/17/2016 10:54 PM, clipka wrote:
>> Whether you're using `rgb` or `srgb` is irrelevant. You can either
>> specify
>>
>> rgb <R,G,B>
>>
>> or
>>
>> srgb <Rp,Gp,Bp>
>>
>> where Rp=f(R), Gp=f(G) and Bp=f(B), with f(x) being a special function
>> defined in the sRGB colour space specification. The rendering results
>> are the same either way.
>
> Does the f(x) mentioned above exist in one of POV-Ray's include files
> somewhere? Would it be a good idea to include it?
No, at present the function is not exposed to the user. If there's
sufficient demand (or someone else stepping in to do the work) it
shouldn't be too difficult to add it to e.g. `colors.inc` as a macro or
user-defined function.
> Also, are there any plans for the future to support CIELAB, CIELUV,
> L*C*h(uv), HCL, etc. when specifying colors?
Since they're not used as commonly as sRGB, I doubt we'll add support
via a keyword (not until we do a major overhaul of the parser at any
rate). Note that `colors.inc` does provide various macros to convert to
and from HSL, HSV and L*a*b, and adding support for other colour models
in the same manner should be no big deal.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
