-
This makes weston_color_transform object be able to express three-channel one-dimensional look-up table transformations. They are useful for applying EOTF and EOTF^-1 mapping, or, gamma curves. They will also be useful in optimizing a following 3D LUT tap distribution once support for 3D LUT is added. The code added here translates from the lut_3x1d fill_in() interface to a GL texture to be used with SHADER_COLOR_CURVE_LUT_3x1D for weston_surfaces. It demonstrates how renderer data is attached to weston_color_transform and cached. GL_OES_texture_float_linear is required to be able to use bilinear texture filtering with 32-bit floating-point textures, used for the LUT. As the size of the LUT depends on what implements it, lut_3x1d fill_in() interface is a callback to the color management component to ask for an arbitrary size. For GL-renderer this is not important as it can easily realize any LUT size, but when DRM-backend wants to offload the EOTF^-1 mapping to KMS (GAMMA_LUT), the LUT size comes from KMS. Nothing actually implements lut_3x1d fill_in() yet, that will come in a later patch. Signed-off-by:Pekka Paalanen <pekka.paalanen@collabora.com>
This makes weston_color_transform object be able to express three-channel one-dimensional look-up table transformations. They are useful for applying EOTF and EOTF^-1 mapping, or, gamma curves. They will also be useful in optimizing a following 3D LUT tap distribution once support for 3D LUT is added. The code added here translates from the lut_3x1d fill_in() interface to a GL texture to be used with SHADER_COLOR_CURVE_LUT_3x1D for weston_surfaces. It demonstrates how renderer data is attached to weston_color_transform and cached. GL_OES_texture_float_linear is required to be able to use bilinear texture filtering with 32-bit floating-point textures, used for the LUT. As the size of the LUT depends on what implements it, lut_3x1d fill_in() interface is a callback to the color management component to ask for an arbitrary size. For GL-renderer this is not important as it can easily realize any LUT size, but when DRM-backend wants to offload the EOTF^-1 mapping to KMS (GAMMA_LUT), the LUT size comes from KMS. Nothing actually implements lut_3x1d fill_in() yet, that will come in a later patch. Signed-off-by:
