[Bf-committers] Updating Colour Configurations

Wed Nov 11 13:23:51 CET 2015

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