| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- FastGaussianBlurValueOperation is a value operation, so use only first vector
component in initializeTileData.
- Gamma correct/uncorrect operations didn't set alpha for output which lead to
usage of uninitialzied memory further in nodes graph.
|
|
Own mistake in image threading commit.
|
|
Gamma correction option was ignored by new compositor system.
Also new compositor was doing alpha premul in a wrong way. In fact,
not sure if it should do premul -- old compositor didn't do that..
|
|
also add UNPACK macros's. handy for printing vectors for eg.
|
|
This commit makes BKE_image_acquire_ibuf referencing result, which means once
some area requested for image buffer, it'll be guaranteed this buffer wouldn't
be freed by image signal.
To de-reference buffer BKE_image_release_ibuf should now always be used.
To make referencing working correct we can not rely on result of
image_get_ibuf_threadsafe called outside from thread lock. This is so because
we need to guarantee getting image buffer from list of loaded buffers and it's
referencing happens atomic. Without lock here it is possible that between call
of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would
be called. Image signal handling too is blocking now to prevent such a
situation.
Threads are locking by spinlock, which are faster than mutexes. There were some
slowdown reports in the past about render slowdown when using OSX on Xeon CPU.
It shouldn't happen with spin locks, but more tests on different hardware would
be really welcome. So far can not see speed regressions on own computers.
This commit also removes BKE_image_get_ibuf, because it was not so intuitive
when get_ibuf and acquire_ibuf should be used.
Thanks to Ton and Brecht for discussion/review :)
|
|
presence of markers still hangs.
also compiler warnings and some style edits.
|
|
(useful for flipping the values inside the node)
|
|
this node allows for more control for normalization of the mapped input range.
Made during BlenderPRO 2012 - Brasilia, Brazil :)
Idea and testing: Daniel Salazar
Implementation: yours truly
Reviewed by Lukas Toenne and Sergey Sharybin
|
|
also initialize bmesh-bevel settings struct to zero to avoid possible uninitialized memory later.
|
|
from blenlib
|
|
It wasn't used and it was incorrect anyway (distortion could be more than 100px).
|
|
Originally issue was discovered when using stabilization and movie distortion
nodes, but in fact issue was caused by render layer node always doing nearest
interpolation. Now made it so this node will respect sampler passed to it's
executePixel function and do an interpolation.
Added two new functions to do bilinear/bicubic interpolation in float buffer
with variable number of components per element, so it could interpolate 1, 3
and 4 component vectors. This functions currently mostly duplicates the same
functions from imageprocess.c and it should actually be de-duplicated. Think
it's ok to leave a bit of time with such duplication, since functions should
be generalized one more time to support byte buffers, which could backfire on
readability.
Also removed mark as complex from stabilization node, which isn't needed sine
int fact this node is not complex.
|
|
- Somehow this node was using nearest interpolation which seems have been
passed from compositor node. It was using b-spline interpolation with
old compositor implementation. Now forced this node to use bilinear
interpolation, which should be close enough.
- Operation should be marked as complex it seems, otherwise area of
interest wouldn't make any affect on it's behavior.
|
|
|
|
This is probably versioning issue happened when both trunk and tomato
were mixed to work on the same file.
Anyway, there're few files here locally and it's probably other users
do have the same files, so lets keep things safe here :)
|
|
unused vars.
|
|
|
|
|
|
the top right.
|
|
|
|
|
|
|
|
code
|
|
|
|
it is expected.
Fix for [#32955] Compositer "Crop" node option "Crop Image Size" doesn't
really crop the input image
|
|
This makes it possible to create pixelized scale in the Tile compositor.
Just append the node in front of a scale node or where you want the pixelization to take place.
There were some bugs on this subject, but they used the work around to add a blur size of 0 in the place where they need the pixelization.
|
|
axis_dominant_v3(). also add min_axis_v3().
|
|
|
|
also fix minor error in MOD decimate when the modifier did nothing the reported face count would be wrong.
|
|
- minf, maxf, mini, maxi --> min_ff, max_ff, min_ii, max_ii
|
|
Patch done by Markus Kasten
Thanks for that!
|
|
also left bmesh decimator on in previous commit.
|
|
|
|
|
|
|
|
Just makes progressive refine :)
This means the whole image would be refined gradually using as much
threads as it's set in performance settings. Having enough tiles is
required to have this option working as it's expected.
Technically it's implemented by repeatedly computing next sample for
all the tiles before switching to next sample.
This works around 7-12% slower than regular tile-based rendering, so
use this option only if you really need it.
This commit also fixes progressive update of image when Save Buffers
option is enabled.
And one more thing this commit fixes is handling display buffer with
Save Buffers option enabled. If this option is enabled image buffer
wouldn't have neither byte nor float buffer until image is fully
rendered which could backfire in missing image while rendering in
cases color management cache became full.
This issue solved by allocating byte buffer for image buffer from
tile update callback.
Patch was reviewed by Brecht. He also made some minor edits to
original version to patch. Thanks, man!
|
|
|
|
|
|
|
|
invalid memory access when freeing the blend file.
|
|
the wrapping was resized to fit the uv map. this step was wrong and has
been deleted.
|
|
the alpha mix formula was wrong. updated it.
Be aware that the regression file does not take the alpha into account,
but it should. or at least one z combine should and the other not.
this fails in 2.63a.
- At Mind -
|
|
Seems to be a regression in new compositor system -- wrong number of planes
was using for image buffer allocation.
|
|
|
|
|
|
Color management would be applied on both of float and byte buffers on image
save in cases if file format doesn't require linear float buffer and if image
is saving as render result.
This solves both initial report issue and TODO marked in previous fix.
Also de-duplicated image buffer color managing code and gave some more
meaningful names for few functions. Also wrote documentation around this
function, so current assumptions about spaces should be clear enough.
Made regression tests by saving EXR/PNG images to all supported format and
rendering OpenGL/Normal animation, in all cases seems everything is fine,
but more tests for sure would be welcome.
|
|
|
|
or good to keep for completeness. quieted some warnings and add flags -Wmissing-include-dirs and -Wno-div-by-zero to cmake/gcc
|
|
|
