POV-Ray : Newsgroups : povray.beta-test.binaries : Function / pattern issues. New inbuilt f_dec_nbit3c, f_enc_nbit3c. : Re: Function / pattern issues. New inbuilt f_dec_nbit3c, f_enc_nbit3c. Server Time
18 May 2024 02:11:45 EDT (-0400)
  Re: Function / pattern issues. New inbuilt f_dec_nbit3c, f_enc_nbit3c.  
From: William F Pokorny
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.