As evidenced by #138868, checking all colorspaces to see if they are sRGB
can be very slow, due to loading all LUTs into memory. Instead use a simpler
check by a list of names only, which is still better than the hardcoded
single name used in Blender 4.4.
Ideally recent configs will use the ColorInterop Forum alias so we can
find the sRGB colorspace reliably.
Briefly about this change:
- OpenColorIO C-API is removed.
- The information about color spaces in ImBuf module is removed.
It was stored in global ListBase in colormanagement.cc.
- Both OpenColorIO and fallback implementation supports GPU drawing.
- Fallback implementation supports white point, RGB curves, etc.
- Removed check for support of GPU drawing in IMB.
Historically it was implemented in a separate library with C-API, this
is because way back C++ code needed to stay in intern. This causes all
sort of overheads, and even calls that are strictly considered bad
level.
This change moves OpenColorIO integration into a module within imbuf,
next to movie, and next to IMB_colormanagement which is the main user
of it. This allows to avoid copy of color spaces, displays, views etc
in the ImBuf: they were used to help quickly querying information to
be shown on the interface. With this change it can be stored in the
same data structures as what is used by the OpenColorIO integration.
While it might not be fully avoiding duplication it is now less, and
there is no need in the user code to maintain the copies.
In a lot of cases this change also avoids allocations done per access
to the OpenColorIO. For example, it is not needed anymore to allocate
image descriptor in a heap.
The bigger user-visible change is that the fallback implementation now
supports GLSL drawing, with the whole list of supported features, such
as curve mapping and white point. This should help simplifying code
which relies on color space conversion on GPU: there is no need to
figure out fallback solution in such cases. The only case when drawing
will not work is when there is some actual bug, or driver issue, and
shader has failed to compile.
The change avoids having an opaque type for color space, and instead
uses forward declaration. It is a bit verbose on declaration, but helps
avoiding unsafe type-casts. There are ways to solve this in the future,
like having a header for forward declaration, or to flatten the name
space a bit.
There should be no user-level changes under normal operation.
When building without OpenColorIO or the configuration has a typo or
is missing a fuller set of color management tools is applies (such as the
white point correction).
Pull Request: https://projects.blender.org/blender/blender/pulls/138433
Previous conversion to scene linear was done in the display transform
shader. Having a separate shader to convert texture to scene linear
allows drawing input textures with different color spaces into a
viewport and apply display transform on all of them.
Currently unused, but is required for !138094. It could also be used
in the future to avoid host-side linearization in the image engine.
Internally it uses a lot of the same logic for shader caching and
binding, but the code is refactored a bit to make it easier to have
a stronger separation in the future if needed.
Ref #138094
Pull Request: https://projects.blender.org/blender/blender/pulls/138308
- ImBuf reference counting: turn that into just an atomic integer
- Cachefile safety: turn into a mutex, since work under the spinlock
was quite heavy (hashtable creation, other memory allocations)
- Movie clip editor: turn into a mutex, since work under the spinlock
was very heavy (reading files from disk, etc.)
- Mesh intersect: remove the previously commented out spinlock path;
replace BLI mutex with C++ mutex for shorter code
Pull Request: https://projects.blender.org/blender/blender/pulls/137989
Other changes include:
- Replace buffer out of bounds check with an assert
(it was only done for the byte).
- Step over pixels on each X span
instead of calculating the offset for each pixel.
- Use const variables.
Note that moving to the templated versions of array allocation functions
in [0] caused integer overflow regressions because multiplying by the
`sizeof(type)` caused the following values to be cast to a size_t.
[0]: e85ebb24fe
WebP images can be at most 16383x16383,
however saving sizes which overflowed an integer would crash.
- Early exit with an error when the image is too large.
- Replace integer offsets with size_t.
- Files cannot exceed 65535 width or height,
attempting to write 65536 would write a zero sized image.
- Ensure that zero sized imbufs are never loaded.
The first two bytes were being checked in the wrong order,
if files using this header were loaded they would detect as IRIS files
from imb_is_a_iris which would then fail to load (printing errors).
This reverts commit cf55a0acdc.
While this was added with the commit that added support for tile cache,
keep the extension check as Blender can load them.
Add a "Pixel Density" sub-panel to render output settings which
can be used to set the density (as pixels per inch for example).
This is then written to images that support pixel density.
Details:
- The scene has two values a PPM factor and a and base unit.
- The base unit defaults to pixels per inch as this is the most
common unit used.
- Unit presets for pixels per inch/centimeter/meter are included.
- The pixel density is stored in the render result & EXR cache.
- For non 1:1 aspect renders, the density increases on the axis
which looks "stretched", so the PPM will print the correct
aspect with non-square pixels.
Ref !127831
The Blender config.ocio does not have any rules, but custom ones can.
The default file rule is ignored if default_byte or default_float roles
exist. These roles are Blender specific, so would not be found in a typical
OCIO config. But when they are set appropriately, they help provide better
default guesses than what is possible with standard OCIO rules.
Pull Request: https://projects.blender.org/blender/blender/pulls/136516
The file formats now fill in ImColorSpaceInfo with the metadata colorspace
and a boolean saying if the pixels have HDR colors. And then the actual
colorspace is decided in imb_handle_colorspace_and_alpha.
This centralizes the logic in one place to make it possible to add
OpenColorIO file rules.
Pull Request: https://projects.blender.org/blender/blender/pulls/136516
Set the flags on the image buffer when loading an EXR file, so they can be
used when saving.
This also removes IB_halffloat and replaces it by the file options flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/135656
Use aces_interchange role in OpenColorIO to identify the correct colorspace
for each config. Also use acesImageContainerFlag attribute from the ACES
container format to identify the colorspace.
Write ACES2065-1 chromaticities in EXR files when appropriate. This gets us
closer to supporting output of the ACES container format, though we don't
write acesImageContainerFlag. There are various restrictions that must be met
which are not very practical, and even exr2aces doesn't write it.
Pull Request: https://projects.blender.org/blender/blender/pulls/135823
The OpenEXR format has a chromaticities attribute that identifies the scene
referred linear color space. Detect these two cases now, and assign the
corresponding color space from the OpenColorIO configuration.
In general these chromaticities are known to be unreliable and missing support
in most software, with ideas to deprecate them entirely. However the ACES
container format standard requires them, and with this change we'll be able to
read such images with the right color space set by default.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/135823
Looks like a logic inversion mistake.
Not clear how bad this issue is, as other code related to image metadata
seems to expect 1024 char max size too (e.g. `MAX_METADATA_STR` define
in `ed_draw.cc`. But this is potentially a very bad issue, and the fix
seems safe enough for 4.4 still.
Should also be backported to active LTSs.
Pull Request: https://projects.blender.org/blender/blender/pulls/135983
