|
|
|
|
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6
Date: 30 Oct 2020 04:15:36
Message: <5f9bcba8$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6
Date: 31 Oct 2020 03:40:40
Message: <5f9d14f8$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6
Date: 31 Oct 2020 12:41:34
Message: <5f9d93be$1@news.povray.org>
|
|
|
| |
| |
|
|
Op 31/10/2020 om 11:52 schreef Ive:
>
> 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.
>
I am not sure. I wrote this scene in 2014 but I don't remember where I
got the functions from. It must have been from a discussion at the time
in these n.g's - I browsed around but I am unable to find a probable
source; mention is made several times of CIE, so I wonder if I did not
get it from there. Sorry.
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
From: Thomas de Groot
Subject: Re: Stock colors and assumed_gamma 1 in POV-Ray 3.6
Date: 5 Nov 2020 03:04:33
Message: <5fa3b211$1@news.povray.org>
|
|
|
| |
| |
|
|
Op 31/10/2020 om 11:52 schreef Ive:
> 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.
>
Maybe from an "earlier" version of CIE? and/or Lightsys? That seems the
most logical to me.
In the mean time I reviewed my scene code and added the latest Bald
Eagle macros to the collection (see image and scene file attached). I
added all the macros to the scene file. This is what it represents:
(1a) my reference color in linear color space;
(1b) my reference color in standard color space;
(2.1a) Ive's: conversion rgb->srgb of (1a);
(2.1b) idem but with Clipka's saturation/brightness boost added;
(2.2a) Ive's: conversion back srgb->rgb;
(2.2b) idem from the boosted color;
(2.2c) idem but using (1b);
(3.1a) Cousin Ricky's: conversion rgb->srgb of (1a);
(3.1b) idem but with Clipka's saturation/brightness boost added;
(4.1a) Bald Eagle's: conversion rgb->srgb of (1a);
(4.1b) idem but with Clipka's saturation/brightness boost added;
(4.2a) Bald Eagle's: conversion back srgb->rgb;
(4.2b) idem from the boosted color;
(4.2c) idem but using (1b).
These are macros applied indiscriminately. It seems immediately obvious
that Bald Eagle's macros do not need the saturation/brightness boost,
except probably where 4.2c is concerned.
I leave it to the experts to judge if this little exercise (which I
enjoyed doing btw) is of any real use. ;-)
--
Thomas
Post a reply to this message
Attachments:
Download 'srgb_test.png' (84 KB)
Download 'utf-8' (15 KB)
Preview of image 'srgb_test.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tho### [at] degrootorg> wrote:
>
> In the mean time I reviewed my scene code and added the latest Bald
> Eagle macros to the collection (see image and scene file attached). I
> added all the macros to the scene file. This is what it represents:
>
Thanks for making this all-inclusive demonstration scene, and for posting the
code. Now I need to 'digest' all of the various color-conversion methods and
pitfalls, as well as all of the message posts here.
I am still working on my own demo scene ;-) It will be a different way of
visualizing the color conversions-- to include rgb-vs-srgb colors in lights as
well.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |