Remove options that are duplicate and change description of options, so
they describe bit better, how timecodes are actually used.
Timecodes in Blender have pretty much nothing in common with more widely
known term "timecode". This confused users (and developers).
There were 5 options of which 3 were exactly same. This commit leaves
user with 3 options:
- Use timecodes for normal seeking/playback - Record Run
- Ensure, that no frame is duplicated or skipped - "Record Run No Gaps"
- Do not use timecodes - "None"
More verbose description was added to the definition in code.
Naming of these timecode types was kept, even if it is incorrect to not
break scripts and habits.
Pull Request: https://projects.blender.org/blender/blender/pulls/121001
The File Output node produces wrong output when the output is set to BW.
This is because the image saving logic assumes float buffers always have
4 channels and ignores the image buffer channels member. So for single
channel images, the code weighted sum neighbouring pixels and asigned
them as a single pixel, producing bleeding at best and crashes at worst.
To fix this, we skip Color to BW conversion if the image is already BW.
And, we fix the functions that assume 4 channels for float buffers.
Pull Request: https://projects.blender.org/blender/blender/pulls/120206
It is not immediately clear why DDS compressed (DXT/S3TC) textures need
to be power of two in size (since nothing in DXT/S3TC intrinsically
requires that). It is only needed due to the "flip the texture upside
down" dance that we do for DDS at load time.
While at it, when logging DXT related messages, tell which texture
was it for, and dimensions. This changes logs like:
```
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed.
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed.
Unable to find a suitable DXT compression, falling back to uncompressed.
```
Into:
```
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed (281splash-dxt1-mips.dds, 890x501).
Unable to load non-power-of-two DXT image resolution, falling back to uncompressed (281splash-dxt5-mips.dds, 890x501).
Unable to find a suitable DXT compression, falling back to uncompressed (281splash-rgba8-mips.dds, 890x501).
```
Pull Request: https://projects.blender.org/blender/blender/pulls/120210
Large int64_t values were calculated and assigned int however the
calculation was performed on integer types which would truncate the
result before casting to an in64_t.
There are still a few places that are more complicated where the replacement
to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly
`IDPropertyTemplate` usage.
This patch unifies the sRGB to Linear color space conversion between the
CPU and GPU compositors. This is because CPU uses an optimized path that
produces values that are very slightly off. To fix this, for the GPU, we
do the conversion CPU side instead of doing it in a shader. Since images
are cached, the performance implications are not significant.
Another added benefit is that we no longer get differences due to the
order of alpha pre-multiplication and sRGB conversion, demonstrated in
#114305. And we no longer require any preprocessing of the images.
This patch adds some new utilities to the Image Buffer module to assign
float, byte, and compressed buffers along with their color spaces. It
also adds an ownership flag to compressed data. Those were added as a
way to facilitate the implementation.
Pull Request: https://projects.blender.org/blender/blender/pulls/118624
This patch adds clamped boundaries variants of the nearest interpolation
functions in the BLI module. The naming convention used by the bilinear
functions were followed.
Needed by #119414.
Pull Request: https://projects.blender.org/blender/blender/pulls/119732
Add a null pointer check around CPU processor, matching the rest of the
processor access.
This solves crash in cases when the OCIO configuration exists but is
invalid: i.e. by removing a lookup table. It could lead to an invalid
render result, but is better than a crash.
The original issue with running Blender from within .zip archive might
still need investigation, as there might be a way to make it work.
Pull Request: https://projects.blender.org/blender/blender/pulls/119693
The IMB_dupImBuf() function does not copy the GPU texture as it might
not be possible if the GPU context is not active, but it also was not
clearing the pointer in the result ImBuf. This could potentially lead
to situation when the texture gets freed via IMB_freeImBuf of either
original or copied image buffer, leaving the other pointing to a freed
GPU texture.
It is not known whether it ever was an actual problem for artists,
but it is nice to avoid such possibility.
Pull Request: https://projects.blender.org/blender/blender/pulls/119469
* If required roles are not found, refuse to load the config
* Use "default" role as fallback for all roles, following the
OpenColorIO docs.
* Use bundled config if loading environment config fails,
instead using very limited fallback config.
* Fix OCIO_exit get called on failed config load, causing
crash when trying to load the next config.
Pull Request: https://projects.blender.org/blender/blender/pulls/119435
"Own" (the adjective) cannot be used on its own. It should be combined
with something like "its own", "our own", "her own", or "the object's own".
It also isn't used separately to mean something like "separate".
Also, "its own" is correct instead of "it's own" which is a misues of the verb.
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
When starting to play back a movie strip, there was a "oh, let's figure out if
this is a video file?" check, immediately followed by "let's initialize the
machinery to decode a video file". The first one is kinda redundant, since if
it will happen to not be a video file, the latter check will nicely fail.
Addressed that by removing (seemingly unused at all?) functionality from
`ImBufAnim`, now it is only used for video file playback. Details:
- It looks like `ImBufAnim` is only ever used to play back "video files", so
remove all the other modes of operation from it ("image sequence").
- Which makes `ImBufAnim::curtype` be not needed, it only needs to store state
of whether it's initialized already.
- Which means there's no need to call `imb_get_anim_type` (which does very
costly `isffmpeg`) when starting to play ImBufAnim.
- Remove some other variables from `ImBufAnim` that were just flat out unused.
In Gold previs playback between 1:41-1:55, on Windows/Ryzen5950X:
- Slowest 3 frames went from 276, 195, 168ms -> 222, 174, 147ms (saves 20+ ms
per frame). All of these frames are camera cuts where multiple new video
clips start playing.
- In the whole playback, total amount of time taken by `imb_get_anim_type`:
234ms -> zero! Since that is no longer used.
- There are still stalls when starting to play a movie clip, and that is
actually initializing ffmpeg things. But now at least right before
"initialize ffmpeg" there's no additional redundant work.
Pull Request: https://projects.blender.org/blender/blender/pulls/118503
IMB_double_x, IMB_double_y, IMB_double_fast_x, IMB_double_fast_y,
imb_filterx are not used by anything. Looks like they all come
from "initial revision, 22 years ago" and probably unused for decades.
Blender had a very limited (only uncompressed or MJPEG frames) .avi file
support, for both reading and writing. This is something that ffmpeg can
fully do.
This removes all of that. 3500 lines of code gone, primary motivations being:
- ffmpeg can read and write .avi files just fine, including ones with
uncompressed or MJPEG frames.
- Blender's ffmpeg integration could also be taught to produce uncompressed or
MJPEG .avi files, but TBH I don't see a particular reason to do that. Modern
formats like H264 are better in every way, and already support "lossless"
option if needed.
- The "Lite" blender build configuration was excluding both ffmpeg and avi
anyway, so that config is something that can't read nor write any movies.
User visible changes:
- In scene image output type, under Video section now there's only Ffmpeg Video
(AVI Raw and AVI JPEG are gone)
- Whenever loading an existing file, if output was one of AVI Raw / AVI JPEG,
it is set to Ffmpeg Video.
Pull Request: https://projects.blender.org/blender/blender/pulls/118409
