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.
bd9f94e917 made it so the file browser doesn't bring files online for
the purpuse of creating their thumbnail, because that can take a while.
Instead it uses a previously cached thumbnail if available. This should
be the behavior for all cases thumbnails are requested, it's not only
the file browser that does this.
In fact it makes sense to move this into the normal function to "manage"
thumbnails (that is, load and if necessary (re)create cached
thumbnails) since there are no currently known use-cases for
different behavior.
Also, seems like the previous solution didn't work when loading ID
previews from offline .blend files. For that we need to use the path to
the .blend file to check the offline status, not the full path to the ID.
Found while working on #109234 (Use UI preview system for async loading of
file/asset previews).
Pull Request: https://projects.blender.org/blender/blender/pulls/112101
"filepath" was misleading since this path could also point into a .blend
file. Further, the convention was to use "filepath" for such files, and
"file_path" for when only an actual file path was expected. This is
highly confusing and non-obvious. Plus a (newer?) function broke with
the convention.
Just be explicit about the type of path, even if a bit verbose. It's
good to always have the reminder that this may be more than just a file
path when passing it around.
This confused me plenty of times. If there are two local variables I
assume they contain different things. In fact these two were equal
throughout the function.
This function is rather big and it's not clear what state variables are
in without a bunch of scrolling around. Plus, having the declarations
close to the function calls that set them makes it more clear that these
functions use the variables as output parameters. So this change should
help understanding the function flow.
Previously, BKE level preview image code was in `BKE_icons.h` and `icons.hh`.
While these types are related, I always found this quite hard to navigate since
preview image stuff was just in the middle of icon functions. Plus, people
don't expect preview image functions in icon files, the relationship is not
obvious.
Instead, use focused files that make it easy to quickly navigate them
and see what they are dealing with.
Pull Request: https://projects.blender.org/blender/blender/pulls/111709
Change compatible look check so that if the view contains
explicitly configured looks the non-explicit looks are not
added to the list.
In practice this means that if there are looks "Low Contrast"
and "AgX - Low Contrast" only the latter one is considered to
be compatible with the "AgX" view.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/111229
While currently the only way to reproduce the issue is to modify
the default OCIO configuration, change the view (which does yet
validate look on change) and save-reload, it seems to be a good
thing to validate anyway, to be more future-proof.
Pull Request: https://projects.blender.org/blender/blender/pulls/111209
If the new view transform does not support the currently configured
look reset look to the default None, similar to the color management
verification on .blend file open.
Currently it is not a problem as all views support the same set of
looks. But with an upcoming addition of AgX it will no longer be
true.
Ref #110685
Pull Request: https://projects.blender.org/blender/blender/pulls/111185
Jason Fielder
Hans Goudey
Campbell Barton
Jeroen Bakker
Philipp Oeser
Bastien Montagne
Richard Antalik
Omar Emara
Brecht Van Lommel
Jesse Yurkovich
Sergey Sharybin
Julian Eisel
Hans Goudey