kannonier8/blender
1
0
Fork 0
forked from bartvdbraak/blender
Code Pull Requests Activity
265d97556a
blender/intern/opencolorio/ocio_impl.cc

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

786 lines
21 KiB
C++
Raw Normal View History

Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2012 Blender Foundation.
* All rights reserved.
*/
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
#include <cassert>
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
#include <iostream>
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
#include <math.h>
Implement GPU-side display transform for clip editor Implemented using GLSL API from OpenColorIO library and some general functions were added to it's c-api: - OCIO_setupGLSLDraw prepares OpenGL context for GPU-based transformation for a giver processor. This function compiles and links shader, sets up it's argument. After this transformation would be applied on an image displaying as a 2D texture. So, glaDrawPixelsTex called after OCIO_setupGLSLDraw will do a proper color space transform. - OCIO_finishGLSLDraw restores OpenGL context after all color-managed display is over. - OCIO_freeOGLState frees allocated state structure used for cacheing some GLSL-related stuff. There're some utility functions in IMB_colormanagent which are basically proxies to lower level OCIO functions but which could be used from any place in blender. Chacheing of movie clip frame on GPU is also removed now, and either glaDrawPixelsTex or glaDrawPixelsAuto are used for display now. This is so no code duplication happens now and no large textures are lurking around in GPU memory. Known issues: - Texture buffer and GLSL are no longer checking for video card capabilities, possibly could lead to some artifacts on crappy drivers/cards. - Only float buffers are displaying using GLSL, byte buffers will still use fallback display method. This is to be addressed later. - If RGB curves are used as a part of display transform, GLSL display will also be disabled. This is also thing to be solved later. Additional changes: - glaDrawPixelsTexScaled will now use RGBA16F as an internal format of storing textures when it's used to draw float buffer. This is needed so LUT are applied without precision loss.
2013-03-29 16:02:27 +00:00
#include <sstream>
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
#include <string.h>
OCIO: Disable the warnings related on C4251 Those warnings are trigerred by stl classes in OCIO's public interface. To quote MSDN: "C4251 can be ignored if you are deriving from a type in the Standard C++ Library" This is the only instance where those warnings hunts us, so for now we can keep it all local in intern/opencolorio but this might be changed in the future.
2016-02-20 08:45:01 +00:00
#ifdef _MSC_VER
# pragma warning(push)
# pragma warning(disable : 4251 4275)
#endif
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
#include <OpenColorIO/OpenColorIO.h>
OCIO: Disable the warnings related on C4251 Those warnings are trigerred by stl classes in OCIO's public interface. To quote MSDN: "C4251 can be ignored if you are deriving from a type in the Standard C++ Library" This is the only instance where those warnings hunts us, so for now we can keep it all local in intern/opencolorio but this might be changed in the future.
2016-02-20 08:45:01 +00:00
#ifdef _MSC_VER
# pragma warning(pop)
#endif
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
using namespace OCIO_NAMESPACE;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
#include "MEM_guardedalloc.h"
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
#include "BLI_math.h"
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
#include "BLI_math_color.h"
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
#include "BLI_math_matrix.h"
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
Color Management: fallback to stub ocio implementation in cases when ocio configuration file failed to load This solves issues with infinite NULL-checks to prevent crashes in such situations. Currently only happens if there's no configuration file at all, but could be tweaked further to fallback if this file isn't usable by blender.
2012-10-04 13:39:08 +00:00
#include "ocio_impl.h"
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
Color Management: restore abort() in cases of error and WITH_ASSERT_ABORT enabled
2012-09-26 13:21:10 +00:00
#if !defined(WITH_ASSERT_ABORT)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
# define OCIO_abort()
#else
# include <stdlib.h>
# define OCIO_abort() abort()
#endif
#if defined(_MSC_VER)
# define __func__ __FUNCTION__
#endif
static void OCIO_reportError(const char *err)
{
std::cerr << "OpenColorIO Error: " << err << std::endl;
Color Management: restore abort() in cases of error and WITH_ASSERT_ABORT enabled
2012-09-26 13:21:10 +00:00
OCIO_abort();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
static void OCIO_reportException(Exception &exception)
{
OCIO_reportError(exception.what());
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
OCIO_ConstConfigRcPtr *OCIOImpl::getCurrentConfig(void)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
ConstConfigRcPtr *config = OBJECT_GUARDED_NEW(ConstConfigRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
try {
*config = GetCurrentConfig();
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
if (*config)
return (OCIO_ConstConfigRcPtr *)config;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE(config, ConstConfigRcPtr);
Color management: fix crashes and memory leaks when using custom OCIO configuration Also fix some missing color spaces when loading some OCIO configurations, by falling back to scene linear if role is not found. There can still be some errors in the console, need to check this further. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
2012-09-18 19:20:26 +00:00
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
void OCIOImpl::setCurrentConfig(const OCIO_ConstConfigRcPtr *config)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
SetCurrentConfig(*(ConstConfigRcPtr *)config);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
OCIO_ConstConfigRcPtr *OCIOImpl::configCreateFromEnv(void)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
ConstConfigRcPtr *config = OBJECT_GUARDED_NEW(ConstConfigRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
try {
*config = Config::CreateFromEnv();
if (*config)
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (OCIO_ConstConfigRcPtr *)config;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE(config, ConstConfigRcPtr);
Color management: fix crashes and memory leaks when using custom OCIO configuration Also fix some missing color spaces when loading some OCIO configurations, by falling back to scene linear if role is not found. There can still be some errors in the console, need to check this further. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
2012-09-18 19:20:26 +00:00
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
OCIO_ConstConfigRcPtr *OCIOImpl::configCreateFromFile(const char *filename)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
ConstConfigRcPtr *config = OBJECT_GUARDED_NEW(ConstConfigRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
try {
Revert "Fix T47869: OpenColorIO Error with unicode path to config file under Windows" White the config itself could be loaded this way, lookup tables can not. Additionally, that's not really clear how to solve the issue with search path which is multi-byte only in the API. Reverting for further investigation. This reverts commit ab4307aa0868f2d8389cc0dd500eff38909b08f1.
2016-03-23 18:25:29 +00:00
*config = Config::CreateFromFile(filename);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
if (*config)
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (OCIO_ConstConfigRcPtr *)config;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE(config, ConstConfigRcPtr);
Color management: fix crashes and memory leaks when using custom OCIO configuration Also fix some missing color spaces when loading some OCIO configurations, by falling back to scene linear if role is not found. There can still be some errors in the console, need to check this further. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
2012-09-18 19:20:26 +00:00
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
void OCIOImpl::configRelease(OCIO_ConstConfigRcPtr *config)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE((ConstConfigRcPtr *)config, ConstConfigRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
int OCIOImpl::configGetNumColorSpaces(OCIO_ConstConfigRcPtr *config)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getNumColorSpaces();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return 0;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::configGetColorSpaceNameByIndex(OCIO_ConstConfigRcPtr *config, int index)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getColorSpaceNameByIndex(index);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
OCIO_ConstColorSpaceRcPtr *OCIOImpl::configGetColorSpace(OCIO_ConstConfigRcPtr *config,
const char *name)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
ConstColorSpaceRcPtr *cs = OBJECT_GUARDED_NEW(ConstColorSpaceRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
*cs = (*(ConstConfigRcPtr *)config)->getColorSpace(name);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
if (*cs)
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (OCIO_ConstColorSpaceRcPtr *)cs;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE(cs, ConstColorSpaceRcPtr);
Color management: fix crashes and memory leaks when using custom OCIO configuration Also fix some missing color spaces when loading some OCIO configurations, by falling back to scene linear if role is not found. There can still be some errors in the console, need to check this further. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
2012-09-18 19:20:26 +00:00
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
int OCIOImpl::configGetIndexForColorSpace(OCIO_ConstConfigRcPtr *config, const char *name)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getIndexForColorSpace(name);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return -1;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::configGetDefaultDisplay(OCIO_ConstConfigRcPtr *config)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getDefaultDisplay();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
int OCIOImpl::configGetNumDisplays(OCIO_ConstConfigRcPtr *config)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getNumDisplays();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return 0;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::configGetDisplay(OCIO_ConstConfigRcPtr *config, int index)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getDisplay(index);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::configGetDefaultView(OCIO_ConstConfigRcPtr *config, const char *display)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getDefaultView(display);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
int OCIOImpl::configGetNumViews(OCIO_ConstConfigRcPtr *config, const char *display)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getNumViews(display);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return 0;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::configGetView(OCIO_ConstConfigRcPtr *config, const char *display, int index)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstConfigRcPtr *)config)->getView(display, index);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::configGetDisplayColorSpaceName(OCIO_ConstConfigRcPtr *config,
const char *display,
const char *view)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
return (*(ConstConfigRcPtr *)config)->getDisplayViewColorSpaceName(display, view);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Part 1 of D1082 by Troy Sobotka, add API in OCIO for luminance calculation.
2015-03-17 13:15:05 +00:00
void OCIOImpl::configGetDefaultLumaCoefs(OCIO_ConstConfigRcPtr *config, float *rgb)
{
try {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
double rgb_double[3];
(*(ConstConfigRcPtr *)config)->getDefaultLumaCoefs(rgb_double);
rgb[0] = rgb_double[0];
rgb[1] = rgb_double[1];
rgb[2] = rgb_double[2];
Part 1 of D1082 by Troy Sobotka, add API in OCIO for luminance calculation.
2015-03-17 13:15:05 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
static bool to_scene_linear_matrix(ConstConfigRcPtr &config,
const char *colorspace,
float to_scene_linear[3][3])
{
ConstProcessorRcPtr processor;
try {
processor = config->getProcessor(colorspace, ROLE_SCENE_LINEAR);
}
catch (Exception &exception) {
OCIO_reportException(exception);
return false;
}
if (!processor) {
return false;
}
ConstCPUProcessorRcPtr cpu_processor = processor->getDefaultCPUProcessor();
if (!cpu_processor) {
return false;
}
unit_m3(to_scene_linear);
cpu_processor->applyRGB(to_scene_linear[0]);
cpu_processor->applyRGB(to_scene_linear[1]);
cpu_processor->applyRGB(to_scene_linear[2]);
return true;
}
Color management: add OCIO aware utility functions for transform to/from XYZ.
2018-10-12 14:42:34 +00:00
void OCIOImpl::configGetXYZtoRGB(OCIO_ConstConfigRcPtr *config_, float xyz_to_rgb[3][3])
{
ConstConfigRcPtr config = (*(ConstConfigRcPtr *)config_);
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 04:17:24 +00:00
Fix wrong white point of Linear ACES in config reading and the bundled config The Blender/Cycles XYZ color space has a D65 white point instead of E, and this was not correctly accounted for both in the OpenColor config reading code and the bundled config. This meant that since the OpenColorIO v2 upgrade, the Linear ACES color space was not working correctly, and other OpenColorIO configs defining aces_interchange were not interpreted correctly.
2021-03-10 15:38:26 +00:00
/* Default to ITU-BT.709 in case no appropriate transform found.
* Note XYZ is defined here as having a D65 white point. */
Color management: add OCIO aware utility functions for transform to/from XYZ.
2018-10-12 14:42:34 +00:00
memcpy(xyz_to_rgb, OCIO_XYZ_TO_LINEAR_SRGB, sizeof(OCIO_XYZ_TO_LINEAR_SRGB));
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 04:17:24 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Get from OpenColorO config if it has the required roles. */
if (!config->hasRole(ROLE_SCENE_LINEAR)) {
return;
}
if (config->hasRole("aces_interchange")) {
/* Standard OpenColorIO role, defined as ACES2065-1. */
Fix wrong white point of Linear ACES in config reading and the bundled config The Blender/Cycles XYZ color space has a D65 white point instead of E, and this was not correctly accounted for both in the OpenColor config reading code and the bundled config. This meant that since the OpenColorIO v2 upgrade, the Linear ACES color space was not working correctly, and other OpenColorIO configs defining aces_interchange were not interpreted correctly.
2021-03-10 15:38:26 +00:00
const float xyz_E_to_aces[3][3] = {{1.0498110175f, -0.4959030231f, 0.0f},
{0.0f, 1.3733130458f, 0.0f},
{-0.0000974845f, 0.0982400361f, 0.9912520182f}};
const float xyz_D65_to_E[3][3] = {
{1.0521111f, 0.0f, 0.0f}, {0.0f, 1.0f, 0.0f}, {0.0f, 0.0f, 0.9184170f}};
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
float aces_to_rgb[3][3];
if (to_scene_linear_matrix(config, "aces_interchange", aces_to_rgb)) {
Fix wrong white point of Linear ACES in config reading and the bundled config The Blender/Cycles XYZ color space has a D65 white point instead of E, and this was not correctly accounted for both in the OpenColor config reading code and the bundled config. This meant that since the OpenColorIO v2 upgrade, the Linear ACES color space was not working correctly, and other OpenColorIO configs defining aces_interchange were not interpreted correctly.
2021-03-10 15:38:26 +00:00
mul_m3_series(xyz_to_rgb, aces_to_rgb, xyz_E_to_aces, xyz_D65_to_E);
Color management: add OCIO aware utility functions for transform to/from XYZ.
2018-10-12 14:42:34 +00:00
}
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
else if (config->hasRole("XYZ")) {
/* Custom role used before the standard existed. */
to_scene_linear_matrix(config, "XYZ", xyz_to_rgb);
}
Color management: add OCIO aware utility functions for transform to/from XYZ.
2018-10-12 14:42:34 +00:00
}
Film response curves implemented as a looks This commit implement's OCIO's Looks idea which is about applying some color correction on the buffer before it get's affected by a display transform. This is mainly used to modify images in an artistics way. Currently we've got looks generated from film response curves for all sorts of cameras. Patch by both of me and Brecht.
2013-09-09 09:48:26 +00:00
int OCIOImpl::configGetNumLooks(OCIO_ConstConfigRcPtr *config)
{
try {
return (*(ConstConfigRcPtr *)config)->getNumLooks();
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return 0;
}
const char *OCIOImpl::configGetLookNameByIndex(OCIO_ConstConfigRcPtr *config, int index)
{
try {
return (*(ConstConfigRcPtr *)config)->getLookNameByIndex(index);
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
OCIO_ConstLookRcPtr *OCIOImpl::configGetLook(OCIO_ConstConfigRcPtr *config, const char *name)
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
ConstLookRcPtr *look = OBJECT_GUARDED_NEW(ConstLookRcPtr);
Film response curves implemented as a looks This commit implement's OCIO's Looks idea which is about applying some color correction on the buffer before it get's affected by a display transform. This is mainly used to modify images in an artistics way. Currently we've got looks generated from film response curves for all sorts of cameras. Patch by both of me and Brecht.
2013-09-09 09:48:26 +00:00
try {
*look = (*(ConstConfigRcPtr *)config)->getLook(name);
if (*look)
return (OCIO_ConstLookRcPtr *)look;
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE(look, ConstLookRcPtr);
Film response curves implemented as a looks This commit implement's OCIO's Looks idea which is about applying some color correction on the buffer before it get's affected by a display transform. This is mainly used to modify images in an artistics way. Currently we've got looks generated from film response curves for all sorts of cameras. Patch by both of me and Brecht.
2013-09-09 09:48:26 +00:00
return NULL;
}
const char *OCIOImpl::lookGetProcessSpace(OCIO_ConstLookRcPtr *look)
{
return (*(ConstLookRcPtr *)look)->getProcessSpace();
}
void OCIOImpl::lookRelease(OCIO_ConstLookRcPtr *look)
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE((ConstLookRcPtr *)look, ConstLookRcPtr);
Film response curves implemented as a looks This commit implement's OCIO's Looks idea which is about applying some color correction on the buffer before it get's affected by a display transform. This is mainly used to modify images in an artistics way. Currently we've got looks generated from film response curves for all sorts of cameras. Patch by both of me and Brecht.
2013-09-09 09:48:26 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
int OCIOImpl::colorSpaceIsInvertible(OCIO_ConstColorSpaceRcPtr *cs_)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
ConstColorSpaceRcPtr *cs = (ConstColorSpaceRcPtr *)cs_;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
const char *family = (*cs)->getFamily();
if (!strcmp(family, "rrt") || !strcmp(family, "display")) {
Cleanup: comments (long lines) in various intern/ libs
2019-05-01 10:50:02 +00:00
/* assume display and rrt transformations are not invertible in fact some of them could be,
* but it doesn't make much sense to allow use them as invertible. */
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return false;
}
if ((*cs)->isData()) {
/* data color spaces don't have transformation at all */
return true;
}
if ((*cs)->getTransform(COLORSPACE_DIR_TO_REFERENCE)) {
Cleanup: comments (long lines) in various intern/ libs
2019-05-01 10:50:02 +00:00
/* if there's defined transform to reference space,
* color space could be converted to scene linear. */
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return true;
}
return true;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
int OCIOImpl::colorSpaceIsData(OCIO_ConstColorSpaceRcPtr *cs)
Color Management: don't apply display transform on Non-Color images Also don't color manage data buffers in texture painting. Makes it possible to view heights and normal maps in proper space and also paint on them without applying extra transformation.
2012-09-19 15:01:36 +00:00
{
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstColorSpaceRcPtr *)cs)->isData();
Color Management: don't apply display transform on Non-Color images Also don't color manage data buffers in texture painting. Makes it possible to view heights and normal maps in proper space and also paint on them without applying extra transformation.
2012-09-19 15:01:36 +00:00
}
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
static float compare_floats(float a, float b, float abs_diff, int ulp_diff)
{
/* Returns true if the absolute difference is smaller than abs_diff (for numbers near zero)
* or their relative difference is less than ulp_diff ULPs. Based on:
* https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ */
if (fabsf(a - b) < abs_diff) {
return true;
}
if ((a < 0.0f) != (b < 0.0f)) {
return false;
}
return (abs((*(int *)&a) - (*(int *)&b)) < ulp_diff);
}
void OCIOImpl::colorSpaceIsBuiltin(OCIO_ConstConfigRcPtr *config_,
OCIO_ConstColorSpaceRcPtr *cs_,
bool &is_scene_linear,
bool &is_srgb)
{
ConstConfigRcPtr *config = (ConstConfigRcPtr *)config_;
ConstColorSpaceRcPtr *cs = (ConstColorSpaceRcPtr *)cs_;
ConstProcessorRcPtr processor;
try {
processor = (*config)->getProcessor((*cs)->getName(), "scene_linear");
}
bf_intern_opencolorio: Fix unused variable build warning with MSVC.
2019-05-25 19:04:24 +00:00
catch (Exception &) {
Cycles/Eevee: unified and improved texture image color space handling Cycles now uses the color space on the image datablock, and uses OpenColorIO to convert to scene linear as needed. Byte images do not take extra memory, they are compressed in scene linear + sRGB transfer function which in common cases is a no-op. Eevee and workbench were changed to work similar. Float images are stored as scene linear. Byte images are compressed as scene linear + sRGB and stored in a GL_SRGB8_ALPHA8 texture. From the GLSL shader side this means they are read as scene linear, simplifying the code and taking advantage of hardware support. Further, OpenGL image textures are now all stored with premultiplied alpha. Eevee texture sampling looks a little different now because interpolation happens premultiplied and in scene linear space. Overlays and grease pencil work in sRGB space so those now have an extra conversion to sRGB after reading from image textures. This is not particularly elegant but as long as engines use different conventions, one or the other needs to do conversion. This change breaks compatibility for cases where multiple image texture nodes were using the same image with different color space node settings. However it gives more predictable behavior for baking and texture painting if save, load and image editing operations have a single color space to handle. Differential Revision: https://developer.blender.org/D4807
2019-04-23 11:56:30 +00:00
/* Silently ignore if no conversion possible, then it's not scene linear or sRGB. */
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
is_scene_linear = false;
is_srgb = false;
return;
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
ConstCPUProcessorRcPtr cpu_processor = processor->getDefaultCPUProcessor();
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
is_scene_linear = true;
is_srgb = true;
for (int i = 0; i < 256; i++) {
float v = i / 255.0f;
float cR[3] = {v, 0, 0};
float cG[3] = {0, v, 0};
float cB[3] = {0, 0, v};
float cW[3] = {v, v, v};
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
cpu_processor->applyRGB(cR);
cpu_processor->applyRGB(cG);
cpu_processor->applyRGB(cB);
cpu_processor->applyRGB(cW);
Color management: add functions to detect scene linear and sRGB color spaces Same as the ones in Cycles, but intended for GPU textures.
2019-05-05 11:14:37 +00:00
/* Make sure that there is no channel crosstalk. */
if (fabsf(cR[1]) > 1e-5f || fabsf(cR[2]) > 1e-5f || fabsf(cG[0]) > 1e-5f ||
fabsf(cG[2]) > 1e-5f || fabsf(cB[0]) > 1e-5f || fabsf(cB[1]) > 1e-5f) {
is_scene_linear = false;
is_srgb = false;
break;
}
/* Make sure that the three primaries combine linearly. */
if (!compare_floats(cR[0], cW[0], 1e-6f, 64) || !compare_floats(cG[1], cW[1], 1e-6f, 64) ||
!compare_floats(cB[2], cW[2], 1e-6f, 64)) {
is_scene_linear = false;
is_srgb = false;
break;
}
/* Make sure that the three channels behave identically. */
if (!compare_floats(cW[0], cW[1], 1e-6f, 64) || !compare_floats(cW[1], cW[2], 1e-6f, 64)) {
is_scene_linear = false;
is_srgb = false;
break;
}
float out_v = (cW[0] + cW[1] + cW[2]) * (1.0f / 3.0f);
if (!compare_floats(v, out_v, 1e-6f, 64)) {
is_scene_linear = false;
}
if (!compare_floats(srgb_to_linearrgb(v), out_v, 1e-6f, 64)) {
is_srgb = false;
}
}
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
void OCIOImpl::colorSpaceRelease(OCIO_ConstColorSpaceRcPtr *cs)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE((ConstColorSpaceRcPtr *)cs, ConstColorSpaceRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
OCIO_ConstProcessorRcPtr *OCIOImpl::configGetProcessorWithNames(OCIO_ConstConfigRcPtr *config,
const char *srcName,
const char *dstName)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
ConstProcessorRcPtr *processor = OBJECT_GUARDED_NEW(ConstProcessorRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
try {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
*processor = (*(ConstConfigRcPtr *)config)->getProcessor(srcName, dstName);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
if (*processor)
return (OCIO_ConstProcessorRcPtr *)processor;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
OBJECT_GUARDED_DELETE(processor, ConstProcessorRcPtr);
Color management: fix crashes and memory leaks when using custom OCIO configuration Also fix some missing color spaces when loading some OCIO configurations, by falling back to scene linear if role is not found. There can still be some errors in the console, need to check this further. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
2012-09-18 19:20:26 +00:00
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
return 0;
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::processorRelease(OCIO_ConstProcessorRcPtr *processor)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
OBJECT_GUARDED_DELETE(processor, ConstProcessorRcPtr);
}
Color management: fix crashes and memory leaks when using custom OCIO configuration Also fix some missing color spaces when loading some OCIO configurations, by falling back to scene linear if role is not found. There can still be some errors in the console, need to check this further. http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management#OpenColorIO_Configuration
2012-09-18 19:20:26 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
OCIO_ConstCPUProcessorRcPtr *OCIOImpl::processorGetCPUProcessor(
OCIO_ConstProcessorRcPtr *processor)
{
ConstCPUProcessorRcPtr *cpu_processor = OBJECT_GUARDED_NEW(ConstCPUProcessorRcPtr);
*cpu_processor = (*(ConstProcessorRcPtr *)processor)->getDefaultCPUProcessor();
return (OCIO_ConstCPUProcessorRcPtr *)cpu_processor;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::cpuProcessorApply(OCIO_ConstCPUProcessorRcPtr *cpu_processor,
OCIO_PackedImageDesc *img)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
(*(ConstCPUProcessorRcPtr *)cpu_processor)->apply(*(PackedImageDesc *)img);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::cpuProcessorApply_predivide(OCIO_ConstCPUProcessorRcPtr *cpu_processor,
OCIO_PackedImageDesc *img_)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
PackedImageDesc *img = (PackedImageDesc *)img_;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
int channels = img->getNumChannels();
if (channels == 4) {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
assert(img->isFloat());
float *pixels = (float *)img->getData();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
int width = img->getWidth();
int height = img->getHeight();
for (int y = 0; y < height; y++) {
for (int x = 0; x < width; x++) {
float *pixel = pixels + 4 * (y * width + x);
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
cpuProcessorApplyRGBA_predivide(cpu_processor, pixel);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
}
}
else {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
(*(ConstCPUProcessorRcPtr *)cpu_processor)->apply(*img);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::cpuProcessorApplyRGB(OCIO_ConstCPUProcessorRcPtr *cpu_processor, float *pixel)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
(*(ConstCPUProcessorRcPtr *)cpu_processor)->applyRGB(pixel);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::cpuProcessorApplyRGBA(OCIO_ConstCPUProcessorRcPtr *cpu_processor, float *pixel)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
(*(ConstCPUProcessorRcPtr *)cpu_processor)->applyRGBA(pixel);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::cpuProcessorApplyRGBA_predivide(OCIO_ConstCPUProcessorRcPtr *cpu_processor,
float *pixel)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
if (pixel[3] == 1.0f || pixel[3] == 0.0f) {
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
(*(ConstCPUProcessorRcPtr *)cpu_processor)->applyRGBA(pixel);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
else {
float alpha, inv_alpha;
alpha = pixel[3];
inv_alpha = 1.0f / alpha;
pixel[0] *= inv_alpha;
pixel[1] *= inv_alpha;
pixel[2] *= inv_alpha;
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
(*(ConstCPUProcessorRcPtr *)cpu_processor)->applyRGBA(pixel);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
pixel[0] *= alpha;
pixel[1] *= alpha;
pixel[2] *= alpha;
}
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
void OCIOImpl::cpuProcessorRelease(OCIO_ConstCPUProcessorRcPtr *cpu_processor)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
OBJECT_GUARDED_DELETE(cpu_processor, ConstCPUProcessorRcPtr);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::colorSpaceGetName(OCIO_ConstColorSpaceRcPtr *cs)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstColorSpaceRcPtr *)cs)->getName();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::colorSpaceGetDescription(OCIO_ConstColorSpaceRcPtr *cs)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstColorSpaceRcPtr *)cs)->getDescription();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
const char *OCIOImpl::colorSpaceGetFamily(OCIO_ConstColorSpaceRcPtr *cs)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (*(ConstColorSpaceRcPtr *)cs)->getFamily();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
OCIO_ConstProcessorRcPtr *OCIOImpl::createDisplayProcessor(OCIO_ConstConfigRcPtr *config_,
const char *input,
const char *view,
const char *display,
const char *look,
const float scale,
const float exponent)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
ConstConfigRcPtr config = *(ConstConfigRcPtr *)config_;
GroupTransformRcPtr group = GroupTransform::Create();
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Exposure. */
if (scale != 1.0f) {
/* Always apply exposure in scene linear. */
ColorSpaceTransformRcPtr ct = ColorSpaceTransform::Create();
ct->setSrc(input);
ct->setDst(ROLE_SCENE_LINEAR);
group->appendTransform(ct);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Make further transforms aware of the color space change. */
input = ROLE_SCENE_LINEAR;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Apply scale. */
MatrixTransformRcPtr mt = MatrixTransform::Create();
const double matrix[16] = {
scale, 0.0, 0.0, 0.0, 0.0, scale, 0.0, 0.0, 0.0, 0.0, scale, 0.0, 0.0, 0.0, 0.0, 1.0};
mt->setMatrix(matrix);
group->appendTransform(mt);
}
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Add look transform. */
Fix T85671: color management crash with Medium Contrast look
2021-02-16 21:37:27 +00:00
bool use_look = (look != nullptr && look[0] != 0);
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
if (use_look) {
const char *look_output = LookTransform::GetLooksResultColorSpace(
config, config->getCurrentContext(), look);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
Fix T85671: color management crash with Medium Contrast look
2021-02-16 21:37:27 +00:00
if (look_output != nullptr && look_output[0] != 0) {
LookTransformRcPtr lt = LookTransform::Create();
lt->setSrc(input);
lt->setDst(look_output);
lt->setLooks(look);
group->appendTransform(lt);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
Fix T85671: color management crash with Medium Contrast look
2021-02-16 21:37:27 +00:00
/* Make further transforms aware of the color space change. */
input = look_output;
}
else {
/* For empty looks, no output color space is returned. */
use_look = false;
}
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
}
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Add view and display transform. */
DisplayViewTransformRcPtr dvt = DisplayViewTransform::Create();
dvt->setSrc(input);
dvt->setLooksBypass(use_look);
dvt->setView(view);
dvt->setDisplay(display);
group->appendTransform(dvt);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Gamma. */
if (exponent != 1.0f) {
ExponentTransformRcPtr et = ExponentTransform::Create();
const double value[4] = {exponent, exponent, exponent, 1.0};
et->setValue(value);
group->appendTransform(et);
}
Film response curves implemented as a looks This commit implement's OCIO's Looks idea which is about applying some color correction on the buffer before it get's affected by a display transform. This is mainly used to modify images in an artistics way. Currently we've got looks generated from film response curves for all sorts of cameras. Patch by both of me and Brecht.
2013-09-09 09:48:26 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
/* Create processor from transform. This is the moment were OCIO validates
* the entire transform, no need to check for the validity of inputs above. */
ConstProcessorRcPtr *p = OBJECT_GUARDED_NEW(ConstProcessorRcPtr);
Film response curves implemented as a looks This commit implement's OCIO's Looks idea which is about applying some color correction on the buffer before it get's affected by a display transform. This is mainly used to modify images in an artistics way. Currently we've got looks generated from film response curves for all sorts of cameras. Patch by both of me and Brecht.
2013-09-09 09:48:26 +00:00
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
try {
*p = config->getProcessor(group);
if (*p)
return (OCIO_ConstProcessorRcPtr *)p;
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
OBJECT_GUARDED_DELETE(p, ConstProcessorRcPtr);
return NULL;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
OCIO_PackedImageDesc *OCIOImpl::createOCIO_PackedImageDesc(float *data,
long width,
long height,
long numChannels,
Style cleanup in OCIO area Also fixed typo in function name.
2013-01-08 20:55:07 +00:00
long chanStrideBytes,
long xStrideBytes,
long yStrideBytes)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
try {
void *mem = MEM_mallocN(sizeof(PackedImageDesc), __func__);
OpenColorIO: upgrade to version 2.0.0 Ref T84819 Build System ============ This is an API breaking new version, and the updated code only builds with OpenColorIO 2.0 and later. Adding backwards compatibility was too complicated. * Tinyxml was replaced with Expat, adding a new dependency. * Yaml-cpp is now built as a dependency on Unix, as was already done on Windows. * Removed currently unused LCMS code. * Pystring remains built as part of OCIO itself, since it has no good build system. * Linux and macOS check for the OpenColorIO verison, and disable it if too old. Ref D10270 Processors and Transforms ========================= CPU processors now need to be created to do CPU processing. These are cached internally, but the cache lookup is not fast enough to execute per pixel or texture sample, so for performance these are now also exposed in the C API. The C API for transforms will no longer be needed afer all changes, so remove it to simplify the API and fallback implementation. Ref D10271 Display Transforms ================== Needs a bit more manual work constructing the transform. LegacyViewingPipeline could also have been used, but isn't really any simpler and since it's legacy we better not rely on it. We moved more logic into the opencolorio module, to simplify the API. There is no need to wrap a dozen functions just to be able to do this in C rather than C++. It's also tightly coupled to the GPU shader logic, and so should be in the same module. Ref D10271 GPU Display Shader ================== To avoid baking exposure and gamma into the GLSL shader and requiring slow recompiles when tweaking, we manually apply them in the shader. This leads to some logic duplicaton between the CPU and GPU display processor, but it seems unavoidable. Caching was also changed. Previously this was done both on the imbuf and opencolorio module levels. Now it's all done in the opencolorio module by simply matching color space names. We no longer use cacheIDs from OpenColorIO since computing them is expensive, and they are unlikely to match now that more is baked into the shader code. Shaders can now use multiple 2D textures, 3D textures and uniforms, rather than a single 3D texture. So allocating and binding those adds some code. Color space conversions for blending with overlays is now hardcoded in the shader. This was using harcoded numbers anyway, if this every becomes a general OpenColorIO transform it can be changed, but for now there is no point to add code complexity. Ref D10273 CIE XYZ ======= We need standard CIE XYZ values for rendering effects like blackbody emission. The relation to the scene linear role is based on OpenColorIO configuration. In OpenColorIO 2.0 configs roles can no longer have the same name as color spaces, which means our XYZ role and colorspace in the configuration give an error. Instead use the new standard aces_interchange role, which relates scene linear to a known scene referred color space. Compatibility with the old XYZ role is preserved, if the configuration file has no conflicting names. Also includes a non-functional change to the configuraton file to use an XYZ-to-ACES matrix instead of REC709-to-ACES, makes debugging a little easier since the matrix is the same one we have in the code now and that is also found easily in the ACES specs. Ref D10274
2021-01-31 18:35:00 +00:00
PackedImageDesc *id = new (mem) PackedImageDesc(data,
width,
height,
numChannels,
BIT_DEPTH_F32,
chanStrideBytes,
xStrideBytes,
yStrideBytes);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
return (OCIO_PackedImageDesc *)id;
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
catch (Exception &exception) {
OCIO_reportException(exception);
}
return NULL;
}
Fixed compilation error on widows Was caused by mixing up own C-API typedefs with OCIO's
2012-10-05 10:05:26 +00:00
void OCIOImpl::OCIO_PackedImageDescRelease(OCIO_PackedImageDesc *id)
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
{
Move guarded objetc allocation to a guardedalloc header Also made libmv-capi use guarded objetc allocation. Run into some suspecious cases when it was not so clear whether memory is being freed or not. Now we'll know for sure whether there're leaks or not :) Having this macros in a guardedalloc header helps using them in other areas (for now it's OCIO and libmv, but in the future it'll be more places).
2013-10-09 08:46:02 +00:00
OBJECT_GUARDED_DELETE((PackedImageDesc *)id, PackedImageDesc);
Color Management, Stage 1: Initial OpenColorIO library integration This commit integrates support of OpenColorIO library into build systems. It also contains C-API for OpenColorIO library which could be used by Blender. CMake has got find rules familiar to OpenImageIO's one which makes it easier for build system to find needed libraries and includes. Scons only could use explicitly defined paths to libraries and includes. C-API would be compiled and Blender would be linked against C-API and OpenColorIO but it wouldn't affect on Blender behavior at all. OpenColorIO could be disabled by setting up WITH_OCIO to Off in CMake and setting WITH_BF_OCIO in Scons.
2012-09-15 10:03:17 +00:00
}
Extend system-info with information about OIIO, OCIO and OSL Summary: Version of those libraries might be useful to know. - OIIO and OCIO is exposed via bpy.app.oiio and bpy.app.ocio. There're "supported", "version" and "version_string" defined in those modules. - OSL is available as _cycles.osl_version and _cycles.osl_version_string. Reviewers: campbellbarton Reviewed By: campbellbarton CC: dingto Differential Revision: http://developer.blender.org/D79
2013-12-08 09:03:17 +00:00
const char *OCIOImpl::getVersionString(void)
{
Revert "Fix T47869: OpenColorIO Error with unicode path to config file under Windows" White the config itself could be loaded this way, lookup tables can not. Additionally, that's not really clear how to solve the issue with search path which is multi-byte only in the API. Reverting for further investigation. This reverts commit ab4307aa0868f2d8389cc0dd500eff38909b08f1.
2016-03-23 18:25:29 +00:00
return GetVersion();
Extend system-info with information about OIIO, OCIO and OSL Summary: Version of those libraries might be useful to know. - OIIO and OCIO is exposed via bpy.app.oiio and bpy.app.ocio. There're "supported", "version" and "version_string" defined in those modules. - OSL is available as _cycles.osl_version and _cycles.osl_version_string. Reviewers: campbellbarton Reviewed By: campbellbarton CC: dingto Differential Revision: http://developer.blender.org/D79
2013-12-08 09:03:17 +00:00
}
int OCIOImpl::getVersionHex(void)
{
return GetVersionHex();
}
Copy Permalink