EXR DWAA and DWAB are conceptually similar to lossy JPG compression,
with a tunable file size vs image quality parameter. However, previously
Blender always used the fixed default setting, which is kinda similar
to very high quality (like 97) for JPG.
Internally EXR DWA/DWB quality parameter is inverted scale, i.e. 0 is
best/lossless quality, and increased setting value means decreased
quality. However the rest of Blender UI uses 1-100 JPG-like quality
scale, where values above 90 are "visually lossless", 100 is lossless,
and going below something like 50 would be visually quite lossy. So map
that to internal DWA setting:
- blender 100 -> DWA 0
- blender 97 -> DWA 45
The rest is linear relation based on those two points.
Pull Request: https://projects.blender.org/blender/blender/pulls/128790
IMB_scale modifies the input image. But some places in code needed to keep
original input intact, so what they did was a sequence of IMB_dupImBuf+IMB_scale
Add IMB_scale_into_new function and use that in several obvious places:
- movieclip_build_proxy_ibuf
- icon_copy_rect
- seq_proxy_build_frame
Rebuilding proxies for VSE image sequences with 94 4K resolution EXR images
(on Ryzen 5950X/Win10/VS2022): 13.4 -> 10.3 seconds.
Pull Request: https://projects.blender.org/blender/blender/pulls/128752
Previous fix (b17734598d) tried to fix this, but it seems that
depending on CPU and video width, ffmpeg might need at least 64
byte alignment, even if CPU we're running on is only AVX2 (32 byte
alignment). That is because some other parts of ffmpeg code
statically pick 64 or 32 byte alignment internally, depending on whether
AVX512 support is even compiled in (even if CPU might not have it).
I have checked whether this does not negatively affect a platform where
SIMD alignment is always 16 (Mac), and it does not, everything works as
expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/128107
This is not an officially supported platform, but it was working before
so might as well keep it up to date.
* Tweak logic for various BLENDER_PLATFORM_ARM checks
* Use linux_arm64 name for folders, matching Windows and macOS
* CUDA is enabled, SYCL and HIP are not
* Tested to work on Rocky Linux 8
When building proxies at lower than 100% resolution, the video frame
downscaling step was single threaded, as found via #127956.
Make it use the same threaded sws_scale machinery that the usual video
decoding/encoding uses. Video encoding/decoding was only using it for
RGB<->YUV conversions, so source and destination sizes were always matching;
here it needs to have different source and destination sizes though.
Time taken to rebuild 50% proxy for a 4K resolution 1440 frames (1 minute)
long video file, on Ryzen 5950X (Win10/VS2022):
- Blender 4.2: 20.1 sec, CPU usage 30-40%.
- Blender 4.3 main: 13.1 sec (ffmpeg build has been fixed to use SIMD),
CPU usage still 30-40% though.
- This PR: 8.3 sec, CPU usage ~95%.
Pull Request: https://projects.blender.org/blender/blender/pulls/128054
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
Looks like ffmpeg AVFrame width/height/format for the deinterlaced frame
was never initialized. That was not a problem until starting with 4.1
the colorspace conversion and upside down flip was started to be
multi-threaded, which accessed the frame width/height.
Also, the memory storage for the deinterlaced frame was never freed
either; fix that too.
Pull Request: https://projects.blender.org/blender/blender/pulls/127689
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.
When loading an EXR image, first we were allocating memory for it,
then clearing it to zero, then using OpenEXR to load the data. But
the process of loading will overwrite all the pixel values anyway,
so it is pointless to do the first clear.
On a test VSE file that has two 1920x1080 EXR image sequences blended
together, plus some color correction on top, playback framerate of it:
- PC: 12.6 -> 13.2 FPS (Ryzen 5950X, RAM bandwidth ~32GB/s)
- Mac: 27.3 -> 29.5 FPS (M1 Max, RAM bandwidth ~400GB/s)
Pull Request: https://projects.blender.org/blender/blender/pulls/127427
Image/movie strip controls color controls: "Saturation" and "Multiply" were
both single-threaded code. Multi-thread both of them. Timings to apply them
on a 4K resolution byte image, on Ryzen 5950X (Win10/VS2022):
- Saturation: 97ms -> 6.3ms
- Multiply: 11.5ms -> 1.1ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127409
IMB_buffer_byte_from_float for "predivide" case was doing two function
calls per pixel. Make it do the work with one function per pixel.
Do the same in IMB_buffer_byte_from_float_mask.
IMB_buffer_byte_from_float on one thread, running on 4K resolution
image, on Ryzen 5950X (Win10/VS2022): 27.4ms -> 24.4ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127308
In VSE, the default setting is that even float images are all in sRGB
(or rather, display) space. However code that was drawing the final
VSE float image on screen, was first converting it to linear space,
and then back to display space.
An optimization already existed that skipped "no-op" conversions for
byte images. This adds a similar case for float images.
Note: I found a previous fix to an old issue (#39953, commit fe29f92030)
in related code. Probably should be double checked whether it has not
regressed.
VSE at 4K resolution, with a single 4K resolution EXR image strip,
playback on Ryzen5950X (Win10/VS2022):
- Playback average FPS 11 -> 18
- Time for sequencer_preview_region_draw part: 92ms -> 58ms
- Time for sequencer_draw_display_buffer in there: 52ms -> 15ms
Pull Request: https://projects.blender.org/blender/blender/pulls/127305
Original code was quite unorganized and not as easy to read through.
There were basically 3 code paths:
1. Division of `AVStream` duration by its timebase
2. Division of `AVFormatContext` duration by its timebase, with possible
AV offset compensation
3. Simply using frame count from `AVStream`
Finally there was possibility of ending up with duration of 0 in
specific case where `pFormatCtx->duration == AV_NOPTS_VALUE`, but I did
not find any test case for this (Added in aebb32748e).
During investigation for PR #126866, I have concluded, that before
commit 8903205dd9, the code which compared duration of stream and
container was incorrectly always true. But it resulted in correct
behavior for about 4 years. Code was reorganized with that assumption,
so above listed code paths are in order of possible execution. Exception
is code path 3, which is run first, but it's result is pretty much always
discarded.
Since all these workarounds are added around code path 3, it is safe
to assume, that it is least precise, so it should be considered last.
Pull Request: https://projects.blender.org/blender/blender/pulls/127010
Commit 8903205dd9 fixed incorrect math, in stream length setting part of
the code, which seemed to force most video files to use safer, but more
complicated codepath.
Even though the math was corrected, the logic was not great. It tried to
use container duration, only stream duration is not significantly (4x!)
longer. This is quite crude.
Instead, check if there is any significant difference between stream and
container durations. The threshold is kept quite high, just to be safe.
This code should be removed in futute cleanup / refactoring.
Pull Request: https://projects.blender.org/blender/blender/pulls/126866
Regression is caused by movie being rendered twice for the same frame
number, but the image is not cached after 5ecb70964e.
The image is rendered first to determine `early_out` in
`seq_render_strip_stack()`, then for the actual image output.
Since VSE cache is not to be used for render job, `ffmpeg_fetchibuf()`
can be optimized to return frame, which is already decoded instead of
re-seeking to last keyframe and decoding all following frames again.
Pull Request: https://projects.blender.org/blender/blender/pulls/126911
Implementing part of design outlined in #126087.
- VSE thumbnail cache has a new implementation, hopefully simpler
and easier to understand.
- Instead of cache key being a VSE strip, frame index, plus
complicated logic for cache items linking etc.,
- The cache is keyed by media file path (if multiple strips
use the same input file, they will share cache entries), frame
index within media file, and any extra data (e.g. steam index
for multi-steam videos)
- Much reduced cache flickering and strange/weird thumbnail choices.
- Likewise, thumbnails no longer disappear-and-reload on operations
like Undo, dragging new video strip into timeline, or F12 render.
- Thumbnails now load faster.
- Images use dedicated/faster thumbnail loading routines when a
format can do that (e.g. JPG and EXR can).
- Movies reuse ffmpeg decoding context for neighboring strips
that use the same file (as often happens when cutting footage)
- Thumbnail requests are processed on several threads now too.
Images and more detail in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126405
Just-introduced in #126390, when source image size is just two pixels
it should not advance to the third pixel after reading the first two.
Was pointed out by randomly failing tests, yay tests.
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
71f2229b0 added a workaround for video files that contain entirely
incorrect stream duration, and corrects that by using container
duration instead. However it used math of `seconds=frames*rate` instead
`seconds=frames/rate`, effectively always ending up falling back to
container instead of stream duration.
Pull Request: https://projects.blender.org/blender/blender/pulls/126368
Technically the regression was caused by #124472 which made it so
duplicating ImBuf allocates the exact amount of memory needed to
hold the pixels, while before IMB_dupImBuf() would leave the float
buffer over-allocated for images that are less than 4 channels per
pixel.
At the same time IMB_scalefastImBuf() was hard-coded to use 4
channels per pixels, for both byte and float buffers. It did not
crash in Blender 4.1 as it was accessing memory that is over-allocated,
but it also did not generate proper preview.
This fix makes the IMB_scalefastImBuf() to operate on an arbitrary
number of channels in the float buffer.
Pull Request: https://projects.blender.org/blender/blender/pulls/126234
The newly added viewport compositor was missing a try-catch guard around
the OCIO `getProcessor` call. All prior call sites were protected except
this one. Unhandled exceptions can occur if the user tries to use a
colorspace config that is not present in their OCIO configuration.
The surrounding code paths need some work in order to not crash at a
later point, which would also impact builds with no OCIO support at all.
In the case of no OCIO support at all, a warning label is placed on the
node as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/125526
When a video width is a multiple of 8 but not 16 (i.e. line size
stride of RGBA frame is multiple of 32 bytes but not 64 bytes), then
on an AVX512 capable CPU the decoded video has a block of "wrapped"
artifacts on the left side.
This started happening in 4.1 with 4ef5d9f60f, where the vertical flip
is done together with YUV->RGB conversion. The logic in there checks
whether ffmpeg frame line size (which might include necessary SIMD
alignment/padding) matches packed imbuf line stride. However, ffmpeg
arguably has a bug, where `av_frame_get_buffer` always uses 32 byte
alignment, instead of 64 byte when on AVX512 code path. Report
has been made to ffmpeg upstream: https://trac.ffmpeg.org/ticket/11116
and in the meantime, explicitly pass `av_cpu_max_align` to
`av_frame_get_buffer`.
Pull Request: https://projects.blender.org/blender/blender/pulls/125578
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
This adds a new mode to the Color Balance node, which applies a white point
transformation similar to the one applied in the view transform.
Unlike the view transform, the compositor node allows specifying both the
source and the destination white point for more flexibility. Both default
to the D65 white point, so just leaving the destination alone achieves the
same behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/124110
While investigating #124217 it was noticed that sometimes a >4 channel
ImBuf might be passed through to this api.
This would cause memory to be overwritten because the destination ImBuf
was created with only 4 channels of memory. Now we create it with the
proper number of channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/124472
Caused by a060e96103
This change restores the old behavior of pass name detection from
channel name prior to the offending commit.
The fix includes regression test based on the files from related
reports, to help catching possible issues in the future.
Being so close to the release this commit restored behavior prior
to the previous fix. Potentially this makes some files to detect
wrong pass name for some specific files, although it is not really
clear if such files exists in the wild.
Pull Request: https://projects.blender.org/blender/blender/pulls/124458
Handle missing font in the hover tooltip preview in the Data-block ID
selector. Add error handing both in IMB_font_preview itself and in the
current caller (to show message).
Pull Request: https://projects.blender.org/blender/blender/pulls/124111
This implements a von-Kries-style chromatic adaption using the Bradford matrix.
The adaption is performed in scene linear space in the OCIO GLSL shader, with
the matrix being computed on the host.
The parameters specify the white point of the input, which is to be mapped to
the white point of the scene linear space. The main parameter is temperature,
specified in Kelvin, which defines the blackbody spectrum that is used as the
input white point. Additionally, a tint parameter can be used to shift the
white point away from pure blackbody spectra (e.g. to match a D illuminant).
The defaults are set to match D65 so there is no immediate color shift when
enabling the option. Tint = 10 is needed since the D-series illuminants aren't
perfect blackbody emitters.
As an alternative to manually specifying the values, there's also a color
picker. When a color is selected, temperature and tint are set such that this
color ends up being balanced to white.
This only works if the color is close enough to a blackbody emitter -
specifically, for tint values within +-150. Beyond this, there can be ambiguity
in the representation.
Currently, in this case, the input is just ignored and temperature/tint aren't
changed. Ideally, we'd eventually give UI feedback for this.
Presets are supported, and all the CIE standard illuminants are included.
One part that I'm not quite happy with is that the tint parameter starts to
give weird results at moderate values when the temperature is low.
The reason for this can be seen here:
https://commons.wikimedia.org/wiki/File:Planckian-locus.png
Tint is moving along the isotherm lines (with the plot corresponding to +-150),
but below 4000K some of that range is outside of the gamut. Not much can
be done there, other than possibly clipping those values...
Adding support for this to the compositor should be quite easy and is planned
as a next step.
Pull Request: https://projects.blender.org/blender/blender/pulls/123278
The issue is a combination of following aspects:
- Missing null-pointer check in the image operation, which is probably
why the result was buggy. It is addressed by #123493.
- In certain conditions loading image was wrongfully failing.
The reason for failing to read image were items with a null-pointer
image buffer left by the cache limit enforcer, which was considered
to be an indication of failed load from disk. The reason why the cache
limiter leaves items with null-ptr as an image buffer is kind of a
legacy limitation which was never resolved. Long story short: the
system expects put() to be called on the cache to clear its empty
items.
To solve the original issue of files considered to be unreadable
only set the cache-empty if the image buffer was added empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/123496
