Am 10/28/2020 um 8:54 schrieb Thomas de Groot:
> 
> Maybe you remember the Bald Eagle / Clipka discussion in 
>
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/

> 
I admire your memory. Especially not just remembering it - but also *where*.

But no I don't think I did read this thread, otherwise I would have been 
tempted to remark that my silly demo scene "cyndi cubes" demonstrates 
the usage of the macros from my file CIE_tools (both part of the 
Lightsys package) and these would be much more powerful (e.g. would also
be able to compensate for whitepoint errors) than Clipka's suggestions.

Which reminds me, these files were written back in 2003, long before 
Christoph even joint the POV-Ray community and meanwhile he already left 
- people come and go and doesn't time fly by?

-Ive

Post a reply to this message

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

> I hope you did not get me wrong. I was not criticizing you - having been
> a programmer once I know very well how easily it happens, but I think in
> former times, mistakes here were quickly spotted. But maybe I'm just
> idealizing the past, like old men often do...

Nope - it's a simple matter of traffic x expertise.
Traffic here is down, and some of us are not yet at the expertise level in some
of the fields where we can just glance at something and the errors and
misconceptions are painfully obvious.
But some of us old men are stubborn, as we often are, and just keep on throwing
ourselves at that learning curve.   :)

> To me it was obvious by just looking at the formula that the linear part
> of the function is no longer the tangent to the exponential part for any
> M <> 1. This did surprise me because you already did switch away from
> the official sRGB gamma correction formula that also has a very small
> gap and makes no perfect tangent. Something that did annoy me since the
> very first draft for sRGB by HP and Microsoft.

Excellent.  A recondite man of great experience.
(You should drop in more often to watch the sht show  ;) )

The intense friction between the theoreticians and empirical experimentalists
and engineers is likely to be eternal  ;)


> Well, now I have read through the whole thread. What a mess. There are
> so many false statements, combined with completely correct statements
> and - as usually - the worst ones: almost true statements.

Oh yes - those are especially naughty.
If you ever wonder why the world we live in is the way it is....


> But if you have any concrete questions, just ask away...

I'll try, but I might just be providing examples of my present level of
[mis]understanding.
(And I'm ok with spreadsheets or graphs or papers to set me on the right path.)

Hmmm.
Conversion formulas aside, what at any given moment are we working with?

When everything is expressed in pigment {rgb <r, g, b,>} at assumed_gammma 1.0,
everything seems pretty straightforward.

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?

Two things which seem pretty unclear are the effect of assumed_gamma srgb,
and/or a light source defined as srgb.  I can conceive the light source as just
being the rgb end result of the srgb conversion formula, like the texture
example, but just checking.
But assumed gamma must affect the whole scene - presumably by doing all of the
color calculations in "srgb color space".  Which with my present understanding,
and peeks into the source code, lead me to speculate that multiplying a pigment
color by a light source color gets a whole lot more complicated.

And reflections.   Metallic reflections.

Does one use srgb for all colors in assumed_gamma srgb scenes or rgb?

What's the proper way to instantiate image_maps that may be encoded by libraries
with in-built gamma handling precorrections?

I guess the concern here with many of my examples / implied questions is the
user trying to do something with srgb, and the software then doing a second
conversion - or the user NOT doing a conversion where needed and winding up not
using the color values needed for consistency with the rest of the scene, or
something getting corrected by the software in the opposite direction because a
user wasn't aware of a required precorrection.

If ANY of that makes any sense.

Post a reply to this message

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

>
> Does one use srgb for all colors in assumed_gamma srgb scenes or rgb?
>

Ah! That's *one* thing that I can answer, from my test scene so far: With
assumed_gamma srgb, the color types don't matter. Both rgb and srgb produce the
exact same result-- srgb colors. Exactly exact, not like srgb colors in
2.2-gamma space, with that *slight* difference we saw. I think Cousin Ricky(?)
or JR (?)mentioned it previously, somewhere in this messy thread, which I didn't
'process' at the time.  ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> ...Exactly exact, not like srgb colors in
> 2.2-gamma space, with that *slight* difference we saw.

Oops, I meant "not like RGB colors in the 'old' 2.2-gamma space..."

But using assumed_gamma srgb is kind of like a more exacting way to get the
old-style assumed_gamma 2.2 look like some of us used to use (and which was
incorrect at the time). Because the effects of *lighting* also change, across
the board. The lighting is no longer 'linear' in the render... which is what
assumed_gamma 1.0 is all about.

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
> Am 10/28/2020 um 2:03 schrieb Kenneth:
> >
> > Or is   srgb 0.7*<.3,.5,.7>  perfectly OK by itself?
> >
> No it isn't. When using the keyword "srgb" you just tell POV-Ray that
> the following color term is "sRGB gamma encoded".
> Multiplying any non linear color value does not only change the
> brightness but also the hue - and is therefor plain wrong.
>
> ...I'm not sure if
> it will swallow this syntax but at least you should get the idea...
>
> #declare C = (srgb <.3,.5,.7>) * 0.7;

Yes, that's very similar to my rather fuzzy understanding of one of Clipka's
older discussions. I should try that (or similar syntax), and compare it to the
function's use.

Thanks to both you and Bald Eagle for clarifying things. Much appreciated.
>
> ...and BTW I just stumbeled over your bold statement
>
> [quote]
> 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.
> [/quote]
>
> I used from the very start (more then 2 decades ago, I guess 3.0 at the
> time) assumed_gamma 1.0 (I already had some experience in the field of
> image processing) and no image I ever created suffered from a washed-out
> look. Some early images of mine did look ugly because my own bad choice
> of colors or bad arrangement of objects but these are no gamma related
> problems ;)
>

That was my MAJOR misunderstanding in the old days-- using assumed_gamma 2.2
simply because the rgb colors I chose didn't look like what I expected...Uh,
washed out from using the values that I *thought* were correct. (I was never any
good at trying to 'massage' linear rgb colors to look right in assumed_gamma 1.0
back then; it seemed so counter-intuitive. So assumed_gamma 2.2 seemed like an
'easy fix', ha.) But I had no clue or worry as to how that affected the
lighting; it looked OK to me at the time. Duh. Once srgb colors came along, I
finally had a long-awaited 'eureka' moment about what I had done wrong, and
finally switched to assumed_gamma 1.0. Better late than never! ;-)
>
>
> And BTW-2 your cityscape looks phantastic and things like this are still
> the strength of POV-Ray even when it has sadly fallen far behind as a
> render engine.
>
Thanks! I truly appreciate the comments.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> >
> > I haven't used POV-Ray in years and never used the srgb keyword in my
> > whole live (I switched to Adobe RGB a long time ago) so I'm not sure if
> > it will swallow this syntax but at least you should get the idea...
> >
> > #declare C = (srgb <.3,.5,.7>) * 0.7;
> >
>
> Maybe you remember the Bald Eagle / Clipka discussion in
>
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/
>
> I digested that at the time in the attached macro. I think (?) this is
> (part of) this answer...
>

Thanks for that! It's probably another discussion that I didn't pay attention to
at the time. :-(

Post a reply to this message

Am 10/28/2020 um 12:05 schrieb Bald Eagle:
> 
> The intense friction between the theoreticians and empirical experimentalists
> and engineers is likely to be eternal  ;)
> 
Having been on both sides during my career did work quite well for me ;)

> 
> When everything is expressed in pigment {rgb <r, g, b,>} at assumed_gammma 1.0,
> everything seems pretty straightforward.
> 
Sure.

> 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. The srgb keyword just tells POV-Ray to consider this color 
as beeing encoded with the sRGB gamma transfer function and converts it 
immediately to its linear equivalent.
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.
In the times before 3.7 it was very hard to work with any kind of image 
map with assumed_gammma 1.0 but Christoph did a really great job in 
fixing all these issues - and IMHO quite underrate as this was an 
endeavor of epic proportions.


> Two things which seem pretty unclear are the effect of assumed_gamma srgb,
> and/or a light source defined as srgb.  I can conceive the light source as just
> being the rgb end result of the srgb conversion formula, like the texture
> example, but just checking.
> But assumed gamma must affect the whole scene - presumably by doing all of the
> color calculations in "srgb color space".  Which with my present understanding,
> and peeks into the source code, lead me to speculate that multiplying a pigment
> color by a light source color gets a whole lot more complicated.
> 
assumed_gamma srgb is close to assumed_gamma 2.2 with all its well known 
drawbacks: POV-Ray will work internally not in a linear color space 
resulting in hue-shifts all over the place.
assumed_gamma srgb is useful when using POV-Ray only as a 
"painting-tool" for drawing graphs or the like...


> Does one use srgb for all colors in assumed_gamma srgb scenes or rgb?

This doesn't matter as rgb just takes the value as is and srgb converts 
into the target space which means in this case no conversion at all 
resulting in the same thing.

> 
> What's the proper way to instantiate image_maps that may be encoded by libraries
> with in-built gamma handling precorrections?
> 
While I have no idea what exactly you do mean by this let me tell you 
this: as long those libraries follow the appropriate image file format 
specifications POV-Ray shouldn't have any problems and otherwise these 
libraries are crap anyway.


> I guess the concern here with many of my examples / implied questions is the
> user trying to do something with srgb, and the software then doing a second
> conversion - or the user NOT doing a conversion where needed and winding up not
> using the color values needed for consistency with the rest of the scene, or
> something getting corrected by the software in the opposite direction because a
> user wasn't aware of a required precorrection.
> 

My point of view here is quite simple: If you aim at any degree for 
realism in your renders you'll have to use assumed_gamma 1.0 and make 
sure that everything that follows the expression rgb is encoded with a 
linear gamma.
This is not my personal opinion, this isn't even an opinion this is a fact.
On the other hand you may not aim for any photo-realism at all then 
POV-Ray allows you to do whatever fits your needs.
This great range of freedom also allows you to mess up things in any 
wanted or unwanted way - this is the price you have to pay for your freedom.


-Ive

Post a reply to this message

Ive <ive### [at] lilysoftorg> wrote:
>
> Well, now I have read through the whole thread. What a mess. There are
> so many false statements, combined with completely correct statements
> and - as usually - the worst ones: almost true statements.
> And then are the things that are simply not relevant anymore (like the
> whole discussion with Warp - Clipka expanded the color_map syntax so
> that none of the complains is still valid).

"Science advances by taking two steps forward and one step back."
Or here, maybe it was 1 step forward and two steps back :-P

I sometimes think of the newsgroups as a kind of 'community sketch pad, where
someone starts out by drawing a few basic shapes or blobs (the "idea"), then
others start adding their own doodles, then erasures, then recapitulations of
the 'history of art', then more doodles... until, hopefully at the end, there is
a 'nice final picture' of the original idea. But sometimes its a real mess
getting there, I agree. (And I'm certainly to blame, here.) But the final result
can be... awesome! Too bad that we can't clean up the mess, by deleting all the
extraneous stuff and dead ends. ;-) Ah, but that's the interesting (and messy)
history of how we got to the end result... to be kept in the archives for all
time, ha. :-O
>
> My point of view here is quite simple: If you aim at any degree for
> realism in your renders you'll have to use assumed_gamma 1.0 and make
> sure that everything that follows the expression rgb is encoded with a
> linear gamma.

I'm genuinely curious about image_map use in that context, and how it is handled
by POV-ray internally. You mentioned, I think, that the *linear* contents of the
image's colors/brightness are used for internal computations(?), regardless of
what we 'see' in the render. If I'm correct about that, do you know if radiosity
from an image_map uses the *linear* values to 'shed its light' into the scene?
In other words, are the radiosity patches' 'colors' based on the linear-color
values of the image? Or does radiosity 'radiate' the 2.2-gamma colors, the image
colors that we 'see' in the render? It would seem that there would be a wide
color difference between the two schemes... with perhaps different visual
results than we might imagine or expect, depending on the scheme used. (A rough
analogy would be, using rgb colors vs. srgb colors for an object's pigment.)

Post a reply to this message

Op 28/10/2020 om 10:33 schreef Ive:
> Am 10/28/2020 um 8:54 schrieb Thomas de Groot:
>>
>> Maybe you remember the Bald Eagle / Clipka discussion in 
>>
http://news.povray.org/povray.advanced-users/thread/%3C57894ece%241%40news.povray.org%3E/

>>
> I admire your memory. Especially not just remembering it - but also 
> *where*.
> 
> But no I don't think I did read this thread, otherwise I would have been 
> tempted to remark that my silly demo scene "cyndi cubes" demonstrates 
> the usage of the macros from my file CIE_tools (both part of the 
> Lightsys package) and these would be much more powerful (e.g. would also
> be able to compensate for whitepoint errors) than Clipka's suggestions.
> 
> Which reminds me, these files were written back in 2003, long before 
> Christoph even joint the POV-Ray community and meanwhile he already left 
> - people come and go and doesn't time fly by?
> 

My memory was from something Christoph said and which I noted down as 
the words of the oracle. So I just had to look for the oracle and there 
it was, with reference et al. ;-)

This whole rgb/srgb business has been a difficult one for me and I just 
try to follow the advices of my learned friends. Breaking the rules more 
often than not I am afraid.

I am sad about all those people who have left and who had something 
tangible to contribute, if only for their amazing scenes. But that is 
life I guess...

-- 
Thomas

Post a reply to this message

Am 10/29/2020 um 0:40 schrieb Kenneth:
> 
> "Science advances by taking two steps forward and one step back."
> Or here, maybe it was 1 step forward and two steps back :-P
> 
Well, even in science - at some point - findings turn into knowledge and 
facts. No astronomer or cosmologist has any doubt about Newtons laws of 
gravity and no - general relativity didn't proof them wrong, it still 
includes Newtons laws. By accepting them and using them we are even able 
to send probes to the border of the solar system by accelerating them 
with sling-shots around Jupiter.


> I sometimes think of the newsgroups as a kind of 'community sketch pad, where
> someone starts out by drawing a few basic shapes or blobs (the "idea"), then
> others start adding their own doodles, then erasures, then recapitulations of
> the 'history of art', then more doodles... until, hopefully at the end, there is
> a 'nice final picture' of the original idea. But sometimes its a real mess
> getting there, I agree. (And I'm certainly to blame, here.) But the final result
> can be... awesome! Too bad that we can't clean up the mess, by deleting all the
> extraneous stuff and dead ends. ;-) Ah, but that's the interesting (and messy)
> history of how we got to the end result... to be kept in the archives for all
> time, ha. :-O

Sure. But then someone (was it you? If so, I'm sorry I do not mean it 
personal) turns up with a link to some past discussion that is meanwhile 
(since 3.7) completely obsolete and frankly, complaining about a minor 
detail that could already be solved within 3.6 (poly_wave as I did 
suggest there) appears to me not like an epic battle, more like a boring 
minor battle of retreat.
So this NG is like the rest of the net. One has to learn how to assess 
and classify the threads written here in the past.

> 
> I'm genuinely curious about image_map use in that context, and how it is handled
> by POV-ray internally. You mentioned, I think, that the *linear* contents of the
> image's colors/brightness are used for internal computations(?), regardless of
> what we 'see' in the render. If I'm correct about that, do you know if radiosity
> from an image_map uses the *linear* values to 'shed its light' into the scene?

Since 3.7 (and assumed_gamma 1.0 of course):

Every image that is loaded via image_map is internally converted 
automagical into a linear representation. POV follows the rules of image 
file format specification and does everything right. In case you KNOW 
that the image you intent to load is different you can use the gamma 
modifier for image maps and tell POV-Ray what it should assume.
Like e.g. image_map {jpeg "my_image" gamma 1.8} for a jpeg file that was 
produced 30 years ago on a Mac.

Every image that is loaded via bump_map is assumed to be already a 
linear representation of the bumpiness (as it should be) and will 
internally be represented as is. In case you KNOW that your map is gamma 
encoded (for whatever reason) you should tell POV-Ray like e.g.
bump_map {jpeg "my_bump" gamma 2.2}.

As POV-Ray has no native support for transparency maps, specularity 
maps, roughness maps, metallicity maps (all of them are pretty much 
standard in professional PBR rendering and as such are always considered 
to be in linear color space as a de facto standard) but can use them 
with the help of the pigment_pattern statement one should always add 
gamma 1.0 to the image_map expression when the image is *NOT* meant to 
be an "image" but a map of some kind.

And radiosity? There is a reason that file file formats like OpenEXR and 
Radiance HDR are already per definition encoded in linear color space.
So, to answer your question, of course uses the radiosity calculation 
linear values.


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.


-Ive

Post a reply to this message