Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Make it so transform between color spaces which is a no-op does not
peroform any calculations.
This was initially found when working on #110941, but the issue can
be replicated easily by renaming "Linear" to "Linear Rec.709" and
adding alias as "Linear".
Doing so would result in a failure of the compositor_matte_test.
The reason for that is due to the image data-block still referring
to the "Linear" color space, the name-based comparison not detecting
that "Linear" and "Linear Rec.709" are the same spaces, and that the
cryptomatte requires bit-perfect floating point values.
Pull Request: https://projects.blender.org/blender/blender/pulls/110959
The current core was only detecting sRGB transform when it is defined
as sRGB->Linear using srgb.spi1d. If it is defined as an inverse of
Linear->sRGB using srgb_inv.spi1d, or as an analytical formula using
ExponentWithLinearTransform then the code did not detect the color
as sRGB on anything by Apple Silicon platform.
The naming of the checks could be improved to make it more clear that
the check is only used to allow lossless access to 8bit sRGB textures.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/110889
The goal is to solve confusion of the "All rights reserved" for licensing
code under an open-source license.
The phrase "All rights reserved" comes from a historical convention that
required this phrase for the copyright protection to apply. This convention
is no longer relevant.
However, even though the phrase has no meaning in establishing the copyright
it has not lost meaning in terms of licensing.
This change makes it so code under the Blender Foundation copyright does
not use "all rights reserved". This is also how the GPL license itself
states how to apply it to the source code:
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software ...
This change does not change copyright notice in cases when the copyright
is dual (BF and an author), or just an author of the code. It also does
mot change copyright which is inherited from NaN Holding BV as it needs
some further investigation about what is the proper way to handle it.
* Rename ambiguous rgb to scene_linear in some places
* Precompute matrices to directly go to scene instead of through XYZ
* Make function signatures more consistent
Between scene linear and sRGB, XYZ, linear Rec.709 and ACES2065-1.
And add some clarifications about color spaces in the docs.
Fixes T98267
Ref T68926
Differential Revision: https://developer.blender.org/D14989
* Don't assume the display colorspace name fully defines the transform
to display space, this is not true in OpenColorIO 2 where view transforms
may be defined in more complexs ways than just specifying a colorspace.
* In places where we need to store the display colorspace name, resolve
<USE_DISPLAY_NAME> token manually.
Ref T96590
This enables the configuration to specify aliases for compatibility with other
configurations.
When a colorspace name is saved in a.blend, that is the alias of a colorspace
in the current configuration, it will show the main colorspace from the
configuration in the user interface and Python API instead.
Loading & saving the .blend file does not make any changes to the stored name,
so as to not make hidden modifications. Only when setting the property again
will the alias name be overwritten by the main colorspace name.
Fixes T96049
Differential Revision: https://developer.blender.org/D14419
This affected loading of EXR files with set to Linear ACES colorspace, as
well as the sky texture for in some custom OpenColorIO configurations.
Use the builtin OpenColorIO transform from ACES AP0 to XYZ D65 to fix this.
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Using the `MEM_*` API from C++ code was a bit annoying:
* When converting C to C++ code, one often has to add a type cast on
returned `void *`. That leads to having the same type name three times
in the same line. This patch reduces the amount to two and removes the
`sizeof(...)` from the line.
* The existing alternative of using `OBJECT_GUARDED_NEW` looks a out
of place compared to other allocation methods. Sometimes
`MEM_CXX_CLASS_ALLOC_FUNCS` can be used when structs are defined
in C++ code. It doesn't look great but it's definitely better. The downside
is that it makes the name of the allocation less useful. That's because
the same name is used for all allocations of a type, independend of
where it is allocated.
This patch introduces three new functions: `MEM_new`, `MEM_cnew` and
`MEM_delete`. These cover the majority of use cases (array allocation is
not covered).
The `OBJECT_GUARDED_*` macros are removed because they are not
needed anymore.
Differential Revision: https://developer.blender.org/D13502
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
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
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
This fixes our workaround for until proper solution is accepted
in upstream.
Now, when default view behaves same as it was supposed to (and
as it behaves in OCIO-1.0.9) it is obvious that our configuration
violates own design -- default view is used for cases when
images don't want to be displays using "render" settings.
This is something what is caused by OCIO library. The patch
has been submitted there:
https://github.com/imageworks/OpenColorIO/pull/638
For until it is refined and checked we do workaround from
our side.
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.
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.
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
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).
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.
Apparently C== allowed to have implementations of
OCIOImpl::setupGLSLDraw, OCIOImpl::finishGLSLDraw and
OCIOImpl::freeGLState in two different files.
STUPID!
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.