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