Le 12/09/2009 11:42, clipka nous fit lire :
> Le_Forgeron schrieb:
> 
>> why not go utf-8 and use a real gamma γ or Γ ? (aaos)
> 
> Cumbersome to input on most machines (as I already mentioned, I
> personally wouldn't mind, because I'd intend to stick mostly to linear
> colors anyway, but I'd expect some people to think otherwise :-)), let
> alone that POV-Ray's support for utf-8 is rather... well, let's call it
> "marginal" ;-)
> 
> (BTW, I need to correct my initial tongue-in-cheek suggestion of \u393
> in favor of \u3B3, as the uppercase Gamma would be inappropriate, being
> reserved for other mathematical purposes...)
> 

yes... all greek letters have already been used for one purpose or
another, according to the field of sciences.
Same for some hebrew letter (aleph anyone ?)

>     #declare MyColor = color rgb <0.5,0.5,0.5>;
>     ...
>     pigment { @MyColor }
> 
> As most colors will be from the same "gamma space", a
> global_settings{...} or - possibly better - default{...} parameter
> should be enough to specify the gamma to be used for that operator.

This sucks! a global/default would generate more issue when merging
includes from different authors.

At worst, I can envision a default setting (of 2.2, due to sRGB curve)
when providing only a 3D vector to a 4D expecting "srgb" (the "s" would
be optional, defaulting to

> This
> will reduce redundant typing effort, and will also improve legibility

Legibility ? with an opaque glyph like @ ? How do you associate that
with a gamma correction ?

typing effort... @ requires me to use 2 fingers at the same time, that's
not an easy typing. Only APL-geek would find that easier.

I still recommend using a plain classical letter(or name).

> ("duh, is that a 5D or 6D vector??"). Note that it could be changed
> anytime if needed (though I guess it would have to be local to any
> include file to avoid trouble). For exceptional cases, an explicit
> "gamma(COLOR,g)" function might be provided.

I'm still thinking that the correct order should be gamma(g,COLOR)

The issue with 6D vector is that current code might not have support for
it yet (5D is the maximum I have seen)

> 
> Or, maybe an extended syntax can be used for the operator, such as in:
> 
>     default { gamma 2.2 }
> 
>     color rgb @<0.5,0.5,0.5>     // for default gamma
>     color rgb @[1.8]<0.5,0.5,0.5> // for explicit gamma

Arghhh... So cryptic!

color srgb <1.8,0.5,0.5,0.5>


Wondering nevertheless about the "s"... maybe another letter ? c for
corrected ?

color srgb <0.5,0.5,0.5> // for classical srgb 2.2 gamma correction
color crgb <1.8,0.5,0.5,0.5> // for custom correction of 1.8

Do we really need srgbtf ? could we not just use
"color srgb<...> filter 0.4 transmit 0.3" ?

BTW... what about separating filtering color from reflecting color ?
(allowing a rgb (or whatever 3D) for filter )(backward compatible, as
plain number get promoted to vector when needed, so filter 0.4 stay
valid (but get a change of behaviour, as previously rgbf<1,0,0,.5> would
have filtered only 50% of red, no green, no blue; filter 0.4 would be a
grey 40%... even with a red reflecting surface; back to old behavior
with filter <0.5,0,0>)

Post a reply to this message