Main goals of this refactor:
* Make it more obvious which update function should be used.
* Make it more obvious which parameters are required by using references instead
of pointers.
* Support passing in multiple modified trees instead of just a single one.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/132862
The new description for `bNode.type_legacy`:
```
/**
* Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname`
* does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames.
* This is mainly kept for compatibility reasons.
*
* Currently, this type is also used in many parts of Blender, but that should slowly be phased
* out by either relying on idnames, accessor methods like `node.is_reroute()`.
*
* A main benefit of this integer type over using idnames currently is that integer comparison is
* much cheaper than string comparison, especially if many idnames have the same prefix (e.g.
* "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node
* types. That could mean e.g. using `ustring` for idnames (where string comparison is just
* pointer comparison), or using a run-time generated integer that is automatically assigned when
* node types are registered.
*/
```
Pull Request: https://projects.blender.org/blender/blender/pulls/132858
This renames the struct `Sequence` to `Strip`.
While the motivation for this partially comes from
the "Sequence Design" #131329, it seems like this
is a good refactor whether the design gets implemented
or not.
The `Sequence` represents what users see as strips in the
VSE. Many places in the code already refere to a `Sequence`
as "strip". It's the C-style "base class" of all strip types.
This also renames the python RNA type `bpy.types.Sequence`
to `bpy.types.Strip` which means that this technically breaks
the python API.
Pull Request: https://projects.blender.org/blender/blender/pulls/132179
The compositor backdrop in certain files always have a size of 256x256
regardless of the actual size of the viewer image. That's because the
compositor writes its result to a different image buffer than the one
the image engine reads its image buffer from. And the image engine
assumes a default size of 256x256. The reason is a bit involved.
For non multi-view images, the image module uses the special cache index
value of IMA_NO_INDEX for the compositor backdrop, which works fine if
the image was detected as a non multi-view image in the first place.
However, this detection fails because the compositor may still write
multi-view images even for non multi-view renders.
In particular, before the compositor writes its viewer image, it ensures
correct views by calling BKE_image_ensure_viewer_views, which first
checks if we need to recreate the views of the viewer image if they
don't match the render views. And in the case of non multi-view image,
that check fails in one case.
Functions like BKE_image_is_multiview checks if a single unnamed view
exists in the image, unnamed being the keyword here. The root issue is
that BKE_image_ensure_viewer_views only checks that a single view
exists, while it should also check that it is unnamed. Which happens
when the user enabled multi-view, added only one view, then disabled
multi-view again.
To fix this, we add a check for the name of the view in case of non
multi-view images. And additionally pull the view matching code into its
own documented utility function for clarity.
Pull Request: https://projects.blender.org/blender/blender/pulls/132348
The image user of the Cryptomatte node does not have an up to date frame
number. That's because the BKE image user walker function which is used
to update image user frames numbers was missing handling for the node.
To fix this, add a case for the Cryptomatte node.
This is a partial fix for #132210.
Pull Request: https://projects.blender.org/blender/blender/pulls/132271
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
With exception of Sequencer, everywhere else in Blender it is assumed
that float images are in linear color space.
Movie files with more than 8 bit/channel precision are now loaded into
float images (since 39c4c7cf3f), but the "load and use them as an
image" code path was not making sure that they are converted to linear
color space.
Pull Request: https://projects.blender.org/blender/blender/pulls/131141
This commit refactors `BKE_image_load` and `BKE_image_load_exists` APIs:
* Remove the `_ex` versions (the 'exist' boolean return pointer can have
default `nullptr` value instead).
* Add `_in_lib` versions, which match signature and behavior of the
generic ID creation code to allow to find or create a new image ID
directly in a library 'namespace' (as linked data).
This is required by upcommig fixes for Brush Assets, which are using
linked but editable data-blocks.
Fix#130194: When trying to add a new image from the UI (e.g. for a new
texture) for a local ID, if that same exact image was already loaded by
a linked ID, it would trigger an assert in `BKE_id_move_to_same_lib`,
because `BKE_image_load_exists` would return the matching linked Image ID
instead of creating a new local one. In release builds with no assert,
it would result in making a linked ID 'local', while still being used by
original other linked data.
Passing around the intended final destination of the new Image (local or
in a given library) allows `BKE_image_load_exists` to be more specific
when searching for an already loaded matching image ID, and ensures that
a new local Image ID is created in the case described above.
Pull Request: https://projects.blender.org/blender/blender/pulls/130195
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
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
