Currently, the OpenEXR reader can't read single-layer XYZ images as a
combined image. Single-view images will only read the X channel, while
multi-view images will interpret the Z as a depth image and the Y and Z
channels will be treated as float passes.
This patch allows the reading of XYZ channels as combined images. For
single-view images, we just extend the RGB-like channel names we match
to contain XYZ. For multi-view images we only treat the Z channel as a
Depth one if no X and Y channels exists, since the Z in this case is
part of the XYZ image.
Pull Request: https://projects.blender.org/blender/blender/pulls/115290
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
Glow effect was doing the correct thing algorithmically (separable gaussian
blur), but it was 1) completely single-threaded, and 2) did operations in
several passes over the source images, instead of doing them in one go.
- Adds multi-threading to Glow effect.
- Combines some operations, e.g. instead of IMB_buffer_float_from_byte
followed by IMB_buffer_float_premultiply, do
IMB_colormanagement_transform_from_byte_threaded which achieves the same,
but more efficiently.
- Simplifies the code: removing separate loops around image boundaries is
both less code and slightly faster; use float4 vector type for more
compact code; use Array classes instead of manual memory allocation, etc.
- Removes IMB_buffer_float_unpremultiply and IMB_buffer_float_premultiply
since they are no longer used by anything whatsoever.
Applying Glow to 4K UHD sequencer output, on Windows Ryzen 5950X:
- Blur distance 4: 935ms -> 109ms (8.5x faster)
- Blur distance 20: 3526ms -> 336ms (10.5x faster)
Same on Mac M1 Max:
- Blur distance 4: 732ms -> 126ms (5.8x faster)
- Blur distance 20: 3047ms -> 528ms (5.7x faster)
Pull Request: https://projects.blender.org/blender/blender/pulls/115818
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774
This function is only used in Sequencer code to convert source byte images
into float images. For a "simple case" where there is no color space
conversion needed, it was doing that on a single thread, in two passes over
the image (first byte -> float conversion, then alpha premultiply).
VSE 4K resolution playback, with two image strips where one of them has
"convert to float" option, on Windows / Ryzen 5950X:
- Overall playback FPS: 3.40 -> 4.03. Still very slow, and a lot of time
is spent in allocating, clearing and deleting various temp images, as
well as final color conversion for display.
- `seq_imbuf_to_sequencer_space` part: 217.9ms -> 86.6ms. Most of
remaining cost is just in just memory allocation+clear, which is why
it's not drastically faster due to threading.
Pull Request: https://projects.blender.org/blender/blender/pulls/115628
Texture usage flag `GPU_TEXTURE_USAGE_MIP_SWIZZLE_VIEW`
was originally implemented and used too conservatively for many
cases in which the underlying API flags were not required.
Renaming to `GPU_TEXTURE_USAGE_FORMAT_VIEW` to reflect
the only essential use case for when a texture view is initialized with
a different texture format to the source texture. Texture views can
still be created without this flag when mip range or base level is
adjusted,
This flag is still required by stencil views and internally by the Metal
backend for certain feature support such as SRGB render toggling.
Patch also includes some small changes to the Metal backend to
adapt to this new compatibility and correctly capture all texture view
use-cases.
Related to #115269
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/115300
The r_data_format parameter from imb_gpu_get_format is always ignored
or overwritten by the r_data_format parameter from imb_gpu_get_data.
It makes more sense to just use the result from the imb_gpu_get_data
function for to determine the data format.
Pull Request: https://projects.blender.org/blender/blender/pulls/114662
Alternative solution to #114414 which reduces the scope of
textures for which single-channel greyscale optimization
is removed from.
Some byte buffers are converted to float buffers during
color management. These cases should retain support in
the optimal path.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/114611
Single channel JPEG files are stored in 4 channels image buffers, with their
bit planes set to 8.
When creating the GPU texture the number of bit planes is used to identify
if the data could be stored as a single channel texture, but in this case
the source data contains 4 channels and doesn't align with the GPU
texture format.
In Blender 3.6 the way how bit planes were stored changed (the planes
used to be 32 for the grayscale byte images matching the number of channels,
but now is set to 8, matching the original loaded image).
Since Blender 3.5 the grayscale byte images are uploaded using a single channel
GPU format, which leads to the mentioned artifacts. Grayscale byte buffers never
seems to have worked since its introduction in
https://archive.blender.org/developer/D15484
This PR disables using the grayscale GPU textures when it sourced from
a byte image.
Pull Request: https://projects.blender.org/blender/blender/pulls/114441
The `anim` data (e.g. of a VSE sequence) would store the last frame read from
FFMPEG as an image buffer, increasing its refcounting and preventing it
to be freed until the whole `anim` data itself gets freed.
In current code, there is no reason to keep a reference to this image
buffer in the `anim` data, so removing it. This may also give a few
percent improvement on the memory usage of the VSE in some cases.
Found while investigating #114342.
Pull Request: https://projects.blender.org/blender/blender/pulls/114395
Currently, the EXR reader only considers uppercase RGBA channel names in
single-layer EXRs, which leaves out the lower case rgba channel names we
started using for data and vector passes in Cycles and the compositor.
Further, a single V channel was also ignored, which is by convention
used for BW passes.
This patch extends the single-layer channel recognition methods to
include lowercase rgba and V channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/114339
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
It's possible to encounter a true 1-channel image if it's coming
directly from, say, a float-value AOV or similar.
This was not accounted for and would cause issues when saving the image
out to a 3 or 4 channel format (wrong values) or when saving out to
another 1 channel format (unnecessary usage of luminance weight values).
Pull Request: https://projects.blender.org/blender/blender/pulls/111577
AVFormatContext::duration was used without checking it was set,
calculations for the frame-rate cast -INT64_MAX to a double,
scaled it then cast to an integer - overflowing.
On my system the result was a negative number so the duration was never
usable in practice.
Add an explicit check for this so the duration is left at zero instead.
Remove unnecessary calls to BLI_file_descriptor_size when using
BLI_mmap_open since this stores the file size too.
While accessing the size twice isn't so bad, the additional check
that the file size isn't an error value is unnecessarily verbose.
Accessing the file size returns -1 on error, for file packing this
was passed directly to an allocation which would wrap around to
SIZE_T_MAX and fail to allocate. In other cases zero was treated
as an error value but -1 wasn't.
Add checks for the error return value, also warn that packing files over
2gb isn't supported.
AgX and Filmic have different looks in the configuration, but the looks
share the same UI name and purpose. So we can switch to the
corresponding look when switching view transforms.
Thanks to Yiming Wu for helping track down the problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/112686
Ensure the string isn't null terminated before len, if this happens
it's likely an error calculating the length argument. Since the length
is passed to memcpy it could result in reading outside `str` bounds.
There was one case where the string was duplicated then grew by 1 byte
afterwards. Replace this with an allocation since it's an uncommon
operation, not especially useful to support.
