[Bf-viewport] 16 Bit Float

[Mike Erwin]

On Wed, Sep 28, 2016 at 12:54 AM, Troy Sobotka <troy.sobotka at gmail.com>
wrote:
>
> I spotted that there will be a new buffer type introduced with the
> viewport plans. This is exciting as well as long overdue. I am wondering if
> a discussion has happened to make this buffer useful for other areas?
>
> In particular, as Antony and I discussed countless times regarding some of
> the issues with paint, it would be ideal if the 16 bit buffer, upon load,
> is loaded and transformed *to reference*.
>
> That is, in an ideal world, once the buffer is allocated and the file
> loaded, that the colourspace is always assumed to be in the reference space
> chosen. If your reference is FoobarRGB, and you load an sRGB image, then
> the 16 bit float buffer would be transformed and stored as FoobarRGB. If an
> image has an imager flip its colourspace via the selection box, regenerate
> the 16 bit float buffer with the new transform input.
>

Is it enough for each image or buffer to *know* what color space its values
are using, without changing those values numerically? Transform to
reference when compositing into the display buffer (or output file).


> On an additional note, I have had more than a few folks ask me if the
> newer PBR system will be fully colour managed by default. My guess is that
> it will, but I am curious as to whether or not this was discussed in the
> sprint?
>

Not discussed in depth, but yes the idea is to have color managed IO, with
rendering / lighting / materials in linear HDR.


> Finally, given that there will be the 16 bit float buffer, I am curious as
> to the reasoning to keep the anachronistic 8 bit format around? It is
> *hugely* problematic in a managed system, not even beginning to discuss the
> horrible nightmare of alpha that we currently have as a result. Is it
> viable to simply promote all 8 bit assets to 16 bit float and avoid the
> ensuing nightmare?
>

8 bit color components are not for assets, but for UI elements & widgets
only. Anything to do with color picking or material preview we'll pay
closer attention to. The idea is that not every task uses real lighting &
colors (pre-material modeling for example).

Kudos to whoever tacked on the 30 bit display buffer as well. You deserve a
> cookie.
>

Thank you, it's delicious! High-end displays are one of my interests. True
HDR display output is too new for me to know much about it, but getting a
quality SDR signal out post tone mapping is something we can do fairly
early in 2.8 development.


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160929/a5c8011b/attachment.htm