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

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

On 2/4/21 8:14 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
> 
> 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?
> 

Thanks. :-) I'm with you on not being sure what the images are! Both are 
  isosurfaces - so shapes. They showed up while I was testing.

Neither encode or decode with these functions care where the data comes 
from or goes too. For the encode there is one value in and three out. 
The decode takes in three values and creates one.

The primary aim is to be able to store and recover high bit depth values 
- something at very nearly double accuracy. The working value range for 
these two functions is -1.0 to 1.0. Expect 0.0-1.0 is what will be most 
used.

Today - with v3.8 - we can easily(1) get to depths of 32 bits (.df3 
only), but not more. The best we can do with the usual image formats 
(and internal color representations) is floats (23 bits).

(1) - With functions in v3.7/3.8 you can almost always do whatever you 
want, but it's often not easy.

So! First and foremost, these two functions are a way to easily work 
with values having bit depths of up to 51 (3 channels, 17 bits each)(2). 
Fifty one is the most this method can support due having to use double 
for input and output.

(2) - In v3.8 Christoph made improvements so that several image formats 
support a bit depth per channel setting (up to 16). This in part the 
reason to support bit depths of 1 to 17 per channel with these two 
functions.

---
Once I got to playing with / testing the implementations, the 
possibilities opened up in a way I did not expect. These functions, by 
side effect, can do more than store high bit depth numbers - and with 
good performance. I was trying to suggest this with my initial post.

I don't know myself what all can be done. I struggled with what 
documentation I wrote for them. The 'extra' stuff is not nearly as easy 
to understand and use. Heck, I'm sure I don't see all the subtleties as yet!

Much of my aim with the povr branch - and especially with this 
pattern/function re-work push - is to knock down restrictions/obstacles 
and open up possibilities. To a degree, I don't know what the work means
in terms of actual day to day usefulness. ;-)

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 2/4/21 8:14 AM, Mr wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> >
> > 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?
> >
>
> Thanks. :-) I'm with you on not being sure what the images are! Both are
>   isosurfaces - so shapes. They showed up while I was testing.
>
> Neither encode or decode with these functions care where the data comes
> from or goes too. For the encode there is one value in and three out.
> The decode takes in three values and creates one.
>
> The primary aim is to be able to store and recover high bit depth values
> - something at very nearly double accuracy. The working value range for
> these two functions is -1.0 to 1.0. Expect 0.0-1.0 is what will be most
> used.
>
> Today - with v3.8 - we can easily(1) get to depths of 32 bits (.df3
> only), but not more. The best we can do with the usual image formats
> (and internal color representations) is floats (23 bits).
>
> (1) - With functions in v3.7/3.8 you can almost always do whatever you
> want, but it's often not easy.
>
> So! First and foremost, these two functions are a way to easily work
> with values having bit depths of up to 51 (3 channels, 17 bits each)(2).
> Fifty one is the most this method can support due having to use double
> for input and output.
>
> (2) - In v3.8 Christoph made improvements so that several image formats
> support a bit depth per channel setting (up to 16). This in part the
> reason to support bit depths of 1 to 17 per channel with these two
> functions.
>
> ---
> Once I got to playing with / testing the implementations, the
> possibilities opened up in a way I did not expect. These functions, by
> side effect, can do more than store high bit depth numbers - and with
> good performance. I was trying to suggest this with my initial post.
>
> I don't know myself what all can be done. I struggled with what
> documentation I wrote for them. The 'extra' stuff is not nearly as easy
> to understand and use. Heck, I'm sure I don't see all the subtleties as yet!
>
> Much of my aim with the povr branch - and especially with this
> pattern/function re-work push - is to knock down restrictions/obstacles
> and open up possibilities. To a degree, I don't know what the work means
> in terms of actual day to day usefulness. ;-)
>
> Bill P.

This sounds very exciting anyway !

Post a reply to this message