- In various VSE related DNA structs, indicate which enums they use
as comments,
- Add enum types for the enums that were untyped,
- Move Wipe effect enums to DNA header for clarity, since they are
serialized values,
- Reduce SeqRetimingKey size from 40 bytes to 32 bytes; there
was too much unnecessary padding.
- Rename some enums SEQUENCE_ -> STRIP_ where relevant.
- Rename wipe enums DO_MEOW_WIPE -> SEQ_WIPE_MEOW
Pull Request: https://projects.blender.org/blender/blender/pulls/143565
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
Ultimately, the issue was caused by updating sound sequence handle in
`AUD_SequenceEntry_setSound` on each new frame regardless if the
modifier data has changed.
This commit fixes the issue by implementing a means for modifiers to
check, if their parameters or inputs are changed.
This is done by storing these parameters in `StripModifierDataRuntime`
struct, that is shared between all modifier types. This is not ideal,
but it significantly simplifies dependency graph runtime store/restore
code.
Function `strip_update_sound_modifiers` passes boolean `needs_update`
to strip stack update functions. If any needs to be updated, it sets
value of `needs_update` to true allowing following update functions to
skip parameter checking to speed up the process.
Original code updated sound sequence handle twice. Once by function
`BKE_sound_update_scene_sound` then by `strip_update_sound_modifiers`.
If sound modifier is used, only `strip_update_sound_modifiers` needs to
be called, so there is condition to decide which one of these functions
is called.
Also fixes#139605
Pull Request: https://projects.blender.org/blender/blender/pulls/141595
New sequence strip modifiers get a name that is to be translated if
translation of data is enabled. This used the default translation
context, but "Sequence" must be used because this is the context used
to extract the modifier names (`modifiersTypes` array in modifier.cc).
Reported by Ye Gui in #43295.
I18n: Translate a few messages
- Translate add-on types in the user preferences.
- Translate a report which uses formatting.
- Do not translate scene names in `sequencer.scene_strip_add` operator
UI.
- Do translate the type of new scene in
`sequencer.scene_strip_add_new` operator.
- Translate Half and Float image format color depth enum items.
- Translate Mix node header with non-color data types.
- Translate sequencer modifiers' names if data translation is enabled.
Most issues reported by Ye Gui in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/141145
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
Ref: #132179
Renames:
- `Editing.act_seq` -> `Editing.act_strip`
- `SequenceModifierData` -> `StripModifierData`
- Its member `mask_sequence` is now `mask_strip`.
- `MetaStack.parseq` -> `MetaStack.parent_strip`
- Remaining function names/parameters that were not dealt with in #132748
- Various references to `seq` or `sequence` throughout code and docs when
referring to a strip
Also moves `_get` to the end of the renamed function names where
applicable for standardization (unless "by" or "from" are used).
There should be no changes to current behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/138077
This PR creates 2 namespaces for VSE code:
- `blender::seq` for sequencer core code
- `blender::ed::vse` for editor code
These names are chosen to not be in conflict with each other.
No namespace was used for RNA.
Finally, file `BKE_sequencer_offscreen.h` was moved from BKE to sequencer.
Pull Request: https://projects.blender.org/blender/blender/pulls/135500
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 type info table for VSE modifiers was initialized to point
to global variables on first use. But really there's no reason to do
that, we can just declare the actual table instead. This is both
shorter, and avoids dances with preprocessor (INIT_TYPE macro).
Pull Request: https://projects.blender.org/blender/blender/pulls/131958
Originally intended to be a code cleanup that makes the code shorter
(part of VSE quality project #130975), but as a side effect many
modifiers are now faster since they no longer do many branches in
the innermost pixel loop.
Main part is having apply_modifier_op that given the "modifier op"
functor object, instantiates the correct processing function based
on type of image (byte vs float) and mask (none, byte, float), for
a total of 6 possible cases. And then a helper like
apply_and_advance_mask that applies mask based on input and result
in a consistent and not "literal copy paste of code" way across the
modifiers.
Brightness/Contrast, Color Balance, Tonemap modifiers were already
optimized to move branches out of inner loops previously; their
performance remains unchanged. Mask modifier performance remains
unchanged; it is very simple and memory bandwidth limited on my
machine.
Other modifiers, tested on 4K resolution, Win10 / Ryzen 5950X, time
in milliseconds taken to apply the modifier calculation, on a byte
image with no mask:
- Curves: 12.1 -> 7.7ms
- Hue Correct: 24.5 -> 15.8ms
- White Balance: 20.5 -> 13.8ms
Same as above, but on a float image with a byte mask:
- Curves: 13.5 -> 12.3ms
- Hue Correct: 19.7 -> 16.4ms
- White Balance: 19.3 -> 15.9ms
Pull Request: https://projects.blender.org/blender/blender/pulls/131736
Commit 073ce98231 back in 2016 changed white balance math to do
a pow based pixel operation instead of multiplication. However
pow on negative numbers (which would happen on any HDR input) is
undefined. Until some better math is decided upon, at least ensure
the input is not negative.
If a strip mask was used several times in the same frame, and it needed
to do byte->float conversion (e.g. mask is produced by a byte-color
strip, but then used in both a byte-color strip, and later on in a
float-color strip), then that byte->float mask image conversion was
introducing two inconsistencies:
- It was making mask alpha channel affect the result, which was not
happening with regular byte mask images, and
- It was converting float mask to scene linear space, which was
resulting in different image than with a byte mask.
Fix those issues by ensuring that all VSE modifiers can take either
byte or float mask as-is, without extra conversions. Previously, some
of the modifiers were done in a way where they only handled "(byte
image + byte mask) or (float image + float mask)" cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/131355
+0.5 should be added to integer pixel coordinate (sampling at pixel
center). This is only really visible in very specific scenarios, but
is more correct.
VSE tonemap is 12-15 times faster.
1) multi-threaded image luminance calculation,
2) avoid calling into OpenColorIO per-pixel, instead do that in
larger batches,
3) for float images (which are primary target for tonemapping),
do not do "to linear space" conversion twice.
Applying tonemap on 4K resolution EXR image, on Ryzen 5950X (Win10/VS2022):
- R/D Photoreceptor mode: 405 -> 31 ms
- Rh Simple mode: 388 -> 23 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127467
When doing average/min/max luminance calculations for tonemapping, ignore
pixels that are outside of the strip rectangle. Due to how VSE innards work,
when a strip is positioned to not cover the whole screen, "the rest" is filled
with transparent black. For tonemapping, this was dragging average calculated
luminance way down.
Images of the issue in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/127207
SEQ_modifier_apply_stack is called from exactly one place, and it always
was throwing away the input image, and taking the newly produced image.
Which means, we can stop copying it. Just run the modifiers on the
input image.
In a test file that is HD (1080p) resolution, two EXR image sequences,
adjustment layer with Color Balance, and a text strip on top,
playback framerate (Ryzen 5950X, Win10/VS2022) goes 20.8 -> 22.1 fps
Pull Request: https://projects.blender.org/blender/blender/pulls/127346
Speedup the Color Balance VSE strip modifier, with two things:
- Generally, use a much lower overhead parallel_for, also with
lower grain size (32 image rows, instead of 64 that were used
before). This is what makes the "float" variant faster.
- For "byte" variant, create a precalculated lookup table instead
of doing all the math per-pixel. This was *almost* done in
existing code, except it was put into the code path that was
never-ever used. However, since this is all done on premultiplied
values, I'm using lookup table size of 1024 instead of 256, so
that semitransparent pixels get some more precision for
"in-between values". This LUT is what results in the main speedup
of "byte" variant.
Calculating Color Balance at 4K resolution, times in milliseconds:
- PC (Ryzen 5950X), PNG (byte): 22.2 -> 2.9 ms, EXR (float): 20.1 -> 15.2 ms
- Mac (M1 Max), PNG (byte): 28.9 -> 7.5 ms, EXR (float): 21.8 -> 8.5 ms
More timing details in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/127121
Skip modifier, when using strip as a mask that ends before specified
timeline frame. To make behavior of missing mask more consistent,
modifier is also skipped, when strip produces blank output due to
missing data.
Skipping modifier due strip boundary only works, when "Mask Time" is set
to Relative mode. This is because absolute mode ignores strip offsets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121498
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
Compositor: Make Hue Correct node wrap
This patch makes the Hue Correct node as well as the Hue Correct VSE
modifiers to wrap, such that no discontinuities occur for the red hue.
Since it now wraps, the default curve preset now exempts the last point
of the curve.
A new CUMA_USE_WRAPPING flag was added to specify wrapping for curve
maps. The implementation works by adding two virtual points before and
after the terminal points in the curve map, such that their handles
match, and would then produce a continues curve.
This is a breaking change, since existing curves were also adjusted
using versioning. However, the change will not be significant, since in
most realistic cases, the terminal points will be close to each other,
and even with wrapping, the connection will be very sharp, almost
matching the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/117114
- enum class StripEarlyOut instead of raw integer defines
- SeqRenderState default initializer instead of seq_render_state_init
- Vector<Sequence*> instead of manually sized arrays of pointers
- some const to several function arguments
Pull Request: https://projects.blender.org/blender/blender/pulls/117829
The sound equalizer is using the Audaspace FFT Convolver.
The blender part creates an array of descriptions of power per "band"
and orders the creation of Equalizer (ISound) in the Audaspace.
Modifier can be created on sound strips. It lets you define
amplification or attenuation over frequency range from 30Hz to 20 kHz.
The power is limited to -30 db - 30 db. This is done using curve
mapping widget.
Co-authored-by: menda <alguien@aqui.es>
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/105613
Previously `SEQ_modifier_list_copy` in append mode does not ensure
unique strip name, which will result in duplicated names in target
modifier list, then `strip_modifier_remove(name="something")` can remove
the wrong one later on. Now fixed using `BLI_uniquename`.
Pull Request: https://projects.blender.org/blender/blender/pulls/111602
The `lib_link` callback cannot always be fully replaced/removed, as in
some case it is also doing some validation checks, or data editing based
on the result of lib_linking internal ID pointers.
The callback has been renamed for that purpose, from `read_lib` to
`read_after_liblink`. It is now called after all ID pointers have been
fully lib-linked for the current ID, but still before the call to
`do_versions_after_linking`.
This change should not have any behavioral effect. Although in theory
the side-effect of this commit (to split lib linking itself, and the
validation/further processing code) into two completely separated steps
could have some effects, in practice none are expected, and tests did
not show any changes in behavior either..
Part of implementing #105134: Removal of readfile's lib_link & expand code.
This fixes a few related issues in VSE code:
* 'lib_link' code was doing 'read_data' tasks (like cleaning up internal
runtime data).
* Handling of `SEQ_TYPE_SOUND_HD` deprecated type of strips was
extremely confusing (versioning done partly in 'lib_link' code, partly
in some 2.50 do_version code).
* Still using deprecated `SEQ_TYPE_SOUND_HD` strip type outside of
versioning code.
* Missing proper usage of deprecated `SEQ_TYPE_SOUND_HD` type inside of
versioning code (!).
Note that the actual conversion from `SEQ_TYPE_SOUND_HD` to
`SEQ_TYPE_SOUND_RAM` is now done in the 'after setup' versioning
process, where it is somewhat safer to add IDs. This implies that
`SEQ_TYPE_SOUND_HD` must be taken into account throughout the whole
regular versioning process (before and after liblink).
Conversion logic itself has been moved to the VSE code.
Pull Request: https://projects.blender.org/blender/blender/pulls/111135
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
