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