On 2021-04-01 12:45 PM (-4), Ive wrote:
> Am 4/1/2021 um 16:53 schrieb William F Pokorny:
>>
>> As a habit I've been declaring colors using srgb space and multiplying
>> for adjustment after. The thought being the declared srgb color is a
>> set color in a set color space. Further, I can refer to that 'srgb
>> color' by common web name and always get that color in my render.
>>
>> By coding this way I'm also protecting against 'run away' intensity
>> due multiplications ahead of the srgb adjustment where the multiplied
>> values end up larger than 1.0(a). I only multiply post srgb input; I
>> only multiply the previously defined color name.

This is a good policy.  In fact it would seem the only policy that works.

>> (b) Ponder two. Would it be better to warn or err/fail during parse
>> where the srgb keyword sees channel inputs >1.0? This would force
>> users to deal explicitly with questionable channel input; force them
>> to explicitly set the linear intent.
> 
> IMHO yes.

This sounds like an excellent idea; and for negative values as well.  It
would even have forestalled Kenneth's problem to begin with.

However, it would break some existing scenes, including Norbert Kern's
"Light & Shadows."  I'm not sure how to handle a feature that was
allowed to be used outside its defined domain.  Perhaps a version check
could resolve this, or maybe just stick with a warning?

> I did argue a bit with Christoph at the time he was making the
> suggestion for introducing the srgb keyword.
> I was against it and my arguments where pretty much the problems you are
> mentioning here.
> Christoph's argument was mainly that whole purpose of the srgb keyword
> is to make life easier for people who use a color picker within any
> paint software to select their colors out of pictures.
> Well, reality is that people are using it because they think it somehow
> solves all gamma related problems -  but without actually understanding
> what it does.

I must say I did not foresee all the confusion that the srgb keywords
would cause, perhaps because I understood the general concept of gamma
before I started using POV-Ray.  But I still think the keywords are a
great convenience, given Christoph's rationale--especially considering
that the color definitions in POV-Ray's own colors.inc are gamma
pre-encoded, whether or not the author of that module knew that they were.

However, the Reference Manual does leave the impression that the
keywords are a general gamma solution, even if that wasn't the intent.
While it does mention third party color sources, it doesn't warn against
inappropriate usage.  What constitutes "inappropriate usage" may need to
be fleshed out.

Post a reply to this message