William F Pokorny <ano### [at] anonymousorg> wrote:
> <---------------------- References. Sixteen previous posts
>
> Function / pattern issues. Povr surface normal{} like dents.
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5f3fb137%241%40news.povray.org%3E/
>
> and
>
> Function / pattern issues. Povr inbuilt status 20 Dec 2020.
>
http://news.povray.org/povray.beta-test.binaries/thread/%3C5fdfc14f%40news.povray.org%3E/
>
>
> Elsewhere mentioned I mentioned replacing the .hf, never official,
> function block only and undocumented feature in v33.8. For the povr
> branch this comes as two new inbuilt functions called f_enc_nbit3c and
> f_dec_nbit3c. The 3 c standing for three channels (usually R,G,B) but
> the channels can be defined anyway one wants.
>
> I'd also mentioned supporting 2-17 bits of depth per channel, but on
> testing realized 1-17 was better because at 1, you can use f_dec_nbit3c
> alone as in inbuilt 3 value average pattern function. One which doesn't
> need to use the function { pattern/pigment } internal interface.
>
> 1-17 bits supports up to 51 bit single value depth (doubles come in at
> 52). The max in practice will probably be 16 bits per channel as this
> will fit in three 16 bit channel image formats of which there are a few.
> Using 17 bits requires moving to hdr or exr with float storage. It means
> on moving from 16 to 17 bits the storage per value increases from 48
> bits to 96 bits.
>
> Why the low bit depths? The depth effectively skews the G and B channels
> by powers of 2 and then powers of 2*2. This is useful as one can weight
> the contributions and then tune. Further, if the contributions are
> functions for example the full bit depth after the power of 2 shifts is
> still there when working with/or as is the values have been normalized.
> This last a concept the .hf implementation didn't support directly -
> users could make it work.
>
> I believe everything here is still doable in v3.8, but it is harder to
> code up.
>
> Not experimented too much as yet, but a couple test images attached.
> Both using a bit depth of 3, functions for each of the three channel
> inputs and marking the inputs normalized. I believe many interesting are
> possible.
>
> Credit to whomever wrote .hf. On some level, the approach in povr's two
> new inbuilt functions is the same. but one less hardwired to a
> particular task.
>
> Bill P.

It looks good. But I'm not sure what I'm looking at. Could this be used as a
kind of tangent space normal_map? If so, using images or functions only?

Post a reply to this message