makes it possible to specify an offset relative to the render resolution (so 0.5
is half the image rather than giving the number of pixels). It's a bit late but
it's a trivial change and needed for 4k mango render.
this patch enables the translate node to wrap around the image borders. This is especially needed if the translate node is not used to position elements on a layer but when it is used instead for seamless backgrounds like mountains or clouds that should be repeated over time (by animating the x/y values).
No trunk without docs! So here is my documentation: http://wiki.blender.org/index.php/User:Plasmasolutions/TranslateNodeExtension
The code is properly documented and should be easy to read and understand. When there are any problems or issues, please comment, I'll tackle them right away!
Greetings, Thomas Beck
* optimized determination dependant areas
* fixed some issues with scale node
There are still some issues when scaling very small values (x=0.0001)
- At Mind -
another patch for the dilate/erode step method, still without any functional changes.
This time it keeps the general algorithm but uses the tile system to make it
multithreaded. I could not measure a speedup on my 2-core laptop, but hope that
it will be faster for more cores. The immediate speedup that is very visible though is
that tiles come in as soon as they are calculated and a dilate/erode node does not
block the whole image to be calculated.
till then, David.
this patch optimizes the dilate/erode step method (hopefully without any functional change),
making its speed not depend on the distance anymore.
Couldn't detect funtional changes so committing. Haven't tested for speed gain.
* credits to erwin94 David M
It was caused by image threading safe commit and it was noticeable
only on really multi-core CPU (like dual-socket Xeon stations), was
not visible on core i7 machine.
The reason of slowdown was spinlock around image buffer referencing,
which lead to lots of cores waiting for single core and using image
buffer after it was referenced was not so much longer than doing
reference itself.
The most clear solution here seemed to be introducing Image Pool
which will contain list of loaded and referenced image buffers, so
all threads could skip lock if the pool is used for reading only.
Lock only needed in cases when buffer for requested image user is
missing in the pool. This lock will happen only once per image so
overall amount of locks is much less that it was before.
To operate with pool:
- BKE_image_pool_new() creates new pool
- BKE_image_pool_free() destroys pool and dereferences all image
buffers which were loaded to it
- BKE_image_pool_acquire_ibuf() returns image buffer for given
image and user. Pool could be NULL and in this case fallback to
BKE_image_acquire_ibuf will happen.
This helps to avoid lots to if(poll) checks in image sampling
code.
- BKE_image_pool_release_ibuf releases image buffer. In fact, it
will only do something if pool is NULL, in all other case it'll
equal to DoNothing operation.
- Drawing masks in image editor requires LOCK_DRAW_IMAGE around
ED_space_image_get* functions since they'll acquire image buffer.
Lock is needed because viewers will be modified directly in
compositor (see commend in draw_image_main)
- Seems that was wrong order of invalidating render result and
viewer image invalidation happened in Composite node, which
could easily lead to thread lock.
This codec is absolutely needed to generate DCP using OpenDCP,
before that external application to convert JP2 to J2K was used
which slowed down export a lot.
New codec is exposed to image format settings panel and called
Codec. Default one is JP2 which creates files with .jp2 extension,
new one is called J2K which creates with .j2c extension.
Other changes:
- Fixed avi jpeg warning which was treating as error here.
- Made it so extension is detecting from ImageFormatData instead
of image file type, which makes it possible to have different
extension for the same file type depending on it's settings.
IRIS format should still be changed (depending on number of
channels it'll be .bw, .rgb or .rgba extension)
- Default image format settings would be set from image buffer
when re-saving it. Makes it possible to easily open .j2c file
and save it using J2K codec (without this change it'll save as
.jp2 using JP2 codec)
There was a missing image reload signal in node creation by drag-dropping,
which lead to incorrectly set image type.
Also fixed misusage of IMB_freeImBuf used to release buffer acquired by
BKE_image_acquire_ibuf.
Think should be pretty much harmless since if this node was used for buffers
with infinities it already showed artifacts. Now it should be more useful for
mapping Z buffers.
from main thread using job update callback.
Added new execution-time callback to bNodeTree which marks job to be updated.
The code here could be a bit not so obvious because in some cases job update
callback need to merge local tree, but it's only needed for old compositor
system which is gonna to be removed soon, so decided not to bother with
cleanup now. Removing old compositor system will also allow to drop stats_draw
callback from bNodeTree.
This should fix following bugs:
- 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.
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..
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 :)
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
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 :)
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.
