|
|
|
|
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Function / pattern issues. New inbuilt f_dec_nbit3c, f_enc_nbit3c.
Date: 3 Feb 2021 17:44:30
Message: <601b274e$1@news.povray.org>
|
|
|
| |
| |
|
|
<---------------------- 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
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: Function / pattern issues. New inbuilt f_dec_nbit3c, f_enc_nbit3c.
Date: 4 Feb 2021 13:55:28
Message: <601c4320$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|