martin53
23rd July 2013, 20:25
Is anyone aware of a filter that can do a weighted merge of 3 source clips plus biasing at a time?
I want do do fast YUV->RGB->YUV conversions without all extra care the internal ConvertTo... routines give; e.g. I would accept a pixel with 0 luma but big U/V to be just black, and I don't need TV->PC range care.
For the formula Y = 0.299*R + 0.587*G + 0.144*B, I'd use the R/G/B planes (ShowRed(), ShowGreen(), ShowBlue()) and produce an Y8 format. Same with different coefficients to produce U and V. In order to create the 128 offset for U and V, I'd need an additional bias offset for the result, or a 0.5 scaled 4th all white clip.
For backward conversion, also negative coefficients are needed. And because the U and V inputs are biased to 128, I think source bias offsets are indispensable too. :(
mt_lutxzy can do the job. But every instance of mt_lutxyz takes several seconds at clip start to create the huge lookup table, and for a complete set of conversion formulas, 2*3 instances are needed.
It is essential that all three source clips are evaluated at a time because intermediate results might exceed the 0...255 range. This prevents use of two cascaded mt_lutxy() calls.
Maybe the even better alternative (memory saving, speed gain) would be a YV24 filter that calculates R/G/B from Y/U/V pixel by pixel on the fly, then does the scaling and biasing that RGBmultiply can do, and converts back to Y/U/V on the fly. With the plain 3*3 matrix multiplications, that does not seem too complicated I think.
I want do do fast YUV->RGB->YUV conversions without all extra care the internal ConvertTo... routines give; e.g. I would accept a pixel with 0 luma but big U/V to be just black, and I don't need TV->PC range care.
For the formula Y = 0.299*R + 0.587*G + 0.144*B, I'd use the R/G/B planes (ShowRed(), ShowGreen(), ShowBlue()) and produce an Y8 format. Same with different coefficients to produce U and V. In order to create the 128 offset for U and V, I'd need an additional bias offset for the result, or a 0.5 scaled 4th all white clip.
For backward conversion, also negative coefficients are needed. And because the U and V inputs are biased to 128, I think source bias offsets are indispensable too. :(
mt_lutxzy can do the job. But every instance of mt_lutxyz takes several seconds at clip start to create the huge lookup table, and for a complete set of conversion formulas, 2*3 instances are needed.
It is essential that all three source clips are evaluated at a time because intermediate results might exceed the 0...255 range. This prevents use of two cascaded mt_lutxy() calls.
Maybe the even better alternative (memory saving, speed gain) would be a YV24 filter that calculates R/G/B from Y/U/V pixel by pixel on the fly, then does the scaling and biasing that RGBmultiply can do, and converts back to Y/U/V on the fly. With the plain 3*3 matrix multiplications, that does not seem too complicated I think.