Commit Graph

14 Commits

Author SHA1 Message Date
578f98d7ad Fix T47452: Translate-node seams w/ subpixel offset 2016-02-18 02:16:49 +11:00
e5e73ccc90 Math Lib: rename fill_*, to copy_*
matching convention for fixed length api, eg: copy_v3_fl
2015-05-05 17:08:29 +10:00
225f68c324 Fix interpolation functions ignoring number of components when doing early output 2015-02-24 00:36:33 +05:00
7bb910cd4e Fix T42344: EWA filter produces blured results
Derivatives variable names are swapped in the old EWA filter code,
need to adjust for that.

TODO: Make naming fore clear in there.
2014-10-31 12:35:20 +01:00
4b4ae8374f Cleanup: style 2014-08-20 08:47:32 +10:00
afa3469288 De-duplicate EWA filter code between renderer and compositor
The title says it all, move the EWA filter to BLI (currently it's
math_interp.c) and use the function from both BI renderer and the
compositor.

This makes more central place of the algorithm, allowing to have
fixes and optimizaitons synchronized across the two usages.

This also fixes T41440: Displacement in compositing creates holes

Reviewers: campbellbarton, lukastoenne

Reviewed By: lukastoenne

Maniphest Tasks: T41440

Differential Revision: https://developer.blender.org/D748
2014-08-18 19:38:15 +06:00
07ceb99213 Code Cleanup: use strict flags for math lib, add inline declarations 2013-12-06 03:57:17 +11:00
45fc80153a Fix for interpolation errors on lower-left borders in compositor image
inputs.

http://wiki.blender.org/uploads/4/4c/Compo_image_interpolation_borders.png

Problem is that all image buffer reader nodes (RenderLayer, Image,
MovieClip) were clipping pixel coordinates to 0..N range (N being width
or height respectively). Bilinear interpolation works ok then on the
upper-right borders (x, N) and (N, y), since the last (N-1) pixel fades
out to N (background). But the lower-left (x, 0) and (0, y) borders are
not correctly interpolated because the nodes cut off the negative pixels
before the interpolation function can calculate their value.

To fix this, the interpolation functions are now entirely responsible
for handling "out of range" cases, i.e. setting (0,0,0,0) results for
invalid pixels, while also handling interpolation for borders.
Callers should not do pixel range checks themselves, which also makes
the code simpler. Should not have any real performance penalty,
the interpolation functions do this check anyway, so is probably even
slightly faster.
2013-12-04 12:09:13 +01:00
8beb565c59 code cleanup: headers - doxy comments. 2013-09-12 03:02:50 +00:00
e63ab3505f use math functions rather then macros for bicubic interpolation. 2013-05-25 09:33:08 +00:00
c5c34ca65f Fix #34782: Video Editor - Substract after transform fails
Couple of precision issues here:

- Interpolation was rounding trunkcating colors, and because
  of some precision issues value 254.999 became 254 leading
  to troubles later.

  Now color interpolaiton will do rounding to nearest int.

- Subtract was setting channels to something negative which
  confused color management (especially negative alpha),

  Now subtract effect will clamp channels to 0 from bottom
  and also do some tricks to prevent small alpha which
  could also confuse color management.
2013-03-28 08:21:29 +00:00
5392ff780b Fix #33210: Diffuse Pass in scale node leads to problems
Was own mistake in render layers interpolation changes.
2012-11-17 13:38:39 +00:00
92c8c2ed69 Code de-duplication in imageprocess.c -- made it use interpolation functions from blenlib 2012-11-11 08:48:35 +00:00
f81e30a41f Solved issue with distorted compositor results in some cases
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.
2012-11-10 19:11:25 +00:00