On 10/29/20 5:20 AM, Ive wrote:
<snip>
> A final remark: not using assumed_gamma 1.0 causes hue-shifts that 
> become more dramatic the more complex the lighting situation is AND it 
> violates the very basic low of energy conservation. There is no brick 
> wall that reflects more light than shines on it.
> If one has no problem with this two issues I'm absolutely fine with this 
> but please do not complain about unexpected results.
> And if somebody uses assumed_gamma 2.2 and produces a brilliant image 
> I'm glad for him but this proofs nothing and is no reason to start this 
> discussion again.

lol...thud (thanks btw)

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:

> So, to answer your question, of course uses the radiosity calculation
> linear values.

Thanks; that was one of the 'missing links' in my conception of radiosity use.
>
>
> A final remark: not using assumed_gamma 1.0 causes hue-shifts that
> become more dramatic the more complex the lighting situation is AND it
> violates the very basic low of energy conservation.

Yes, that is how I now understand any *non*-assumed_gamma 1.0 to operate. (And
of course, visual results bear it out.)


> ... And if somebody uses assumed_gamma 2.2 and produces a brilliant image
> I'm glad for him but this proofs nothing and is no reason to start this
> discussion again.
>

Well, in an ideal world, with everyone having perfect recall of all of the
arcane details that make up POV-ray, I would agree. But the trouble with the
newsgroups (and even the highly-detailed reference wiki) is that the true
'nuggets of wisdom' are spread out and not easily referenced. (That's probably
the case with any large collection of facts.) In the newsgroups here, the truly
useful nuggets are contained *somewhere* in x-number of years of posts, and it
sometimes takes real detective work to find them.

I bow down to anyone who can keep *all* of that stuff in memory, for instant
recall!

Thomas here, and Bald Eagle as well AFAIK, have apparently taken the time to
create a compendium of pertinent links to old posts, that they can refer to. I
used to do the same-- until my old Win XP computer failed...and I had stupidly
neglected to back up my years of 'net links. (I've learned my lesson, the hard
way.) For me, it's almost like starting again from ground-zero.

The point is, it's not easy (at least for me) to remember all the do's and
don'ts of POV-ray operation, and especially the 'why'.

One of Clipka's many strengths was that he had infinite patience in answering
the 'same ol' questions' over and over again. Aside from his knowledge and his
willingless to share it, that was the one quality that stood out.

Post a reply to this message

Op 29/10/2020 om 17:22 schreef Kenneth:
> Thomas here, and Bald Eagle as well AFAIK, have apparently taken the time to
> create a compendium of pertinent links to old posts, that they can refer to. I
> used to do the same-- until my old Win XP computer failed...and I had stupidly
> neglected to back up my years of 'net links. (I've learned my lesson, the hard
> way.) For me, it's almost like starting again from ground-zero.
> 
> 
My compendium of pertinent links is small as I did really start that 
quite recently after I lost so much time in tracing back relevant info 
(and/or history) I needed for particular projects. The net (and hence 
POV-Ray) is great for re-inventing the wheel at regular times :-) No 
criticism involved here; it is the nature of the net that stimulates 
this I am afraid, and its volatile way of "remembering" and "forgetting" 
things. The same goes for all those people who were present during those 
early days of POV-Ray and have vanished now, sometimes suddenly, 
sometimes gradually, but knowledge has gone with them, if that knowledge 
had not been secured one way or another.

I suppose prehistoric man experienced the same phenomenon: one tribe 
discovered a novel way of knapping silex tools. They boasted about it in 
the neighbourhood but were wiped out by their version of covid-19 before 
the knowledge was spread. It certainly is true of his spread from 
Africa: it happened several times but only few expansion waves were 
successful.

[and now I shut up]

-- 
Thomas

Post a reply to this message

Let me stick out my neck once again. ;-)

Back in 2014, and following some discussion it appears, I composed this 
test scene, without really understanding the matter. What is wrong?

-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (6 KB)

Am 10/30/2020 um 9:15 schrieb Thomas de Groot:
> Let me stick out my neck once again. ;-)
> 
> Back in 2014, and following some discussion it appears, I composed this 
> test scene, without really understanding the matter. What is wrong?
> 

I didn't run it as I do not have Ricky's include file anyway but from 
looking at it there is nothing wrong

The first box under "Ive's macros" should be brighter and less saturated 
and the second one should be the same as your 1st reference color.
If this is not what you expect you might want to check your expectations
But in case you want *my* boxes to look the same as *your* reference 
boxes you should obviously also use "MyColor" for the first box and 
sRGB_to_scRGB(MyColor) for the second one as this does exactly the same 
as the POV-Ray keyword srgb.

-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
> I didn't run it as I do not have Ricky's include file anyway but from
> looking at it there is nothing wrong

https://news.povray.org/%3C5513104c%241%40news.povray.org%3E

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 10/28/2020 um 12:05 schrieb Bald Eagle:
> >
> > But let's say someone borrows a nice texture that has srgb keywords
> > sprinkled throughout its declaration.  The color that pigment color values
> > that get "exposed" to the other elements in the scene are still just - rgb,
> > correct?
> >
> Absolutely...[snip]
> As long one is aware that rgb has to be followed by an linear color
> expression everything is fine while on the other hand an expression like
> rgb <220, 32, 80>/255 together with assumed_gammma 1.0 cries out to
> produce an unwanted result.

Sorry, I was just re-reading the posts here. Did you mean to say
    srgb <220, 32, 80>/255  there?

I assume from what's been said that  rgb <220, 32, 80>/255 is the same as
rgb <0.8627,0.1255,0.3137> -- simple division in 'linear' rgb space.

Whereas SRGB <220, 32, 80>/255 would be the one that "cries out to produce an
unwanted result".

Correct?

(or perhaps I was reading your comment somewhat out-of-context, and that you did
mean  rgb <220, 32, 80>/255 as *turned into*  SRGB <220, 32, 80>/255, with the
warning.)

Just wanted to make sure :-)

Post a reply to this message

Op 30/10/2020 om 10:25 schreef Ive:
> Am 10/30/2020 um 9:15 schrieb Thomas de Groot:
>> Let me stick out my neck once again. ;-)
>>
>> Back in 2014, and following some discussion it appears, I composed 
>> this test scene, without really understanding the matter. What is wrong?
>>
> 
> I didn't run it as I do not have Ricky's include file anyway but from 
> looking at it there is nothing wrong
> 
> The first box under "Ive's macros" should be brighter and less saturated 
> and the second one should be the same as your 1st reference color.
> If this is not what you expect you might want to check your expectations
> But in case you want *my* boxes to look the same as *your* reference 
> boxes you should obviously also use "MyColor" for the first box and 
> sRGB_to_scRGB(MyColor) for the second one as this does exactly the same 
> as the POV-Ray keyword srgb.
> 

Thanks, yes, I get it. There were a couple of things terribly wrong with 
my assumptions at the time. I need to review this again.

-- 
Thomas

Post a reply to this message

Am 10/31/2020 um 8:40 schrieb Thomas de Groot:
>>
>> The first box under "Ive's macros" should be brighter and less 
>> saturated and the second one should be the same as your 1st reference 
>> color.
>> If this is not what you expect you might want to check your expectations
>> But in case you want *my* boxes to look the same as *your* reference 
>> boxes you should obviously also use "MyColor" for the first box and 
>> sRGB_to_scRGB(MyColor) for the second one as this does exactly the 
>> same as the POV-Ray keyword srgb.
>>
> 
> Thanks, yes, I get it. There were a couple of things terribly wrong with 
> my assumptions at the time. I need to review this again.
> 

Oh, just out of curiosity, do you remember where "Ive's macros" are 
from? At the time I wrote CIE.inc and added a few other function to 
lightsys I did definitely prefer this xyz_2_xyz style. And I think scRGB 
wasn't even defined at this time.

-Ive

Post a reply to this message

Am 10/30/2020 um 23:29 schrieb Kenneth:
> Ive <ive### [at] lilysoftorg> wrote:
>>>
>> As long one is aware that rgb has to be followed by an linear color
>> expression everything is fine while on the other hand an expression like
>> rgb <220, 32, 80>/255 together with assumed_gammma 1.0 cries out to
>> produce an unwanted result.
> 
> Sorry, I was just re-reading the posts here. Did you mean to say
>      srgb <220, 32, 80>/255  there?
> 
> I assume from what's been said that  rgb <220, 32, 80>/255 is the same as
> rgb <0.8627,0.1255,0.3137> -- simple division in 'linear' rgb space.
> 
> Whereas SRGB <220, 32, 80>/255 would be the one that "cries out to produce an
> unwanted result".
> 
> Correct?
> 

Err, no!
My point is when somebody uses byte values to express a color he usually 
got them from a color picker, from the Windows build in color selector, 
from an image processing program or somehow directly from an image file.
In all cases these byte values are gamma encoded.
And even he didn't use any of theses apps I'm sure he *thinks* in an 
gamma encoded space as otherwise there is no reason to use byte values 
instead of floating points.
Therefor  srgb <220, 32, 80>/255  is what he actually wants.
And yes, in this case, the the division by 255 is valid (even when it is 
within an non-linear space) because it is NOT a brightness adjustment 
(causing hue shifts) but simply converts the byte values to floating 
point making them fit into the 0.0 to 1.0 range.

-Ive

Post a reply to this message