| Age | Commit message (Collapse) | Author |
|---|
|
Make the update logic consistent with the case where the initial texture is
created. Also fixes a wrong assert.
Thanks Clément for spotting this.
|
|
From quick look it doesn't seem to be leading to real issues yet as the
image buffers are created with the default roles, but valid color space
is needed to be ensured for an upcoming development.
|
|
Mainly duplicate includes and else after return.
|
|
Same as in Cycles, this is needed for some color space conversions that don't
compress well to byte sRGB, like for example Filmic sRGB.
Ref T68926
|
|
|
|
|
|
* Port over new code tables from Cycles
* Convert Rec.709 to scene linear for lookup table.
* Move code for wavelength and blackbody to IMB so they can access the
required transforms, which are not in blenlib.
* Remove clamping from blackbody shader to bypass the texture read.
Since it's variable now easiest to just always read from the texture
than pass additional parameters.
* Fold XYZ to RGB conversion into the wavelength table.
Ref T68926
|
|
|
|
* 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
|
|
|
|
The names of color spaces in OpenColorIO configs can be arbitrary, so don't
use hardcoded names from our default config.
|
|
* Respect the image file color space setitng for saving in various cases where
it was previously ignored. Previously it would often use the sRGB or Linear
color space even when not selected.
* For the Save As operator, add a Color Space option in the file browser to
choose the color space of the file. Previously this was chosen automatically,
now it's possible to e.g. resave a Linear image as Linear ACES.
* When changing the file format, the colorspace is automatically changed to an
appropriate color space for the file format. This already happened before, but
there was no visibility or control in the operator settings for this.
* Don't change color space when using the Save operator to save over the same
file.
* Fix missing color space conversion for 16 bit PNGs, where it assumed wrongly
assumed ibuf->rect would be used for saving. Add BKE_image_format_is_byte to
more accurately test this.
Fixes T74610
Ref T68926
Differential Revision: https://developer.blender.org/D14899
|
|
* 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
|
|
- Deprecated headers
- Else after return
- Inconsistent parameter names (I used the most recently modified)
- Raw string literals
|
|
|
|
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
|
|
The Output Properties > Output panel now has a Color Management subpanel to
override scene settings. When set to Override instead of Follow Scene, there
are settings to:
* For OpenEXR, choose a (linear) colorspace for RGBA passes
* For other file formats, use different display/view/look/exposure/gamma
These settings affect animation render output, image save of renders and the
compositor file output node. Additionally, the image save operator and
compositor file output nodes also support overriding color management.
Includes some layout changes to the relevant panels to accomdate the new
settings and to improve consistency. Ideally subpanels would be used to better
organize these settings, however nodes and operators don't currently support
creating subpanels.
Differential Revision: https://developer.blender.org/D14402
|
|
Make a copy of ImageFormatData that contains the effective color management
settings, and pass that along to the various functions. This will make it
possible to add more complex logic later.
For compositing nodes, passing along view and display settings through
many functions made it harder to add additional settings, so just get those
from the scene now.
Differential Revision: https://developer.blender.org/D14401
|
|
These share a lot of logic with regular image saving and should be unified
more in the future.
|
|
Also fixes missing code to read/write/free/copy color management settings
in various places. This can't be set through the UI currently, but still
should be handled consistently.
|
|
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
|
|
Ref T92709
|
|
Previously, `ImageTile->ok` and `ImageUser->ok` were used to indicate
whether an image failed to load. There were three possible values
which (probably) had the following meanings:
* `0`: There was an error while loading the image. Don't try to load again.
* `1`: Default value. Try to load the image.
* `2`: The image was loaded successfully.
This image-wide flag did not make sense unfortunately, because loading
may work for some frames of an image sequence but not for others.
Remember than an image data block can also contain a movie.
The purpose of the `->ok` flag was to serve as an optimization to avoid
trying to load a file over and over again when there is an error (e.g. the
file does not exist or is invalid). To get the optimization back, the patch
is changing `MovieCache` so that it can also cache failed load attempts.
As a consequence, `ibuf` is allowed to be `NULL` in a few more places.
I added the appropriate null checks.
This also solves issues when image sequences are used with the
Image Texture node in Geometry nodes (also see D12827).
Differential Revision: https://developer.blender.org/D12957
|
|
We now use a for_each function with callback to iterate through all sequences in the scene.
This has the benefit that we now only loop over the sequences in the scene once.
Before we would loop over them twice and allocate memory to store temporary data.
The allocation of temporary data lead to unintentional memory leaks if the code used returns to exit out of the iteration loop.
The new for_each callback method doesn't allocate any temporary data and only iterates though all sequences once.
Reviewed By: Richard Antalik, Bastien Montagne
Differential Revision: http://developer.blender.org/D12278
|
|
|
|
This shows the text as part of the assertion message.
|
|
Scanline processor did its own heurestic what didn't scale well when
having a multiple cores. In stead of using our own code this patch will
leave it to TBB to determine how to split the scanlines over the
available threads.
Performance of the IMB_transform before this change was 0.002123s, with
this change 0.001601s. This change increases performance in other areas
as well including color management conversions.
Reviewed By: zeddb
Differential Revision: https://developer.blender.org/D11578
|
|
Includes fixes to misspelled function names.
Ref D11280
|
|
And fix a (harmless) compiler warning.
|
|
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
|
|
|
|
|
|
is present
Caused by rB4212b6528afb.
'updateGLSLCurveMapping()' compares cacheIDs and in certain scenarios,
these are the same when they should not.
- whenever we had multiple viewports that are colormanaged with
curvemappings this worked right (cacheIDs were different)
- for example, this also worked right when the ImageEditor displays a
Render Result or a Compositor Viewer
- but it worked wrong when the Image Editor displays any other Image (or
no Image at all)
- it also worked right if there were multiple Image Editors [and one of
them displays a Render Result e.g]
Now why is this so?
For comparison, the curve mapping's pointer/address is used.
- update_glsl_display_processor frees the curve_mapping, see
BKE_curvemapping_free(global_glsl_state.curve_mapping)
- similar, update_glsl_display_processor creates a new curvemapping, see
BKE_curvemapping_copy(view_settings->curve_mapping)
- now for the situation that a viewport with curvemapping and a viewport
without curvemapping is present and you make changes to the curvemapping
the following happens:
-- curve_mapping_settings->cache_id is set once [to the memory address
of curvemapping before change]
-- change happens
-- viewport 1 frees curvemapping
-- viewport 2 duplicates using BKE_curvemapping_copy, but this one gets
the same address like before the change
-- this means we have different data on the same address with the same
cacheID...
Solution: to really make the cache ID unique we can combine the pointer
with its 'changed_timestamp' [which increases on every change].
Reviewers: jbakker
Maniphest Tasks: T82460
Differential Revision: https://developer.blender.org/D9559
|
|
This callback made some sense before moving the file-type information
from a bit-flag to an enum: e142ae77cadf04103fbc643f21cf60891862f6a8
Since then, we can compare the type value directly.
Also replace loops over file types with IMB_file_type_from_{ibuf/ftype}.
|
|
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9349
|
|
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
|
|
|
|
No functional changes expected.
|
|
Also order sizeof(..) first to promote other values to size_t.
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/imbuf` module.
No functional changes.
|
|
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
|
|
|
|
Clang Tidy reported a couple of false positives. I disabled
those `NOLINTNEXTLINE`.
Differential Revision: https://developer.blender.org/D8199
|
|
I'm not sure if the Sky was deliberately left out or was just waiting for a
better moment, but so many I was disappointed that Sky in EEVEE is
completely white.
There are already 2 implementations (osl and gpu) so this is the third one.
Looking at other cases it seems that we are not supposed to share sources
between cycles and the rest? So the new util_sky_model files are just
copies of what is already in cycles, except that the data file uses the RGB
variant of the Hosek/Wilkie model, because we output RGB anyway (but can be
easily changed to XYZ if desired - the results are nearly identical).
I am not sure if it is okay to pass 3*9 float values as 3 mat4 uniforms (I
wanted to use mat3 but it does not work).
Also, should I cache the sky model data between renders if the parameters
do not change?
Reviewed By: fclem, brecht
Differential Revision: https://developer.blender.org/D7108
|
|
settings
Stabilized ImBuf just needs to use the same colorspace and alpha
settings as the original one.
Maniphest Tasks: T76698
Differential Revision: https://developer.blender.org/D7713
|
|
Also pass some args as 'const'.
|
|
When RGB images or BW images are converted to a GPU texture and color
space conversion was needed the images were read incorrectly.
This patch checks the correct amount of channels in the image and uses
that as the correct pixel stride.
|
|
|
|
Reviewed By: brecht sergey jbakker
Differential Revision: http://developer.blender.org/D6729
|
