> > 1. KeyingBlur (used for pre/post blur) uses a 'bokeh blur with gaussian > type flat' in the YCC color space on color channels 2+3. in 4k this can be > very slow. I would really like to see a different algorithm here. as the > bokeh type of formular is >
It doe not use bokeh for couple of weeks already. It uses quite the same kernel-based approach as it's used for clipping. 3. The KeyingClip operation also uses a kernel. I am not sure what would be a common value. The larger the slower it gets. > It checks whether pixel is on edge or not by checking values of neighbor pixels within given size of kernel. > KeyingScreen: Blocks execution. Not sure if we can cache this like we did > with distort/undistort. don't know how much time it takes. and if this > process can be breaked! perhaps this is a really interesting part to > investigate. > That's not actually truth.That's only building of voronoi diagram and triangulating it happens in single thread, but that doesn't seems real stopper. That's like ~0.01sec to calculate triangulation, probably could optimize it a bit more. Main slowness was in running pixel processor, which is now optimized and gave 1.5-2.0x speedup in my tests. > MaskNode: this nodes is a buffer operation. The implementation calculates > everything to a buffer and reads the result using tiles. The calculation of > the buffer blocks all threads. > Mailed with Pete tonight. He was planning to commit optimization to how feather is calculated on his monday (quite large timezone gap). Also, we've been discussing making this stuff nicely tileable. Hopefully soon it'll be done. -- With best regards, Sergey Sharybin _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers