Am 27.12.2015 um 01:19 schrieb Mike Horvath:
> I'm rendering the attached scene on Windows, but the default
> assumed_gamma value of 1.0 seems too light. Switching it to 2.2 is much
> better. Is there something wrong with my scene, because as I understand
> it, you're really not supposed to mess with assumed_gamma.

And that's particularly true when rendering images that are supposed to
illustrate colour models.

As for how the image should properly look, that actually depends on the
colour model you're trying to illustrate: If the "value" parameter is
supposed to be linear, then it /must not appear/ linear. If the
parameter is instead supposed to be gamma-encoded, then approximate
linear /appearance/ is the right thing.

This is because when it comes to brightness, what /appears/ linear to
the eye actually isn't, and is actually close to a gamma of roughly 2.5.


Now while this would at first seem to imply that using assumed_gamma 2.2
would be the right thing to do if "value" is supposed to be
gamma-encoded, there is one thing to be aware of: Blending
/chromaticity/ in this mode is pretty messy. Whether it would give the
right results again would depend on the details of the colour model.


My suggestion would be to stick to assumed_gamma 1.0, and use POV-Ray
3.7.1's new colour_map/pigment_map "blend_mode" and "blend_gamma"
parameters for more control over the colour gradients. Use "blend_mode
1" for entirely linear interpolation, "blend_mode 2 blend_gamma 2.2" for
blending matching a gamma of 2.2, or "blend_mode 3 blend_gamma 2.2" to
get gamma 2.2 interpolation of brightness but gamma 1.0 interpolation of
chromaticity.

The defaults for these parameters are "blend_mode 0" (which performs
gamma-agnostic blending, effectively matching the assumed_gamma setting)
and "blend_gamma 2.5". Note that as opposed to most other gamma
settings, "srgb" is not a legal value for "blend_gamma".

Post a reply to this message

On 12/26/2015 9:42 PM, clipka wrote:
> My suggestion would be to stick to assumed_gamma 1.0, and use POV-Ray
> 3.7.1's new colour_map/pigment_map "blend_mode" and "blend_gamma"
> parameters for more control over the colour gradients. Use "blend_mode
> 1" for entirely linear interpolation, "blend_mode 2 blend_gamma 2.2" for
> blending matching a gamma of 2.2, or "blend_mode 3 blend_gamma 2.2" to
> get gamma 2.2 interpolation of brightness but gamma 1.0 interpolation of
> chromaticity.
>
> The defaults for these parameters are "blend_mode 0" (which performs
> gamma-agnostic blending, effectively matching the assumed_gamma setting)
> and "blend_gamma 2.5". Note that as opposed to most other gamma
> settings, "srgb" is not a legal value for "blend_gamma".
>

Where do I download version 3.7.1?


Mike

Post a reply to this message

Mike Horvath <mik### [at] gmailcom> wrote:
> On 12/26/2015 9:42 PM, clipka wrote:
>
> Where do I download version 3.7.1?
>

I think it's here...

https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.8141620

This concept of chromaticity/brightness/gamma is completely new to me (as
regards POV-Ray rendering); ditto the new 'blend' tools in 3.7.1. Clipka will
(hopefully!) give us more info. A question I would have is this: Are the new
blend tools specifically for creating accurate/specialized 'color models' like
you're doing here (as well as for your Munsell color wheel render that you
posted earlier)-- or are the tools meant to be used for our everyday, normal
POV-Ray scenes as well?

Very interesting!

Post a reply to this message

Am 28.12.2015 um 04:14 schrieb Kenneth:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> On 12/26/2015 9:42 PM, clipka wrote:
>>
>> Where do I download version 3.7.1?
>>
> 
> I think it's here...
> 
> https://github.com/c-lipka/povray/releases/tag/v3.7.1-alpha.8141620

That would be one version that does the job, but it isn't the newest. My
recommendation would be the newest version from here:

https://github.com/c-lipka/povray/releases


> This concept of chromaticity/brightness/gamma is completely new to me (as
> regards POV-Ray rendering); ditto the new 'blend' tools in 3.7.1. Clipka will
> (hopefully!) give us more info. A question I would have is this: Are the new
> blend tools specifically for creating accurate/specialized 'color models' like
> you're doing here (as well as for your Munsell color wheel render that you
> posted earlier)-- or are the tools meant to be used for our everyday, normal
> POV-Ray scenes as well?

Those colour and pigment map blend settings are indeed intended for
everyday normal use. There are plenty of other ways to achieve what Mike
may need, so I wouldn't have implemented the feature just for him.

Instead, I'd like to give credit to Warp, who sowed the seed for this
feature back in the days when 3.7.0 was nearing completion, with his
persistent refusal to accept that "assumed_gamma 1.0" is the holy grail
of getting good images -- which of course it is, and his stubborn
position was of course entirely unfounded... except, erm... well, not quite.

As you're new to the topic of gamma, let's give you a quick overview:

- Historically, computer graphics used cathode ray tube (CRT) displays.
In a CRT the brightness of pixels on screen is controlled by modulating
a particular voltage applied to the CRT, but the resulting brightness
does not follow this voltage in a linear fashion, but according to a
power-law, i.e. brightness = voltage^gamma, where gamma is typically
somewhere around 1.8 to 2.2. To keep the display electronics and the
computer's display interface simple, neither contained any mechanism to
compensate for this distortion, so images intended to be presented on a
computer display had to be /gamma corrected/ first to take that
distortion into account. Usually this was already done during image
creation, and the image saved in a /gamma pre-corrected/ format.

- This wasn't such a bad thing though, as the human visual perception is
also highly non-linear; if we'd use an 8-bit linear brightness format,
the precision would be far too low in the dark portions of an image
(leading to visible colour banding), while being far too high in the
bright portions of an image (leading to a waste of storage space); but
it so happens that 8 bit provides just about enough precision in both
dark and bright portions of /gamma pre-corrected/ images. Thus, this
format also makes for an efficient encoding, and in modern file formats
it is therefore typically referred to as /gamma encoding/.

- In today's graphics industry, conceptually gamma pre-correction no
longer plays any role, because correcting for the specific gamma of
whatever display happens to be connected is instead done by the graphics
application, operating systems, graphics driver and/or some calibration
feature built into the display; gamma encoding still lives on however --
even in the way colour information is input or presented in user
interfaces for selecting particular colours.

- As a matter of fact, gamma pre-correction and later gamma encoding
used to be so ubiquitous in the world of computer graphics, /and/
appeared to be so natural, that for a very long time people didn't even
realize that it was there -- including the original authors of POV-Ray.
This is a problem, because POV-Ray needs to do a lot of calculations
with brightness values, and the formulae for those calculations were
written under the silent (but wrong) presumption that colour information
was encoded linearly.

- POV-Ray 3.6 was the first version of POV-Ray to ever tackle the issue
of gamma, by introducing the "assumed_gamma" keyword and the
"File_Gamma" (or was it "Display_Gamma"?) ini file setting. In this
simple model, "assumed_gamma" told POV-Ray what gamma all the input
colours were pre-corrected for, while ini file setting told POV-Ray what
gamma to pre-correct all its output for (that is file output and preview
display). However, this was essentially it -- POV-Ray still did all its
internal computations as if all colours were linear, even if
"assumed_gamma" was set to something else than 1.0. Also, setting
"assumed_gamma" to 1.0 did solve this one problem, but it required all
colours in the scene file to be specified using linear values and, worse
yet, it meant all input image files were also assumed to use linear
encoding.

- POV-Ray 3.7 solved (to my knowledge) virtually all the problems where
the 3.6 gamma handling fell short: It introduced separate ini file
settings for the two output paths (to file, and to preview display) so
that output images could be pre-corrected for a different display gamma
than the system it was previewed on; it introduced the "srgb" keyword so
that colours in the scene file could be specified in a format faimilar
to most users and easily produced by colour picker tools; and it
introduced a set of rules, as well as keywords to override them, to try
to infer the gamma for which input images are pre-corrected for.

Except for the problems that Warp still saw. His annoying feedback had
already inspired a good deal of the gamma improvements. Now he argued
that "assumed_gamma 1.0" couldn't be right because gradients would look
crappy.

He was wrong about "assumed_gamma 1.0"; it did a perfect job, and I
tried to explain why it was right.

To no avail. He was adamant that they did look crappy, and that
"assumed_gamma 2.2" did a much better job on them. Which, as I openly
admit now, and silently admitted back then, was an entirely correct
observation.

It wasn't the fault of "assumed_gamma 1.0" though, but rather the plain
fact that for artistic purposes non-linear interpolation of gradients is
desirable.

For brightness gradients, that is. When it comes to gradients between
different colours with same brightness, using that same interpolation
causes a dip in the brightness around the center of the gradient.

I tried a whole bunch of different colour models to do the interpolation
in, but none got both types of gradients right. I gave up, and 3.7 went
out the door without a solution for this problem.


Later however, I found the time to revisit the issue, and found that
good results /can/ be obtained; the key is to split up the colour
information into brightness (i.e. the weighted sum of the colour
channels) and chroma (i.e. the relative balance between the colour
channels), interpolate the brightness non-linearly and the chroma
linearly, and then re-combine the two properties into the new result colour.

That is exactly what "blend_mode 3" does: It was designed to give you
the most aesthetically pleasing gradients you could ever ask for.
"blend_mode 0" is only there for backward compatibility, "blend_mode 1"
is there to do physically correct purely linear interpolation, and
"blend_mode 2" is there just for completeness' sake.

Post a reply to this message

Christoph, as always, we are much indebted to your work and 
comprehensive explanations. I won't say that I understand everything, 
but I shall do my best to implement this in my work as much as possible.

-- 
Thomas

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> - POV-Ray 3.6 was the first version of POV-Ray to ever tackle the issue
> of gamma, by introducing the "assumed_gamma" keyword and the
> "File_Gamma" (or was it "Display_Gamma"?) ini file setting.

The assumed_gamma keyword was present in POV-Ray 3.5, and it was Display_Gamma.

> Except for the problems that Warp still saw. His annoying feedback had
> already inspired a good deal of the gamma improvements. Now he argued
> that "assumed_gamma 1.0" couldn't be right because gradients would look
> crappy.

Warp's stubbornness has already inspired an update to AndroidRobot in the Object
Collection, and inspired gamma awareness in two upcoming modules that I haven't
released yet.  (But he is still wrong.)

P.S.  To my eyes, the hue gradients look best around gamma 1.5 or 1.6.  (I no
longer trust my eyes enough to say which gammas are best for chroma and
lightness.  I thank Thomas de Groot for jolting me into the realization that my
lying eyes should not be trusted.)

Post a reply to this message

In article <5680cc73@news.povray.org>, ano### [at] anonymousorg says...
> interpolate the brightness non-linearly and the chroma
> linearly,

This is one of those things that is so obvious and simple once someone 
solves it.

Post a reply to this message

On 27-12-2015 3:42, clipka wrote:
> My suggestion would be to stick to assumed_gamma 1.0, and use POV-Ray
> 3.7.1's new colour_map/pigment_map "blend_mode" and "blend_gamma"
> parameters for more control over the colour gradients. Use "blend_mode
> 1" for entirely linear interpolation, "blend_mode 2 blend_gamma 2.2" for
> blending matching a gamma of 2.2, or "blend_mode 3 blend_gamma 2.2" to
> get gamma 2.2 interpolation of brightness but gamma 1.0 interpolation of
> chromaticity.
>

I tried it but couldn't figure out the usage of these new parameters as 
I got error messages under 3.7.1, in the pigment block as well as in the 
global_settings. Where to put them?
-- 
Thomas

Post a reply to this message

Am 30.12.2015 um 13:31 schrieb Thomas de Groot:
> On 27-12-2015 3:42, clipka wrote:
>> My suggestion would be to stick to assumed_gamma 1.0, and use POV-Ray
>> 3.7.1's new colour_map/pigment_map "blend_mode" and "blend_gamma"
>> parameters for more control over the colour gradients. Use "blend_mode
>> 1" for entirely linear interpolation, "blend_mode 2 blend_gamma 2.2" for
>> blending matching a gamma of 2.2, or "blend_mode 3 blend_gamma 2.2" to
>> get gamma 2.2 interpolation of brightness but gamma 1.0 interpolation of
>> chromaticity.
>>
> 
> I tried it but couldn't figure out the usage of these new parameters as
> I got error messages under 3.7.1, in the pigment block as well as in the
> global_settings. Where to put them?

Right smack at the beginning of the colour_map or pigment_map block,
like so:

    pigment {
        gradient x
        colour_map {
            blend_mode 3
            blend_gamma 2.0
            [ 0.0 rgb <0,0,0> ]
            [ 1.0 rgb <1,0,0> ]
        }
    }

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 28.12.2015 um 04:14 schrieb Kenneth:

>
> Later however, I found the time to revisit the issue, and found that
> good results /can/ be obtained; the key is to split up the colour
> information into brightness (i.e. the weighted sum of the colour
> channels) and chroma (i.e. the relative balance between the colour
> channels), interpolate the brightness non-linearly and the chroma
> linearly, and then re-combine the two properties into the new result colour.
>

It took me awhile to absorb your explanation (which is excellent, as always.)
Although the subject of gamma in POV-Ray isn't new to me, this new (subtle?)
topic of chromaticity/brightness certainly is. I have to admit that I never
noticed any 'flaws' in color/brightness gradations in my scenes (having 'worked
around' any odd-looking surprises, at least to my own satisfaction.) But your
explanation of the underlying problems-- and your new tools to solve them-- are
real 'eye-openers', if you'll pardon the pun.  ;-) I'm happily amazed that you
(and Warp) continued to think about this topic.

Thanks for your hard work!

Post a reply to this message