The issue only happened when compiling with clang which
apparently evaluated the parameters in a different order.
`IMB_steal_encoded_buffer` sets `ibuf->encoded_size` to 0.
To avoid unnecessary looping over listbase items the function
`BLI_listbase_count_at_most` was used however it resulting in an awkward
expression: `BLI_listbase_count_at_most(list, count + 1) == count`
replace this with `BLI_listbase_count_is_equal_to(list, count)`.
Also remove noisy print when a thumbnail can't be generated from an
animation. Similar prints have been commented and mainly seem useful
for debugging.
Blender doesn't read meta data of images in case they were packed, which
make things like image Cryptomatte fail. This is because the image
loading code didn't specify meta data reading for packed images, but did
for normal images.
To fix this, we also specify meta data reading for packed images. And
while at it, move all common IB flags in the same like to avoid such
differences in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/126602
API: merged IMB_scalefastImBuf, IMB_scaleImBuf, IMB_scaleImBuf_threaded
into one function IMB_scale with enum IMBScaleFilter {Nearest, Bilinear, Box}
and bool "threaded" param.
Performance:
- Box filtering (nee IMB_scaleImBuf) can be multi-threaded now.
- Nearest filtering (nee IMB_scalefastImBuf) can be multi-threaded now.
Also fix performance regression on float images caused by fix in #126234
- Bilinear filtering (nee IMB_scaleImBuf_threaded) is several times faster now.
Correctness:
- Nearest and Box filtering: no longer loses half of edge pixels when scaling
up.
- Box: fixed garbage results (and possible out of bounds reads) for non-4
channel float images.
- Bilinear: no longer shifts image when scaling up.
- Bilinear: properly filters when scaling down by 2x2.
Test coverage:
- Add gtest coverage for various IMB_scale modes.
- Add a IMB_performance_test performance test, ran manually.
More details, images and performance numbers in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126390
Over the year, changes in how image packedfiles were handled broke the
fallback case of missing packed data in a few places, this commit fixes
proper cleanup of invalid packed files in the Image's list of
packedfiles.
In addition, also do not create inplicit sharing info when the read data
is `nullptr`.
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
The issue has been introduced by #122105
The image save operator does exactly the thing which was not supported by
the change and was not caught during development or view: it acquires and
releases image buffers while a render result of the Image data-block is
held acquired.
The solution is to implement a simple user-counter for the render result.
Currently it is only used by the image's render result acquire/release API,
as it is the most important case for now. The render pipeline uses its own
way of protecting the result, for which the user counter is not needed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122231
Conversion of compositor node tree to operation is done in a job thread,
and the main thread might modify the image data-block at the same time.
This change fixes it by making it so compositor uses acquire/release
semantic for the image data-block, and making it so the image locks its
render result, preventing other threads from modifying it.
Ref #121761
Pull Request: https://projects.blender.org/blender/blender/pulls/122105
Image's render result might get freed from another thread while the
compositor is running.
Add an utility function which invokes callback on the image's stamp
data from a thread-guarded block.
Ref #118337, #121761
Pull Request: https://projects.blender.org/blender/blender/pulls/121907
Image operation's get_im_buf() function was not thread-safe:
- It had TOCTOU issue around calculating multi-layer indices and
requesting to load the image buffer.
- It accessed render result, render layer and pass pointers without
any thread guards.
This change moves all the logic needed to access the image buffer
into a single function with proper guards around the access. The
result is user-counted, so it is usable in a thread even if another
thread modifies the image.
The is still potential TOCTOU in the compositor since the image is
acquired twice: once from init_execution(), and once from the
determine_canvas(). It could cause issues if image resolution is
changed between these calls. It is still to be looked into.
Ref #118337, #121761
BLF_buffer was trying to accept "how many colors channels in output
image?" argument and doing math with it, but in the lowest level code
was always writing out full 4 channels for each pixel.
All the call sites would ever call it with argument of 4 however, and
that is why no one noticed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/121630
This makes the read and write API functions match more closely, and adds
asserts to check that the data size is as expected.
There are still a few places remaining that use BLO_read_data_address
and similar generic functions, these should eventually be replaced as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/120994
Remove all BLF "_ex" versions of functions by using default arguments.
These functions only differ by having an optional argument that can
return extra details about the result of the operation. This PR just
make these part of the main function as optional arguments with default
values - all nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/119994
This patch refactors the backdrop offset to be stored as a float instead
of an int and to be stored in the image runtime structure instead of the
image itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/119877
Seems to work OK in basic cases, but needs more work when copying
outside of Main at least.
Note: There is no behavioral changes expected from this commit.
Note that there are at least two known usecases for this change:
* Liboverrides, as with recursive resync and proxies conversion it
often ends up creating 'virtual' linked data that does not actually
exists in the library blend files.
* Complex versionning code (`do_versions_after_setup`) when it needs
to create new IDs (currently handling linked data that way is just not
supported!).
Implements #107847.
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
This data was 'hidden' away in a util in
`lib_query.cc`, which made it hard to discover and keep up-to-date.
However, as shown by e.g. #108407, critical low-level features in ID
management code, such as remapping, now rely on this information being
valid.
Also simplify `BKE_library_id_can_use_filter_id` and
`BKE_library_id_can_use_idtype` to make them more generic, relying on
IDTypeInfo to retrieve IDtype-specific info.
No behavioral changes expected here.
`BKE_image_scale` -- which is only used for the python API -- was
getting the `ImBuf` without providing an `ImageUser`.
This is fine, but always gets the first tile (and the current frame for sequences).
To resolve this, add an optional "frame" & "tile_index" argument so these can be specified explicitly (similar to layer_index and pass_index already used for some other API functions).
Fixes#117539 : Scaling UDIM images via Image.scale() only scales one tile
Pull Request: https://projects.blender.org/blender/blender/pulls/117549
Broken from 72ab6faf5d
Because the `IMA_GEN_TILE` flag was not cleared during the memory pack,
the tile was regenerated on reloading. Mimic what is done during save
and clear the flag if all tiles pack successfully.
Pull Request: https://projects.blender.org/blender/blender/pulls/117472
Rename: anim -> ImBufAnim
Rename: anim_index -> ImBufAnimIndex
There were cases where removing redundant "struct" qualifier caused
a warning since the name of the struct member was also anim.
Use uppercase type name to conform with other types names.
Ref !117394
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
The name `offset_in_ID` is very misleading since it does not have to be an offset at all,
it just has to be some unique value. Often it's also a hash or a constant value depending
on the use.
Pull Request: https://projects.blender.org/blender/blender/pulls/117306
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
Except for vertex groups and a few older color types, these
are generally replaced by newer generic attribute types.
Also remove some includes of DNA_mesh_types.h, since it's
included indirectly by BKE_mesh.hh currently.
The Realtime compositor currently relies on the GPU cache in image IDs.
That cache only supports single layer images, so multi-layer images will
be acquired without a cache, introducing significant IO bottlenecks for
the GPU compositor.
This patch ignores the image GPU cache and stores the images in the
static cache manager of the compositor. Draw data was introduced to the
image ID for proper cache invalidation, like other IDs such as masks.
The downside is that the cache will no longer be shared between EEVEE
and the compositor. But realistically, images are not typically shared
between materials and compositors.
This is just a temporary solution until we have proper GPU storage
support for image buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/115511
