clipka wrote:

> Strictly speaking, POV-Ray 3.7 doesn't introduce a fully new gamma 
> handling concept at all; it just (1) obsoletes the 3.6 default of not 
> performing any gamma handling at all

Does this mean if you already used assumed_gamma 1.0 in 3.6
then your rgb colors will render the same with #version 3.7?

Post a reply to this message

Am 06.03.2012 00:36, schrieb Christian Froeschlin:
> clipka wrote:
>
>> Strictly speaking, POV-Ray 3.7 doesn't introduce a fully new gamma
>> handling concept at all; it just (1) obsoletes the 3.6 default of not
>> performing any gamma handling at all
>
> Does this mean if you already used assumed_gamma 1.0 in 3.6
> then your rgb colors will render the same with #version 3.7?

Yes.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> It might make /some/ sense to add a kind of "prgb" keyword; the rgb 
> keyword actually means "physical colors" /only/ if assumed_gamma is set 
> to 1.0. This interpretation of "rgb" is backward compatible with 3.6.

  I don't think "rgb" is generally considered to describe the amount of
radiant energy (measured in Joules) reflected by a surface (so that for
example "rgb 0.5" means that the surface reflects half of the incoming
radiant energy), but rather the *perceived* color of the surface (iow.
"rgb 0.5" means that the surface *looks* exactly half as bright as
"rgb 1").

  Measuring things in terms of perceived brightness is way more common than
in terms of absolute radiant energy. For instance, most SI units related to
light, such as the lux and the candela, measure perceived brightness.

-- 
                                                          - Warp

Post a reply to this message

Am 06.03.2012 17:33, schrieb Warp:
>    I don't think "rgb" is generally considered to describe the amount of
> radiant energy (measured in Joules) reflected by a surface (so that for
> example "rgb 0.5" means that the surface reflects half of the incoming
> radiant energy), but rather the *perceived* color of the surface (iow.
> "rgb 0.5" means that the surface *looks* exactly half as bright as
> "rgb 1").
>
>    Measuring things in terms of perceived brightness is way more common than
> in terms of absolute radiant energy. For instance, most SI units related to
> light, such as the lux and the candela, measure perceived brightness.

Careful when using those terms: While the luminous flux (measured in 
lux) and luminous intensity (measured in candela) do include some 
correction to account for /some/ peculiarities of human perception, 
these are limited to wavelength-dependent weighting, and doesn't account 
for gamma-like effects. For any given hue and saturation, the units 
still represent light intensity /linearly/.

Thus, a luminous flux of 0.5 lux is still perceived as about 73% as 
bright as a flux of 1.0 lux.

Post a reply to this message

> >    It becomes a bit more problematic when you are not defining the colors
> > yourself, but are using a pre-defined texture (eg. from an include file).
> > Now, I don't remember if something was added to POV-Ray 3.7 to "convert"
> > such a pre-defined texture into 'srgb' on the fly.

Ok, well in looking at all the include files from the folder
"POV-Ray\v3.7\include" (stones1, stones2, textures, colors, etc) they all say
they're for version 3.5. Are they the wrong ones to be using with 3.7?

> No, indeed not. I guess the proper solution there is to overhaul the
> standard include files to use "srgb" throughout.

So are you saying I should do a Find and Replace for everything "rgb" and
replace with "srgb" in these include files? Actually, most of the "rgb"
statements are "rgbt". whatever that means..

Post a reply to this message

Am 07.03.2012 03:01, schrieb JamesB7271:
>>>     It becomes a bit more problematic when you are not defining the colors
>>> yourself, but are using a pre-defined texture (eg. from an include file).
>>> Now, I don't remember if something was added to POV-Ray 3.7 to "convert"
>>> such a pre-defined texture into 'srgb' on the fly.
>
> Ok, well in looking at all the include files from the folder
> "POV-Ray\v3.7\include" (stones1, stones2, textures, colors, etc) they all say
> they're for version 3.5. Are they the wrong ones to be using with 3.7?

They're the official ones that come with 3.7, if that's what you're 
asking. That doesn't mean they're ideal for 3.7 though.

>> No, indeed not. I guess the proper solution there is to overhaul the
>> standard include files to use "srgb" throughout.
>
> So are you saying I should do a Find and Replace for everything "rgb" and
> replace with "srgb" in these include files?

Maybe a good thing would be to copy the files (maybe name them 
"stones1_srgb.inc", for instance), and modify those copies.

> Actually, most of the "rgb"
> statements are "rgbt". whatever that means..

Besides "rgb", which defines a color in terms of red, green and blue, 
there are also keywords that define the color's transmit and/or filter 
value at the same time; those are "rgbt", "rgbf", and "rgbft".

The keywords "srgbt", "srgbf" and "srgbft" also exist.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 07.03.2012 03:01, schrieb JamesB7271:
> >>>     It becomes a bit more problematic when you are not defining the colors
> >>> yourself, but are using a pre-defined texture (eg. from an include file).
> >>> Now, I don't remember if something was added to POV-Ray 3.7 to "convert"
> >>> such a pre-defined texture into 'srgb' on the fly.
> >
> > Ok, well in looking at all the include files from the folder
> > "POV-Ray\v3.7\include" (stones1, stones2, textures, colors, etc) they all say
> > they're for version 3.5. Are they the wrong ones to be using with 3.7?
>
> They're the official ones that come with 3.7, if that's what you're
> asking. That doesn't mean they're ideal for 3.7 though.
>
> >> No, indeed not. I guess the proper solution there is to overhaul the
> >> standard include files to use "srgb" throughout.
> >
> > So are you saying I should do a Find and Replace for everything "rgb" and
> > replace with "srgb" in these include files?
>
> Maybe a good thing would be to copy the files (maybe name them
> "stones1_srgb.inc", for instance), and modify those copies.
>
> > Actually, most of the "rgb"
> > statements are "rgbt". whatever that means..
>
> Besides "rgb", which defines a color in terms of red, green and blue,
> there are also keywords that define the color's transmit and/or filter
> value at the same time; those are "rgbt", "rgbf", and "rgbft".
>
> The keywords "srgbt", "srgbf" and "srgbft" also exist.

Ok, I did a Find and Replace on my stones2.inc file (well the new
stones2_srgb.inc file) and replaced everything "rgb" with "srgb". So "rgbt" now
becamse "srgbt".

That appears to have worked. The textures I was using for these sample renders
now look normal again (much richer color definition) instead of all washed out.

So the problem actually was a mismatch of version 3.7's new use of srgb and the
lack of srgb values in the old 3.5 include file 3.7 was processing. Correct?

Thank you so much everyone for all your assistance in clearing this up. I now
feel confident that everything is "right" so I can start moving forward..

Thanks,
-James

Post a reply to this message

Am 09.03.2012 01:57, schrieb JamesB7271:

> That appears to have worked. The textures I was using for these sample renders
> now look normal again (much richer color definition) instead of all washed out.
>
> So the problem actually was a mismatch of version 3.7's new use of srgb and the
> lack of srgb values in the old 3.5 include file 3.7 was processing. Correct?

Yup.

Post a reply to this message

JamesB7271 <nomail@nomail> wrote:
> Ok, I did a Find and Replace on my stones2.inc file (well the new
> stones2_srgb.inc file) and replaced everything "rgb" with "srgb". So "rgbt" now
> becamse "srgbt".

  I think it would be better if there was some way of specifying an
assumed_gamma for a declared texture. Perhaps something like:

    texture { some_declared_texture assumed_gamma srgb }

or something similar.

-- 
                                                          - Warp

Post a reply to this message

Am 09.03.2012 09:45, schrieb Warp:
> JamesB7271<nomail@nomail>  wrote:
>> Ok, I did a Find and Replace on my stones2.inc file (well the new
>> stones2_srgb.inc file) and replaced everything "rgb" with "srgb". So "rgbt" now
>> becamse "srgbt".
>
>    I think it would be better if there was some way of specifying an
> assumed_gamma for a declared texture. Perhaps something like:
>
>      texture { some_declared_texture assumed_gamma srgb }
>
> or something similar.

Hm... I do have some doubts whether this could actually fly, but I'll 
ponder the idea.

Post a reply to this message