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