[Bf-committers] Updating Colour Configurations
Brecht Van Lommel
brechtvanlommel at pandora.be
Wed Nov 11 12:40:20 CET 2015
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
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
>> > 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.
>> > > for
>> > > > example, if you have to convert colour temperature via a Bradford
>> > > > 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
> With best regards, Sergey Sharybin
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers