Le_Forgeron schrieb:
>> 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.

I object to the notion of this to "suck", as you put it. Granted, it may 
have its drawbacks in that particular case. Still, as long as includes 
are only included (instead of manually merged), and can have their own 
local default gamma, this is a non-issue.

Also note that when manually merging includes, you're opening a can of 
worms anyway, like differing #version settings, potential variable name 
clashes, total dimensions, media densities, and other some such, so I 
see no great harm in adding one single more thing to take care of in 
this case.

On the other hand I see a significant benefit of not having to type the 
gamma value all the time.

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

How do you associate ! with logic negation, or | with logical and? How 
do you associate <..,..,..> with vectors?

Why, by convention of course.

Not to mention that at present, I'm considering the @ sign to be just a 
working draft.

> 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.

Oh Hell, two fingers on keyboard! What a catastrophe!

Hey, get real: You need to press the "shift" key for quite a host of 
things, I guess. As a German, for instance, I need to press "shift" to 
get a multiplication asterisk, dividing slash, opening or closing 
parentheses, quotes etc, and "altGr" to get curly braces or square brackets.

With your proposed solution, you need to type the gamma value over and 
over again - which obviously does not require to press multiple keys 
simultaneously, but only a one-fingered man would find that easier than 
having to type a single character - even if it would involve a 
three-finger move.

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

that would be all the same to me.

> 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>

Arghhh... Even more cryptic!

With the @[GAMMA]<...> syntax, at least it's clear at first glance that 
gamma correction is performed (provided of course the reader is familiar 
with the "@" sign being used for that purpose).

With the srgb <GAMMA,...> syntax, you have the following issues:

- While there is indeed no "natural" association of the "@" symbol with 
gamma correction, neither is this the case for the "s" prefix. The user 
would have to know that the sRGB color space includes some gamma 
adjustment - and would then be all confused why he should specify a 
gamma, because sRGB does not allow for choosing a gamma at will. So no 
bonus for the srgb syntax as being more "natural".

- At a quick glance, "srgb" might be mixed up with all the other "rgb" 
things, which already make it difficult to quickly identify the blue 
component (is this rgb, so that blue is the rightmost component? is this 
rgbt or rgbf, so that blue is the second to right? Or is this even 
rgbtf, so that blue is the third to right?); your proposal adds to this 
the problem of quickly identifying color components by starting from the 
left of the vector.

- The syntax you propose might also have users think that gamma would be 
a component of a color vector - when in fact it is just some math 
applied to the color.

- As already mentioned, it would prevent performing gamma-correction as 
early as possible on colors not explicitly specified as such, but as a 
standard 3D vector instead. For instance, it would absolutely prevent 
the use of gamma-corrected colors in a macro that would expect the 
colors to be passed as pure 3D vectors or as individual components.

No, I really don't see your proposed syntax as any less cryptic - rather 
to the contrary.


> 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>)

A bit problematic - not only due to the change in semantics (which would 
be easily addressed by promoting "transmit" to an RGB color vector 
instead, and dropping "filter" altogether). Still, this would create 
problems with some legacy syntax variants, such as:

     color rgb <R,G,B> transmit T filter F
     color filter F red R green G blue B

Additional problems would arise of the poor separation of vectors and 
colors in POV-Ray, so various scripts may rely on the 4th and/or 5th 
fields of 5D vectors to be accessible via the .filter and .transmit 
keywords, respectively, and others may rely on certain vector math 
operations working on colors in a particular way.

Still, there may be ways to overcome even these obstacles, and indeed 
this has been lurking at the back of my head for quite some time now. 
There are actually a few uglies in the tracing code due to not having 
full-color transparency, and those keep nagging at me.

Post a reply to this message