[Bf-viewport] 16 Bit Float

[Troy Sobotka]

Greetings all.

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.

This would make the buffer implementation hugely useful for any painting
operations, and any future work on VSENextGen etc.

The only downside that I can see would be native 16 bit buffers would need
to have a secondary "original" format kicking around so an imager can
potentially change the colourspace as required.

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?

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?

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

With respect,
TJS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20160928/9ecdb8d3/attachment-0001.htm