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