On 07/10/2016 11:30 AM, William F Pokorny wrote:
> On 07/10/2016 08:37 AM, Le_Forgeron wrote:
...
> OK. If the optionality is what we are trying to indicate, I think we
> probably want something like :
>
> COLOR_VECTOR:
>       [rgb] float            | (promoted to 3 value vector)
>       [rg0] <2 Term Vector>  |
>       [rgb] <3_Term_Vector>  |
>       [rgbf] <4_Term_Vector> |
>       rgbt <4_Term_Vector>   |
>       [ rgbft ] <5_Term_Vector> |
>       srgb <3_Term_Vector>   |
>       srgbf <4_Term_Vector>  |
>       srgbt <4_Term_Vector>  |
>       srgbft <5_Term_Vector>
>
> Bill P.

Argh... Just popped into my head the line:

[rg0] <2 Term Vector>  |

is more like:

[rgb] <2 Term Vector>  | (blue is zero in this case)

there is of course no "rg0". :-)

Bill P.

Post a reply to this message

Am 10.07.2016 um 17:30 schrieb William F Pokorny:

> OK. If the optionality is what we are trying to indicate, I think we
> probably want something like :
> 
> COLOR_VECTOR:
>      [rgb] float            | (promoted to 3 value vector)
>      [rg0] <2 Term Vector>  |
>      [rgb] <3_Term_Vector>  |
>      [rgbf] <4_Term_Vector> |
>      rgbt <4_Term_Vector>   |
>      [ rgbft ] <5_Term_Vector> |
>      srgb <3_Term_Vector>   |
>      srgbf <4_Term_Vector>  |
>      srgbt <4_Term_Vector>  |
>      srgbft <5_Term_Vector>

Since floats and less-than-5-term vectors are automatically promoted to
5-term vectors this is not necessary. To the contrary, what you suggest
might be misinterpreted to imply that e.g. `rgbft <4_Term_Vector>` would
be invalid, when in fact it is perfectly legal.

Also, there is no `rg0` keyword, so that's plain nonsense right there.

Post a reply to this message

On 07/10/2016 11:50 AM, clipka wrote:
> Am 10.07.2016 um 17:30 schrieb William F Pokorny:
>
>> OK. If the optionality is what we are trying to indicate, I think we
>> probably want something like :
>>
>> COLOR_VECTOR:
>>       [rgb] float            | (promoted to 3 value vector)
>>       [rg0] <2 Term Vector>  |
>>       [rgb] <3_Term_Vector>  |
>>       [rgbf] <4_Term_Vector> |
>>       rgbt <4_Term_Vector>   |
>>       [ rgbft ] <5_Term_Vector> |
>>       srgb <3_Term_Vector>   |
>>       srgbf <4_Term_Vector>  |
>>       srgbt <4_Term_Vector>  |
>>       srgbft <5_Term_Vector>
>
> Since floats and less-than-5-term vectors are automatically promoted to
> 5-term vectors this is not necessary. To the contrary, what you suggest
> might be misinterpreted to imply that e.g. `rgbft <4_Term_Vector>` would
> be invalid, when in fact it is perfectly legal.
>
> Also, there is no `rg0` keyword, so that's plain nonsense right there.
>
(Indeed. I'm about half nonsensical in any given moment. ;-) See my own, 
earlier correction to rg0)

The block under discussion is in the section:

http://wiki.povray.org/content?title=Reference:Color_Expressions

where we describe how a user can specify color as in:

pigment { color .... }

In this context it seems to me we care not that a 5 term vector is 
otherwise treated by POV-Ray as a color vector by default, but whether 
we need to specify the rgb... whatever string in the color 
specification. In the latter context I think what I have written is what 
happens. All these are today valid ways to specify color:

color 1           // We get white
color <1,1>       // We get yellow
color <1,1,1>     // White
color <1,1,1,1>   // Clear by filter
color <1,1,1,1,1> // Again clear

Bill P.

Post a reply to this message

Le 10/07/2016 17:49, William F Pokorny a écrit :
> On 07/10/2016 11:30 AM, William F Pokorny wrote:
>> On 07/10/2016 08:37 AM, Le_Forgeron wrote:
> ...
>> OK. If the optionality is what we are trying to indicate, I think we
>> probably want something like :
>>
>> COLOR_VECTOR:
>>       [rgb] float            | (promoted to 3 value vector)
>>       [rg0] <2 Term Vector>  |
>>       [rgb] <3_Term_Vector>  |
>>       [rgbf] <4_Term_Vector> |
>>       rgbt <4_Term_Vector>   |
>>       [ rgbft ] <5_Term_Vector> |
>>       srgb <3_Term_Vector>   |
>>       srgbf <4_Term_Vector>  |
>>       srgbt <4_Term_Vector>  |
>>       srgbft <5_Term_Vector>
>>
>> Bill P.
> 
> Argh... Just popped into my head the line:
> 
> [rg0] <2 Term Vector>  |
> 
> is more like:
> 
> [rgb] <2 Term Vector>  | (blue is zero in this case)
> 
> there is of course no "rg0". :-)
> 
> Bill P.

IMHO, you are missing that, at another level, the missing terms are automatically
created from existing input when needed.

float get promoted to 3D, 2D get completed to 3D with 0 as the last term and so on
(including 2D expended to 4D and 5D when needed)... but some too-short expression can
give you a warning (such as "Suspicious expression after rgbf.")
On the same line, providing a 5D for a 4D (e.g. rgbf) will also give you a warning
(that's not a promotion/extension, rather a reduction).
Yet, it is valid syntax. (even if the 5th term get ignored).

On the same line, when "<N_Term_Vector>" is used, it can be any expression (including
+,-,* and /... and even some within ?: ternary operator ) which result in such values,
at the end.
You are going to have very hard to have a readable syntax if you want to list all
possible cases for just "rgb xxxxx"

Post a reply to this message

Am 10.07.2016 um 18:21 schrieb William F Pokorny:

> The block under discussion is in the section:
> 
> http://wiki.povray.org/content?title=Reference:Color_Expressions
> 
> where we describe how a user can specify color as in:
> 
> pigment { color .... }
> 
> In this context it seems to me we care not that a 5 term vector is
> otherwise treated by POV-Ray as a color vector by default, but whether
> we need to specify the rgb... whatever string in the color
> specification. In the latter context I think what I have written is what
> happens. All these are today valid ways to specify color:
> 
> color 1           // We get white
> color <1,1>       // We get yellow
> color <1,1,1>     // White
> color <1,1,1,1>   // Clear by filter
> color <1,1,1,1,1> // Again clear

If you look at it that way, you forget

  color rgb 1
  color rgb <1,1>
  color rgb <1,1,1>
  color rgbf 1
  color rgbf <1,1>
  color rgbf <1,1,1>
  color rgbf <1,1,1,1>
  color rgbt 1
  color rgbt <1,1>
  color rgbt <1,1,1>
  color rgbt <1,1,1,1>
  color rgbft 1
  color rgbft <1,1>
  color rgbft <1,1,1>
  color rgbft <1,1,1,1>
  color rgbft <1,1,1,1,1>
  color srgb 1
  color srgb <1,1>
  color srgb <1,1,1>
  color srgbf 1
  color srgbf <1,1>
  color srgbf <1,1,1>
  color srgbf <1,1,1,1>
  color srgbt 1
  color srgbt <1,1>
  color srgbt <1,1,1>
  color srgbt <1,1,1,1>
  color srgbft 1
  color srgbft <1,1>
  color srgbft <1,1,1>
  color srgbft <1,1,1,1>
  color srgbft <1,1,1,1,1>

Also, you forget

  color rgb <1,1,1,1>
  color rgb <1,1,1,1,1>
  color rgbf <1,1,1,1,1>
  color rgbt <1,1,1,1,1>
  color srgb <1,1,1,1>
  color srgb <1,1,1,1,1>
  color srgbf <1,1,1,1,1>
  color srgbt <1,1,1,1,1>

which are also accepted (even though they raise a warning).

You don't really want to list all these special cases individually in
the syntax box for COLOR (or at least I /hope/ you don't want to ;)).

As for the factoid that "a 5 term vector is otherwise treated by POV-Ray
as a color vector by default", this is technically wrong.

The truth is that `.x`, `.y`, `.z` ect., as well as `.red`, `.green",
`.blue` etc., are all allowed for both vectors and colours, and both
colours and vectors can be used interchangeably, so the difference
between the two is pretty obscure (which is a property of POV-Ray's SDL
that I have always detested).

As for the `rgbft` being optional in a colour statement, this also does
/not/ mean that 5-term vectors are treated as colours by default.
Instead, it means that if the parser /specifically/ expects a colour, an
arbitrary vector is also legal (and is the very mechanism by which
vectors can be used in place of colours).

Post a reply to this message

Am 10.07.2016 um 13:03 schrieb Le_Forgeron:
> Le 10/07/2016 12:41, clipka a écrit :
>> Am 10.07.2016 um 05:16 schrieb Bald Eagle:
>>> (curious - Was .hf eliminated, or was it never implemented?)
>>
>> In the 3.6 docs, it is only mentioned in the isosurface tutorial, where
>> it is labeled "experimental", and in the source code it is even labeled
>> as unofficial, for MegaPOV compatibility only.
>>
>> In fact, `.hf` is only available within functions; also, it is intended
>> to produce an "experimental feature" warning (but currently doesn't).
>>
> 
> The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")
> 
> Now, should it remains an experimental feature... I do not know.

The code is bogus (the constant 0.996093 in the formula is not only a
"magic" value, but most certainly wrong), so it sure as hell shouldn't
become canonical in its current form.

Post a reply to this message

On 07/10/2016 12:32 PM, Le_Forgeron wrote:
> Le 10/07/2016 17:49, William F Pokorny a écrit :
>> On 07/10/2016 11:30 AM, William F Pokorny wrote:
>>> On 07/10/2016 08:37 AM, Le_Forgeron wrote:
>> ...
>>> OK. If the optionality is what we are trying to indicate, I think we
>>> probably want something like :
>>>
>>> COLOR_VECTOR:
>>>        [rgb] float            | (promoted to 3 value vector)
>>>        [rg0] <2 Term Vector>  |
>>>        [rgb] <3_Term_Vector>  |
>>>        [rgbf] <4_Term_Vector> |
>>>        rgbt <4_Term_Vector>   |
>>>        [ rgbft ] <5_Term_Vector> |
>>>        srgb <3_Term_Vector>   |
>>>        srgbf <4_Term_Vector>  |
>>>        srgbt <4_Term_Vector>  |
>>>        srgbft <5_Term_Vector>
>>>
>>> Bill P.
>>
>> Argh... Just popped into my head the line:
>>
>> [rg0] <2 Term Vector>  |
>>
>> is more like:
>>
>> [rgb] <2 Term Vector>  | (blue is zero in this case)
>>
>> there is of course no "rg0". :-)
>>
>> Bill P.
>
> IMHO, you are missing that, at another level, the missing terms are automatically
created from existing input when needed.
>
> float get promoted to 3D, 2D get completed to 3D with 0 as the last term and so on
(including 2D expended to 4D and 5D when needed)... but some too-short expression can
give you a warning (such as "Suspicious expression after rgbf.")
> On the same line, providing a 5D for a 4D (e.g. rgbf) will also give you a warning
(that's not a promotion/extension, rather a reduction).
> Yet, it is valid syntax. (even if the 5th term get ignored).
>
> On the same line, when "<N_Term_Vector>" is used, it can be any expression
(including +,-,* and /... and even some within ?: ternary operator ) which result in
such values, at the end.
> You are going to have very hard to have a readable syntax if you want to list all
possible cases for just "rgb xxxxx"
>
(Christoph, I saw your response too, but will respond just here)

I think I generally understand the promotion and demotion going on when 
colors are expected and we have various floats or vectors as the 
starting point/right-hand-argument.

When I originally questioned the line:

[ rgbft ] <5_Term_Vector> |

it was because our saying rgbft was optional per the brackets in just 
the five term vector case did not make sense to me for a syntax 
specification.

That "...the missing terms are automatically created from existing input 
when needed" is the point.

The rgb string is also optional for a float and multiple vector 
specifications. Why is it we are not showing the user it is optional 
with brackets as in [rgb], but doing it for rgbft and the 5 term vector 
case?

It seems to me for a syntax specification for color vectors we should be 
completely truthful about whether the string is optional, or always 
vague, listing just the various ".rgb.." strings.

Bill P.

Post a reply to this message

Le 10/07/2016 19:43, clipka a écrit :
> Am 10.07.2016 um 13:03 schrieb Le_Forgeron:
>> Le 10/07/2016 12:41, clipka a écrit :
>>> Am 10.07.2016 um 05:16 schrieb Bald Eagle:
>>>> (curious - Was .hf eliminated, or was it never implemented?)
>>>
>>> In the 3.6 docs, it is only mentioned in the isosurface tutorial, where
>>> it is labeled "experimental", and in the source code it is even labeled
>>> as unofficial, for MegaPOV compatibility only.
>>>
>>> In fact, `.hf` is only available within functions; also, it is intended
>>> to produce an "experimental feature" warning (but currently doesn't).
>>>
>>
>> The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")
>>
>> Now, should it remains an experimental feature... I do not know.
> 
> The code is bogus (the constant 0.996093 in the formula is not only a
> "magic" value, but most certainly wrong), so it sure as hell shouldn't
> become canonical in its current form.
> 

IIRC, the heigth field interpretation of the color (when coming from indexed picture)
was & is also bogus (kept as such for backward compatibility)

(0.996093 looks like 255/256 : .99609375000000000000000000000000000000000000000000)

(See imageutil.cpp, image_height_at() function, due to history an 8 bit value bbbbbbbb
is promoted into 16 bits as bbbbbbbb00000000, making 65535 an unreachable value;
Notice that 0xFF00 / 0x10000 is also the same magic value)



Looking at the code of fncode.cpp,
the operations would resume to (r+g/255)*255/256

For r=g=1.0 (max normal value), it result in 1.0 (also the expected max value).
Excepted that the constant is truncated at the 7th significant decimal digit, which is
also the usual precision of double.
So, it is probably always bad, but nobody would be able to see it at that precision,
and because it is truncated to a lower multiplier, there is no overflow, and rounding
error might get you a 1.0 (not tested).

Post a reply to this message

Le 10/07/2016 20:50, Le_Forgeron a écrit :
>  which is also the usual precision of double.

My bad, 7th decimal digit is the precision of float, not double.

Post a reply to this message

Am 10.07.2016 um 20:50 schrieb Le_Forgeron:

>>>> In fact, `.hf` is only available within functions; also, it is intended
>>>> to produce an "experimental feature" warning (but currently doesn't).
>>>>
>>>
>>> The code which set the flag is in comment in fncode.cpp ("// TODO
FIXME		Experimental_Flag |= EF_ISOFN;")
>>>
>>> Now, should it remains an experimental feature... I do not know.
>>
>> The code is bogus (the constant 0.996093 in the formula is not only a
>> "magic" value, but most certainly wrong), so it sure as hell shouldn't
>> become canonical in its current form.
>>
> 
> IIRC, the heigth field interpretation of the color (when coming from indexed
picture)
> was & is also bogus (kept as such for backward compatibility)

Yup. Not directly related though.

> (0.996093 looks like 255/256 : .99609375000000000000000000000000000000000000000000)

That's what I think, too.

Post a reply to this message