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

Post a reply to this message

Attachments:
Download 'f_dec_nbit3c_01.jpg' (248 KB) Download 'f_dec_nbit3c_03.jpg' (409 KB)

Preview of image 'f_dec_nbit3c_01.jpg'

Preview of image 'f_dec_nbit3c_03.jpg'