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 < [email protected]> 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 <[email protected]> > 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 < > > [email protected]> 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" <[email protected]> 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 < > >> > [email protected]> 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 < > [email protected] > >> > > >> > > wrote: > >> > > > On Nov 10, 2015 2:47 PM, "Brecht Van Lommel" < > >> > [email protected] > >> > > > > >> > > > 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 > >> > > > [email protected] > >> > > > http://lists.blender.org/mailman/listinfo/bf-committers > >> > > _______________________________________________ > >> > > Bf-committers mailing list > >> > > [email protected] > >> > > http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > >> > > >> > > >> > > >> > -- > >> > With best regards, Sergey Sharybin > >> > _______________________________________________ > >> > Bf-committers mailing list > >> > [email protected] > >> > http://lists.blender.org/mailman/listinfo/bf-committers > >> > > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > > > > > > > -- > > With best regards, Sergey Sharybin > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
