On 4/25/24 08:40 (-4), Bald Eagle wrote:
> 
> So, it looks to me to be like this:
> 
> When POV-Ray uses an assumed_gamma that is <> 1, it funnels everything through a
> function that translates all of the colors from a line to a curve.
> 
> Also, when images are encoded using a gamma <> 1, the same thing happens.
> 
> So if you're going to use byte-encoded (s)rgb values from a color picker, then
> you're not going to be funneling them through any kind of software that "reads
> the image in" - you're manually bypassing that.  So you wind up having to
> manually do the correction yourself with the srgb keyword to pull all of the
> colors back into the linear space _of the pre-rendered SDL file_ before then
> rendering your image with what may be a(nother) non-linear gamma <>1.
> So if you just used the byte-encoded color values, you'd wind up applying gamma
> adjustments twice - the one that is inherent in the sampled image color values,
> and then the one that POV-Ray applies when you render the image with a gamma <>
> 1.

Sounds like you've got it.

> It's early, and the coffee is still sinking in, so I don't fully understand why
> gamma gets applied to an image in the first place - unless it's just a way to
> preserve the original gamma=1 color values for image-editing purposes.

I can't speak for the old pre-standardization days, but nowadays I
believe it's to minimize storage requirements.  If the image is stored
with a linear format, our non-linear perception would lead to banding in
darker areas of the image, and storage overkill in the lighter areas.
Eliminating the banding while keeping a linear format would require
significantly more storage.  By using a gamma that approximates our
perception, we shift the resolution balance towards the darker end, thus
reducing banding without increasing storage requirements.

Note that HDR formats such as EXR can get away with linear storage,
because they use floating point, rather than binary.

Post a reply to this message

hi,

"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> > so, the "take away" is to not mix RGB types and 's' variants in the
> > same scene ?
>
> I don't think it causes any technical problems 'under the hood'-- I sometimes
> mix the two 'flavors' in *object* colors, depending on...whim ;-) But as a
> *general* rule, it is probably not a good idea to mix one flavor in LIGHTS with
> another flavor on objects-- only because the resulting object colors would be
> somewhat unexpected.

ouch.  exactly the habit I've fallen into, srgb light + rgb all else.  </grin>



> Consider the following combinations ...

thank you very much for that.  simple and effective.


> Personally, I like to use the 3rd combination...just a personal choice due to
> familiarity with how colors in other graphics apps appear to me. No 'washed-out'
> colors, in other words. I have never been very good at choosing plain rgb
> triplets to get what I want.

same here, I need a visual of the colour, usually.  may try and address "the
habit".


@ingo, "I wouldn't miss srgb."

thanks for providing a "sideways perspective", appreciated.


regards, jr.

Post a reply to this message