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

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

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