> Apparently, Image A *is* how we see things in the real world, with our eyes.
> Which is of course combined with real-world 'radiosity' and fill light, so we
> probably don't perceive things *exactly* that way, but close to it. Whereas,
> Image B is what many of us *think* we should see-- probably based on how photos
> and films of the real world look, at least with older film technology. I think
> that was part of Warp's fundamental argument with Clipka, back in 2010 (and my
> own argument then too.)
> 
When looking at the Moon, what I see is more like A, but with the dark 
part similar to B.
When the object is MUCH closer, like a close by concrete ball, then, 
it's A all the way.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> So, I'm tired, and my eyeballs hurt, so I sought out some
> isobutylphenylpropionic acid and a gin & tonic.
>
> Warp and clipka always went at it with gusto!   :D
> We should email Warp and drag him back in....
>
> I think, if we're going to play with these things, and be able to reliably and
> usefully understand WTH is going on, then some sort of visual correspondence
> roadmap ought to be made.
>
> Consider:
>
> A box has a pigment with 2 image_maps, blended in a pigment_map, illuminated by
> a light source, rendered by POV-Ray, displayed on a monitor, and seen by you.
> ...

I'm afraid that we also need to take into account any changes made by the driver
for the graphic card, the driver for the monitor and perhaps the operating
system.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k

Post a reply to this message

On 2020-10-20 2:32 PM (-4), Alain Martel wrote:
>>
> When looking at the Moon, what I see is more like A, but with the dark 
> part similar to B.
> When the object is MUCH closer, like a close by concrete ball, then, 
> it's A all the way.

That's because there is very little back lighting in outer space, unless 
the Moon is in a crescent phase.

Post a reply to this message

"Tor Olav Kristensen" <tor### [at] TOBEREMOVEDgmailcom> wrote:
[Bald Eagle wrote:}
> >
> > Consider:
> >
> > A box has a pigment with 2 image_maps, blended in a pigment_map, illuminated by
> > a light source, rendered by POV-Ray, displayed on a monitor, and seen by you.
> > ...
>
> I'm afraid that we also need to take into account any changes made by the driver
> for the graphic card, the driver for the monitor and perhaps the operating
> system.
>
Yes-- and I am currently grappling with such changes, on my Win 7 computer
(built-in video card) and my cheap-o 'TV monitor': basically, increased
orange/yellow color-intensity in any 'saved' image file, from any source. And
slightly darkened image files from POV-ray. It is either due to the monitor
itself, or I am using the wrong ICC profile in the computer (currently sRGB,
which I thought would be correct.) In any case, the only *reliable* viewing
environments that I completely trust are 1) the POV-ray preview window, and 2)
Ive's IC/Lilysoft image-viewing app. Everything else is skewed.

A new *real* computer monitor would certainly help...unless the problem is
somewhere in the computer itself.

I miss my old and trustworthy CRT monitor.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> In the same way that the graph shows arrows representing conversions between
> the different curves, I'd like it if we could have a collection macros that
> do the same thing - with a switch to turn on some text output to the debug
> stream describing the inputs and results.  "Converting linear rgb <r, g, b>
> to sRGB <sr, sg, sb>..."   or some such thing.
....

> I would also like to have a way to do what clipka was cautioning me
> about - where a palette of srgb colors could be lightened or darkened using
> a multiplier, and the math would be correct to do it in the proper color
> space.
>
> The new tone-adjusting formulas are:
>
> #declare SRGB_Encode = function (C, M) {
>  select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> }
>
> #declare SRGB_Decode = function (C, M) {
>  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> }
>
> using M as a multiplier.  Looks like it works correctly, even with  M > 1.
> Perhaps it's not "right", but it's the way I envisioned its usage.
>

I took your advice-- I'm currently working on a complex text scene, taking into
account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
because I personally want to form an opinion about whether or not to use srgb
colors for lights as well, simply to get the color I 'visually' expect as
opposed to 'linear' rgb colors that are intrinsically washed-out in an
assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
'rgb' there, but my test scene will compare the difference.

And I plan to use your excellent conversion functions; it looks like you figured
out how to 'correctly' multiply srgb colors with an M, which is a more complex
situation than multiplying simple rgb colors. Your coding skills are more
sophisticated than mine, so I'll take your word for it ;-)

Can I assume that, if I choose *not* to use the M-multiplier in your functions
(for my simpler test scene), I could just change the function like so? and with
C being a typical 3-part color vector like <.3,.6,.9>)?:

#declare SRGB_Encode = function (C) {
 select (C-0.0031308, C*12.92, C*12.92, (1.055 * pow (C, 1/2.4) - 0.055))

The reason being, that I might restrict any color values to between 0.0 and 1.0,
for a better 'basic' test of things. (Although, I might change my mind.)

When my test scene is complete and working properly, I'll post it elsewhere.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:

> I took your advice-- I'm currently working on a complex text scene, taking into
> account assumed_gamma, and rgb/srgb colors for both objects AND light sources--
> because I personally want to form an opinion about whether or not to use srgb
> colors for lights as well, simply to get the color I 'visually' expect as
> opposed to 'linear' rgb colors that are intrinsically washed-out in an
> assumed_gamma 1.0 environment. I know that Clipka recommended we stick with
> 'rgb' there, but my test scene will compare the difference.

Yes, the washed-out thing is very off-putting.
In situations where there is no readily-available and easily-understood
documentation that adequately explains how all of the pieces influence the final
result, I think it's just as important to understand what _doesn't_ work (and
why ) as it is to be aware of what does work.

In the absence of any "proper" way to achieve an end result, the Warp et al
approach of using assumed_gamma 2.2 is both understandable and unavoidable.
However, if there _exists_ a "proper" method by which to achieve the exact same
results, then it's important to people who spend a lot of time using the system
to be proficient with that, even though there may be specific instances where
they purposefully don't.  (In this instance, using the "proper" gamma for all of
the reasons that clipka outlined involving lighting, monitors, highlights and
shadows, etc.)


> Can I assume that, if I choose *not* to use the M-multiplier in your functions
> (for my simpler test scene), I could just change the function like so? and with
> C being a typical 3-part color vector like <.3,.6,.9>)?:




A multiplier of 1 is ... no multiplier at all.   ;)

Post a reply to this message

> "Bald Eagle" <cre### [at] netscapenet> wrote:

> >
> > The new tone-adjusting formulas are:
> >
> > #declare SRGB_Encode = function (C, M) {
> >  select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> > }
> >
> > #declare SRGB_Decode = function (C, M) {
> >  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> > }
> >
> > using M as a multiplier.  Looks like it works correctly, even with  M > 1.
> > Perhaps it's not "right", but it's the way I envisioned its usage.
> >
>

[off-topic, sort of...]
Here's some food for thought, which just occured to me-- not about your
functions, but about the conversion formulae themselves (Wikipedia and
elsewhere):

The conversion formulae use a "2.4 gamma" in the computations-- whereas, in
POV-ray, and running antialiasing in a scene, Clipka chose a "2.5 gamma" for the
antialiasing gamma (this in v3.8xx). Maybe I'm cluelessly 'comparing apples to
oranges', but I wonder why Clipka didn't choose "2.4 gamma" instead? I suppose
there *is* a reason, but... :-O

Just something to keep you and me up at nights, wondering about the
difference... ;-)

Post a reply to this message

Am 10/18/2020 um 23:22 schrieb Bald Eagle:
> 
> The new tone-adjusting formulas are:
> 
> #declare SRGB_Encode = function (C, M) {
>   select (C-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C, 1/2.4) - 0.055)*M)
> }
> 
> #declare SRGB_Decode = function (C, M) {
>   select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4)*M)
> }
> 
> using M as a multiplier.  Looks like it works correctly
 >


Nope. Both functions are wrong far all M <> 1.0!

If you do not already see this by looking at the formulas just check it: 
Use SRGB_Encode for any value of C and then the result for SRGB_Decode. 
This should give the original value of C.


The correct functions would be

#declare SRGB_Encode = function (C, M) {
  select (C*M-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C*M, 1/2.4) 
- 0.055))
}

#declare SRGB_Decode = function (C, M) {
  select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4))*M
}


It worries me for this NG that stuff like this stays uncorrected for 
over 10 days.

-Ive

Post a reply to this message

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

>
> The correct functions would be
>
> #declare SRGB_Encode = function (C, M) {
>   select (C*M-0.0031308, C*12.92*M, C*12.92*M, (1.055 * pow (C*M, 1/2.4)
> - 0.055))
> }
>
> #declare SRGB_Decode = function (C, M) {
>   select (C-0.040449936, C/12.92, pow ((C+0.055)/1.055, 2.4))*M
> }
>
> It worries me for this NG that stuff like this stays uncorrected for
> over 10 days.
>

Well, see? It did get corrected :-) (Not that I would know which is which,
mathematically speaking; functions are sometimes a 'black box' to me.) I like to
think that the newsgroups are *eventually* self-correcting, like after-the-fact
letters to a scientific publication.

I hate to admit that I have not yet tried Bald Eagle's functions; perhaps a
purely visual test would have shown that something might be amiss. [Sorry, B.E.,
I've been busy with other coding.]

He did say, ..."Perhaps it's not "right", but it's the way I envisioned its
usage."

In any case, thanks for the update.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> Ive <ive### [at] lilysoftorg> wrote:
>
> >
> > The correct functions would be
> > [snip]

Just to clarify, in my own mind, some things about the use of these functions
(because I'm currently working on an all-inclusive test scene about this stuff):

When using assumed_gamma 1.0, and in POV-ray's preview render:

If I want to *multiply* an RGB color,  rgb 0.7*<.3,.5,.7> would be OK to do.

But if I want to multiply an SRGB color,  srgb 0.7*<.3,.5,.7> would NOT be the
correct way to do it, to get the 'expected' color result (if I understand some
of Clipka's older remarks); I would instead need to use a somewhat different
multiplication scheme. Is that what these 'multiplication functions' are for--
the way to properly 'multiply' an SRGB color?

Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?

Or am I way off base as to what the functions themselves are meant for?

Post a reply to this message