Quote:
Originally Posted by SilaSurfer
So Fluxsmooth should be tweaked to get stronger effect
|
Maybe yes, maybe no. Read on.
Quote:
|
if so are those sideaffects of shading going to be more amplified if I do so?
|
Definetly yes. If FluxSmooth is set up more aggressively (i.e. bigger threshold), then it'll do more good where Flux is doing right, and will do more bad where Flux is doing wrong.
Remember FluxSmooth is a simple temporal smoother with median-like decision where to filter and where not.
Examples:
a) a pixel sequence: ... 80 81 85 79 80 ...
Flux will filter the "85" and the "79", because these two pixels are overshooting both of their neighbors.
b) pixel sequence: ... 80 81 85 85 81 80
Flux will filter *nothing*, because no pixel satisfies the "overshooting both neighbors" criteria.
For case b), this means:
- IF those two "85" are due to motion, then Flux has done correct.
- But IF those two "85" in fact are related to "flicker" in a "flat" a/o "static" area, then Flux has not filtered something that you would like to have filtered.
Truth is, this kind of "flickering of low spatial frequencies" is one of the ultimate foes, because right here it is where the nebula-of-uncertainty becomes thick:
a) without mocomp, you can't know if it's flicker or motion
b) with mocomp, you can't know if the mocomp has been misleaded by the flicker
c) With prefiltering before mosearch, you can't know if the prefilter has mangled moving areas (because of a)) and conseqquentially has misleaded the mosearch
Chicken-and-egg problem, without any definite solution.