[Bf-committers] Updating Colour Configurations

[Brecht Van Lommel]

The way I imagined it working is to assume that any RGB value in the
shader evaluation, lights properties, etc, is all in the renderer
working space already, so besides image textures there's no
transformations of colors going into and out of the renderer. We'd
keep the requirement that the renderer working space is RGB like, so
the channels can be interpreted as RGB. So you'd only have the linear
space conversion in a handful of places like the sky texture and image
textures.

The main reason to have it customizable is that I think that if you
pick a linear space, you want to work with that same linear space
everywhere in Blender, or other software packages. Rendering in one
color space and compositing in another would have weird side effects
like out of gamut colors, render passes not adding up to the combined
result exactly, etc. But switching all of Blender to a specific wide
gamut RGB would break backwards compatibility quite badly, and would
not work for e.g. game designers that use Rec.709 RGB or studios that
adopt ACES RGB.

I'm not sure what the tedious workflow or spectrum rendering issues
would be. The changes to the kernel would be quite minimal I think, we
should not need to change shaders nodes, textures, lights, BSDFs
besides a few exceptions like the sky texture and blackbody.

On Wed, Nov 11, 2015 at 1:23 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> You're right about sky texture, but for blackbody and wavelength we can
> "bake" the transform into the approximation curves.
>
> Main question is -- is there really a benefit to support customizable
> kernel's linear space? What's the benefits comparing to use wider RGB
> space? IMO, custom linear space in kernel will only cause problems -- more
> tedious workflow in node trees, textures, lighting setup, impossibility to
> fake spectrum rendering, plus afair reasonable amount of BSDFs are
> evaluated against RGB.
>
> On Wed, Nov 11, 2015 at 4:40 PM, Brecht Van Lommel <
> brechtvanlommel at pandora.be> wrote:
>
>> If we want to make the working space for the renderer configurable,
>> then there are a couple of places where we need to do transformations
>> besides image textures. For example the sky texture has a hardcoded
>> XYZ to Rec.709 RGB conversion, so if we use a wider gamut RGB space
>> the 3x3 matrix used for that should be changed. The wavelength and
>> blackbody node also have such built-in assumptions. Those conversion
>> must happen inside the kernel I think.
>>
>> I'm not sure which other linear space conversion you had in mind. I
>> would think that you'd use a single linear color space for rendering,
>> compositing, .. and any other operations in linear space in Blender.
>> Linear space conversions would then happen mostly for file I/O and
>> display.
>>
>> For byte textures in general we do indeed need LUTs. Unless we convert
>> them outside the kernel, but then there's the extra memory usage since
>> you need to store the result as (half) float to avoid precision loss.
>>
>>
>> On Wed, Nov 11, 2015 at 10:54 AM, Sergey Sharybin <sergey.vfx at gmail.com>
>> wrote:
>> > Linear space conversion we can do outside of the kernel without loosing
>> > precision. Unless i'm missing something the only change in the kernel
>> would
>> > be sampling of byte textures. That would need to be changed to use LUT
>> > because you can't really linearize with 3x3 matrix.
>> >
>> > On Wed, Nov 11, 2015 at 2:49 PM, Brecht Van Lommel <
>> > brechtvanlommel at pandora.be> wrote:
>> >
>> >> Right, I agree a wider gamut RGB would be fine for rendering. I was
>> >> confused about the XYZ thing but Troy wasn't actually suggesting to
>> render
>> >> in that space. It's more of an implementation detail for how to specify
>> >> chromaticities and white point in the OCIO configuration and then make
>> them
>> >> available to Cycles and other places in Blender.
>> >>
>> >> Baked LUTs would work yeah, just for conversion between linear spaces a
>> 3x3
>> >> matrix is simpler.
>> >> On Nov 11, 2015 10:21, "Sergey Sharybin" <sergey.vfx at gmail.com> wrote:
>> >>
>> >> > For the majority of Blender it's already possible to use whatever
>> linear
>> >> > space you want. It should work rather fine in areas like compositor.
>> >> >
>> >> > For the rendering i don't know if it really makes sense to make core
>> >> > working in XYZ space. I had a WIP patch which witched Cycles to a
>> wider
>> >> > gamut RGB space which solved issues caused by color saturation. Some
>> >> other
>> >> > render engines aren't using XYZ either because difference between XYZ
>> and
>> >> > wider gamut RGB is quite negotiable. So using wider gamut internally
>> and
>> >> > converting to whatever-scene-linear is after rendering should work
>> rather
>> >> > fine i think.
>> >> >
>> >> > As for OCIO conversion on GPU -- it's possible to use same baking API
>> as
>> >> > for GLSL and then interpolate baked LUTs from the CUDA/OpenCL kernels.
>> >> >
>> >> >
>> >> >
>> >> > On Wed, Nov 11, 2015 at 7:42 AM, Brecht Van Lommel <
>> >> > brechtvanlommel at pandora.be> wrote:
>> >> >
>> >> > > After talking to Troy I now understand the idea better. So basically
>> >> > > we want the scene_linear color space (the working space for
>> rendering)
>> >> > > to be fully defined and configurable. Currently it is hardcoded to
>> >> > > Rec.709 RGB, but we want to support color spaces with a wider gamut
>> >> > > covering more colors of the visible spectrum. We can do that by
>> >> > > ensuring the OCIO configuration has an XYZ color space and a
>> >> > > transformation from the XYZ color space to the scene_linear color
>> >> > > space.
>> >> > >
>> >> > > Then for example if we do XYZ to scene linear RGB conversion in the
>> >> > > Cycles Sky texture, we use that OCIO transformation instead of the
>> >> > > hardcoded XYZ to Rec.709 RGB conversion that we have now.
>> >> > >
>> >> > > However, OCIO can't be called from the GPU, so we need to implement
>> >> > > that transformation ourselves in the Cycles kernel. Luckily, if the
>> >> > > scene_linear color space is indeed radiometrically linear, then the
>> >> > > transformation to/from XYZ must be a linear transformation, which is
>> >> > > just a 3x3 matrix. The columns of that matrix can be extracted from
>> >> > > OCIO by transforming the colors (1, 0, 0), (0, 1, 0), (0, 0, 1).
>> This
>> >> > > 3x3 matrix can be easily copied to and used on the GPU.
>> >> > >
>> >> > > On Wed, Nov 11, 2015 at 12:16 AM, Troy Sobotka <
>> troy.sobotka at gmail.com
>> >> >
>> >> > > wrote:
>> >> > > > On Nov 10, 2015 2:47 PM, "Brecht Van Lommel" <
>> >> > brechtvanlommel at pandora.be
>> >> > > >
>> >> > > > wrote:
>> >> > > >>
>> >> > > >> I doubt GPU rendering is a problem, but I have no idea what the
>> word
>> >> > > >> "role" means in this context and what "implementing an XYZ role"
>> >> > > >> means.
>> >> > > >
>> >> > > > A role is simply a known alias that software can hunt for via
>> OCIO.
>> >> So
>> >> > > for
>> >> > > > example, if you have to convert colour temperature via a Bradford
>> >> etc.
>> >> > > > transform and require the space's XYZ primaries and white point,
>> you
>> >> > > could
>> >> > > > request the “XYZ” role. It is provided for grabbing “Grading” or
>> “UI”
>> >> > > > transforms etc.
>> >> > > >
>> >> > > > With respect,
>> >> > > > TJS
>> >> > > > _______________________________________________
>> >> > > > Bf-committers mailing list
>> >> > > > Bf-committers at blender.org
>> >> > > > http://lists.blender.org/mailman/listinfo/bf-committers
>> >> > > _______________________________________________
>> >> > > Bf-committers mailing list
>> >> > > Bf-committers at blender.org
>> >> > > http://lists.blender.org/mailman/listinfo/bf-committers
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > With best regards, Sergey Sharybin
>> >> > _______________________________________________
>> >> > Bf-committers mailing list
>> >> > Bf-committers at blender.org
>> >> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >> >
>> >> _______________________________________________
>> >> Bf-committers mailing list
>> >> Bf-committers at blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> >>
>> >
>> >
>> >
>> > --
>> > With best regards, Sergey Sharybin
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> With best regards, Sergey Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers