| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Previously we used to cache a float image representation of the image in
rect_float. This adds some incorrect behavior as many areas only expect
one of these buffers to be used.
This patch stores float buffers inside the image engine. This is done per
instance. In the future we should consider making a global cache.
|
|
In ffmpeg 5.0, several variables were made const to try to prevent bad API usage.
Removed some dead code that wasn't used anymore as well.
Reviewed By: Richard Antalik
Differential Revision: http://developer.blender.org/D14063
|
|
Compatibility with OpenEXR 2 is preserved, since Blender releases and Linux
distribution packages can be on different versions.
Ref D14128
|
|
Function `IMB_indexer_get_seek_pos()` can return non 0 seek position for
frame index 0. This causes seeking to incorrect GOP and scanning ends
with failiure.
Hard-code first frame index seek position to 0.
Differential Revision: https://developer.blender.org/D13974
|
|
Image buffer was visible but buffer wasn't available. In the case
the color only overlay of the render result was displayed the image
buffer was not check to be valid.
This patch adds a null pointer check to check in `IMB_alpha_affects_rgb`
to solve this crash.
|
|
Caused by integer overflow in `steps_per_frame` calculation.
|
|
|
|
This change applies only for automatic proxy building, when strip
is added to timeline. Manual building process is not affected.
Don't build proxy file if movie is already fast enough to seek.
To determine seek performance, check if whole GOP can be decoded
in 100 milliseconds.
To consider some variation in GOP size, large number of packets are
read, assuming that each packet will produce 1 frame. While this is not
technically correct, it does give quite accurate estimate of maximum GOP
size.
This test will ensure consistent performance on wide array of machines.
Check should be done in order of few milliseconds.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11671
|
|
Movies with variable frame rate can cause mismatch of displayed frame
when proxies are used. Since proxies are not used for rendering, this
means, that output may be different than expected. This problem can be
avoided when timecodes are used.
Set used timecode to Record Run. Timecodes are built with proxies at
the same time, therefore if proxies are built and used this will
resolve possible mismatch of output.
Record run is chosen, because it will show frames based on time they
were encoded by encoder and should match behavior as if movie was
played back at normal speed. This change is done only for new strips
in order to not overwrite user defined settings.
Other minor changes:
- When proxies are enabled, size 25% is no longer set by default. It was mostly annoying anyway.
- Silence warning when timecode file is not present. This was introduced in 4adbe31e2fc98f982aed3d97505513750ec348d4.
Previously use of timecodes was hard-coded in sequencer and this error would spam console if timecodes would be
enabled by default and proxies would be never built.
ref: T95093
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13905
|
|
Using a negative linesize to flip an image vertically is supported in
ffmpeg but not for every function.
This method treats frames that need and those that do not need alignment
the same. An RGBA frame buffer with alignment that ffmpeg decides is
optimal for the CPU and build options is allocated by ffmpeg.
The `sws_scale` does the colorspace transformation into this RGBA frame
buffer without flipping. Now the image is upside down and aligned.
The combined unaligning and vertical flipping is then done by
`av_image_copy_to_buffer` which seems to handle negative linesize
correctly.
Reviewed By: ISS
Differential Revision: https://developer.blender.org/D13908
|
|
Includes unwanted changes
This reverts commit 46e049d0ce2bce2f53ddc41a0dbbea2969d00a5d.
|
|
This patch implements the vector types (i.e:`float2`) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the `blender::math` namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
####Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others
we currently don't have (uintX, intX). All these variations were
asking for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector
functions should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the `BLI_(float|double|mpq)(2|3|4).hh` is a
bit of a let down. Most clases are incomplete, out of sync with each
others with different codestyles, and some functions that should be
static are not (i.e: `float3::reflect()`).
####Upsides:
- Still support `.x, .y, .z, .w` for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types
and can be restricted to certain types. Also template specialization
let us define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance
is the same.
####Downsides:
- Might impact debugability. Though I would arge that the bugs are
rarelly caused by the vector class itself (since the operations are
quite trivial) but by the type conversions.
- Might impact compile time. I did not saw a significant impact since
the usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length.
For instance, one can't call `len_squared_v3v3` in
`math::length_squared()` and call it a day.
- Type cast does not work with the template version of the `math::`
vector functions. Meaning you need to manually cast `float *` and
`(float *)[3]` to `float3` for the function calls.
i.e: `math::distance_squared(float3(nearest.co), positions[i]);`
- Some parts might loose in readability:
`float3::dot(v1.normalized(), v2.normalized())`
becoming
`math::dot(math::normalize(v1), math::normalize(v2))`
But I propose, when appropriate, to use
`using namespace blender::math;` on function local or file scope to
increase readability.
`dot(normalize(v1), normalize(v2))`
####Consideration:
- Include back `.length()` method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement. It felt
like too much for what we need and would be difficult to extend / modify
to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches `delaunay_2d.cc` and the intersection code. I would like
to know @howardt opinion on the matter.
- The `noexcept` on the copy constructor of `mpq(2|3)` is being removed.
But according to @JacquesLucke it is not a real problem for now.
I would like to give a huge thanks to @JacquesLucke who helped during this
and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: https://developer.blender.org/D13791
|
|
Reverted because the commit removes a lot of commits.
This reverts commit a2c1c368af48644fa8995ecbe7138cc0d7900c30.
|
|
This patch implements the vector types (i.e:float2) by making heavy
usage of templating. All vector functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
In the ongoing effort to make shaders less GL centric, we are aiming
to share more code between GLSL and C++ to avoid code duplication.
Motivations:
- We are aiming to share UBO and SSBO structures between GLSL and C++.
This means we will use many of the existing vector types and others we
currently don't have (uintX, intX). All these variations were asking
for many more code duplication.
- Deduplicate existing code which is duplicated for each vector size.
- We also want to share small functions. Which means that vector functions
should be static and not in the class namespace.
- Reduce friction to use these types in new projects due to their
incompleteness.
- The current state of the BLI_(float|double|mpq)(2|3|4).hh is a bit of a
let down. Most clases are incomplete, out of sync with each others with
different codestyles, and some functions that should be static are not
(i.e: float3::reflect()).
Upsides:
- Still support .x, .y, .z, .w for readability.
- Compact, readable and easilly extendable.
- All of the vector functions are available for all the vectors types and
can be restricted to certain types. Also template specialization let us
define exception for special class (like mpq).
- With optimization ON, the compiler unroll the loops and performance is
the same.
Downsides:
- Might impact debugability. Though I would arge that the bugs are rarelly
caused by the vector class itself (since the operations are quite trivial)
but by the type conversions.
- Might impact compile time. I did not saw a significant impact since the
usage is not really widespread.
- Functions needs to be rewritten to support arbitrary vector length. For
instance, one can't call len_squared_v3v3 in math::length_squared() and
call it a day.
- Type cast does not work with the template version of the math:: vector
functions. Meaning you need to manually cast float * and (float *)[3] to
float3 for the function calls.
i.e: math::distance_squared(float3(nearest.co), positions[i]);
- Some parts might loose in readability:
float3::dot(v1.normalized(), v2.normalized())
becoming
math::dot(math::normalize(v1), math::normalize(v2))
But I propose, when appropriate, to use
using namespace blender::math; on function local or file scope to
increase readability. dot(normalize(v1), normalize(v2))
Consideration:
- Include back .length() method. It is quite handy and is more C++
oriented.
- I considered the GLM library as a candidate for replacement.
It felt like too much for what we need and would be difficult to
extend / modify to our needs.
- I used Macros to reduce code in operators declaration and potential
copy paste bugs. This could reduce debugability and could be reverted.
- This touches delaunay_2d.cc and the intersection code. I would like to
know @Howard Trickey (howardt) opinion on the matter.
- The noexcept on the copy constructor of mpq(2|3) is being removed.
But according to @Jacques Lucke (JacquesLucke) it is not a real problem
for now.
I would like to give a huge thanks to @Jacques Lucke (JacquesLucke) who
helped during this and pushed me to reduce the duplication further.
Reviewed By: brecht, sergey, JacquesLucke
Differential Revision: http://developer.blender.org/D13791
|
|
|
|
The direct cause of the bug in question was passing in the raw memory
buffer to sscanf. It should be called with a null-terminated buffer;
which isn't guaranteed when blindly trusting the file data.
When attempting to fuzz this code path, a variety of other crashes were
discovered and fixed.
Differential Revision: https://developer.blender.org/D11952
|
|
|
|
Was not actually flipping in the need_aligned_ffmpeg_buffer case.
|
|
Harden bounds check in the stream reader avoiding integer overflow.
|
|
Add a data boundary check in the flipping code.
This code now also communicates the number of mipmap levels
it processed with an intent to avoid GPU texture from using
more levels than there are in the DDS data.
Differential Revision: https://developer.blender.org/D13755
|
|
Fix IMB_flip[xy] to handle cases where integer overflow might occur when
given sufficiently large image dimensions.
All of these fixes were of a similar class where the intermediate
sub-expression would overflow silently. Widen the types as necessary.
Differential Revision: https://developer.blender.org/D13744
|
|
MSVC used to warn about const mismatch for arguments passed by value.
Remove these as newer versions of MSVC no longer show this warning.
|
|
|
|
API added in rBa3ad5abf2fe85d623f9e78fefc34e27bdc14632e
|
|
|
|
|
|
|
|
|
|
|
|
Added support for 1, 2, 3 float channel source images. Destination
images must still be 4 channels.
|
|
Renamed or removed parameters which no longer exist.
|
|
Also add groups in some files.
|
|
|
|
This reverts commit 943aed0de35621e328 and f76e04bf4d7cdce8
The latter caused a test failure: `sequencer_render_transform`
Reverting since the fix is not obvious (to me), and people are
away for the weekend.
|
|
Improvement of the IMB_transform function by separating the UVWrapping
method from the color interpolation function. This would allow us to
perform uv wrapping operations separate from the interpolation function.
Currently this wrapping is only supported when interpolating colors.
This change would allow us to perform it on non-color image buffers.
|
|
|
|
Reduce the inner loop of IMB_transform by extracting writing to an
output buffer in a template. This reduces a branch in the inner loop and
would allow different number of channels in the future.
|
|
Use IMB_get_rect_len to solve overflow issues.
|
|
|
|
When loading huge images (30k) blender crashed with a buffer overflow.
The reason is that determine the length of a buffer was done in 32bit
precision and afterwards stored in 64 bit precision.
This patch adds a new function to do the correct calculation in 64bit.
It should be added to other sections in blender as well. But that should
be tested on a per case situation.
|
|
|
|
Ref T92709
|
|
This change uses generics to reduce code duplication an increases
flexibility and performance. Performance increase isn't measurable
for end users.
|
|
Part of a refactoring to make IMB_transform more generic to reduce
unneeded branching.
|
|
`IMB_transform` is used in VSE. It had a required crop parameter
for cropping the source buffer. This is not always needed.
In the image engine we want to use the use the `IMB_transform`
with wrap repeat. Both options are mutual exclusive and due
to performance reasons the wrap repeat is only available when
performing a nearest interpolation.
|
|
Affect and effect are too confusing for non-native english speakers
(like me). Also BAKING_MASK_MARGIN doesn't exist anymore in the code.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13361
|
|
`IMB_moviecache` is implemented as a singleton. When destructing the
singleton via `IMB_moviecache_destruct` it will not be created anymore
resulting inusage of unallocated memory and potentional memory
corruption.
When running blender this doesn't happen, but when creating images in
test cases the moviecache should be able to be recreated after it is
destroyed.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D13287
|
|
Contributed by luzpaz.
Differential Revision: https://developer.blender.org/D13264
|
|
When scaling down image, users expect to see background, which doesn't
currently happen in VSE. This is because strips use cross blend mode by
default, because alpha over is much slower. Reason is, because any area
of image can be transparent, and therefore it can't have early out
implemented in a way that cross blend mode can.
Flag images rendered by codecs that don't support transparency as fully
opaque and implement a form of early out for alpha over blend mode.
When rendering image stack, 2-input effects are ignored on the
"way down". Alpha over needs rendered overlay image to decide whether it
will use only overlay or background too. Therefore overlay can be
rendered safely before it is used. Image flags can be checked and it can
be freed if needed. Freeing doesn't cause any performance degradation,
because image is always stored in cache.
This feature does not improve blend mode performance. In summary, it
only allowes for having alpha over blend mode on background images
without suffering from lower performance.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D12914
|
