A tone mapper designed specifically for PBR color accuracy, to get sRGB
colors in the output render that match as faithfully as possible the input
sRGB baseColor under gray-scale lighting. This is aimed toward product
photography use cases, where the scene is well-exposed and HDR color values
are mostly restricted to small specular highlights.
Fixes#118824: Proposal: add a view transform for Khronos PBR Neutral Tone Mapper
Co-authored-by: Emmett Lalish <elalish@google.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118936
AgX exhibited some banding-like artifacts that were due to being
approximated with a 3D LUT. This commit resolves that by increasing
the LUT resolution enough to mitigate the artifacts and make them
unnoticeable.
Additionally:
- The previous LUTs were written in a space-inefficient way, using
e.g. "0.000000" instead of "0". The new LUTs are written more
efficiently, avoiding quite as dramatic a file size increase as
usually accompanies 3D LUT resolution increases.
- The previous LUTs included output values greater than 1.0, which was
both incorrect for a tone mapper, and also pointless since Blender
immediately clips them anyway. The new LUTs clip to 1.0. This also
allows the more efficient writing to squeeze even more space savings
out of the LUTs.
- The previous inverse AgX LUT contained NaNs. Those have been
replaced with 0.0 in the new inverse LUT.
Note that due to discrepancies between the LUTs previously provided
to Blender and the AgX scripts that were later published, the color
transform in these LUTs are slightly different. But they are close, and
equivalently good.
Pull Request: https://projects.blender.org/blender/blender/pulls/113253
On a user level this view transform provides much better handling of colors in
the over-exposed areas.
With this configuration the following display devices are available, including
AgX view transform for them:
* sRGB
* Display P3
* Rec.1886
* Rec.2020
NOTE: There is no Filmic view transform available for the newly added display
devices.
AgX also brings an implementation of False Colors view transform, which replaces
Filmic-based, and is available for all display devices.
The backward compatibility is preserved. The new files will default to AgX view
transform, which makes it non-forward compatible.
More technical details is available in the original PR #106355.
Please note that the PR has been split into more incremental changes when
was landing.
Pull Request: https://projects.blender.org/blender/blender/pulls/111099
The change is motivated by using the actual CIE standard, preparing for the
Spectral Cycles, and making followup AgX integration more straight forward.
On a user level this change renames XYZ space to Linear CIE-XYZ D65, and
introduces Linear CIE-XYZ E.
The aliases are configured so that the backward compatibility is preserved.
The forward compatibility will be achieved by committing an alias name to the
3.6 release branch.
Ref #110685
Use OCIO's built-in functionality for sRGB which allows to have un-clipped
range of the input colors. The lookup tables are now removed.
Should be no functional changes on the user side.
However, it is possible that this change does not preserve exact per-pixel
value due to difference in precision.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110712
This is a Step 1 of the AgX project integration, which is focused on cleaning
up legacy aspects of the configuration.
Delete all not longer used colorspaces and their LUT files. This includes:
nuke_rec709, lg10, XYZ display device and its standard view colorspace.
The nuke_rec709, lg10 were not used, and the XYZ display device was initially
added to support output for a DCP compliant J2K files. Unfortunately, some of
the crucial transform was missing from this initial configuration, so often a
custom OCIO configuration was needed. With the addition of Filmic and now with
AgX this really became not-so-usable use-case. Also, there is no display device
which is XYZ and on which Blender can realistically run.
The None display device has duplicated functionality as the Raw view in sRGB
display. Its need originated for the compatibility with legacy "No Color
Management" option in Blender. It is also missing in the fallback color
management implementation. So, now use sRGB with Raw view to replicate the
old behavior. There will be a separate do-version commit after this one to help
transitioning the current files to the new configuration.
The Raw and Non-Color are duplicates of each other, there is no need to have
both of them. Since users are more familiar with Non-Color, and it's also the
one assigned as the data role, will keep Non-Color and remove Raw. For the
compatibility the Raw is an alias of the Non-Color space.
Ref #110685
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.
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
* Replace Log view transform with Filmic Log.
* Remove Rec.709, DCI-P3 displays that were incomplete and outdated.
* Remove outdated RRT and Film transforms, replaced by Filmic.
* Remove camera responsive curves that don't work with HDR colors.
* Rename Default view transform to Standard.
We're breaking compatibility now for 2.80, so that we can add future
improvements on a clean config.
Part of the code was contributed by George Vogiatzis in D4782.
Differential Revision: https://developer.blender.org/D4900
Previously converting from linear space to SRGB was doing rather
slow inverted 1D lookup. Adding explicit inverse LUT gives 20%
speedup of OpenGL render.
Next question is: why do we even bother with sRGB conversion here,
OpenGL is already in the proper space so in theory we can avoid
quite some color space conversions. In any case, having this case
optimized in nice anyway.
* Reorder list a bit to put brands together
* Move looks menu below views
* Rename camera_response to film_response folder, to make clear that these
are photographic film types, not camera models
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.
- Sequencer preview was clamping float buffers
- ACES color space wasn't correct, was noticeable when
applying display processor from linear space to display.
- Extended sRGB LUT to sRGBf from nuke-default config.
Makes sequencer behave much better in sRGB space.
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.
