还是会慢的,因为若是跳帧处理,则输出帧=处理帧<输入帧NAVras 写了:过完BM3D再select every输出?Echo 写了: 这样处理的好处是,可以利用100帧的信息;
对于需要帧间关系来完成的处理更为有益。
速度应该不会变慢
可能只能牺牲速度,先全处理,再选择输出帧
还是会慢的,因为若是跳帧处理,则输出帧=处理帧<输入帧NAVras 写了:过完BM3D再select every输出?Echo 写了: 这样处理的好处是,可以利用100帧的信息;
对于需要帧间关系来完成的处理更为有益。
速度应该不会变慢
首先你用的是BM3D还是V-BM3D(在mvf.BM3D里是radius0>0),前者是纯intra处理,在之前或之后SelectEvery都没有区别。Echo 写了:这样处理的好处是,可以利用100帧的信息;vempx 写了: 不是很懂你的思考逻辑……
你这个需求,先在VS里面用内置滤镜把100帧变成50
然后再把这50帧全部送给BM3D处理输出不就行了?
对于需要帧间关系来完成的处理更为有益。
V-BM3D√mawen1250 写了: 首先你用的是BM3D还是V-BM3D(在mvf.BM3D里是radius0>0),前者是纯intra处理,在之前或之后SelectEvery都没有区别。
如果是V-BM3D,那么就在之后SelectEvery,至于哪些帧会被处理,则是由每个滤镜对帧的请求逻辑决定的,不需要你自己管。
——实际上由于Collaborative Filter的特点,当select 1/2帧时,只有最后一个bm3d.VAggregate不会被请求所有帧,而之前的主要部分(VBasic、VFinal),所有帧都会被请求(因为radius=1时,bm3d.VAggregate每一帧的结果由前后共三帧来决定),所以理论上速度和是否SelectEvery都不会有多大区别。
转444后处理确实仍然非常干净,,但好奇还想问下 如果用havsfunc里对knlmeans的方法到BM3D上(降Y修shift然后cmode=True,最后UV合cmode=False的Y),对chroma噪点严重的效果还会有提升吗?(更慢了... )mawen1250 写了: 首先BM3D依赖于block match进行降噪,而对于YUV,Y是用于BM的,如果分开处理意味着U、V被用作BM,而它们本身通常并不适合做BM(包含的结构信息太少);其次是OPP效果比普通matrix的YUV好。
所以我的建议是转YUV444处理(mvf.BM3D里做的)。