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