-
1. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 18, 2012 12:04 PM (in response to walczakb)OK, I nailed it down to the blue channel. Red and green work fine. Only if there is gamma manipulation (lift and gain work fine) in the blue channel I keep getting the weird artifacts.
It might be helpful to note that I am using PF_Pixel_BGRA_32f structure provided by SDK:
typedef struct {
PF_FpShort blue, green, red, alpha;
} PF_PixelBGRA_32f;
cast from typical PF_PixelFloat via:
inBGRA_32f = reinterpret_cast<PF_Pixel_BGRA_32f*>(InP);
So... any ideas?
-
2. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 18, 2012 12:15 PM (in response to walczakb)Figured it out, although I still have no idea why it's only problematic with the blue channel.
If I clamp the blue channel on the input, I am not getting the artifacts. Is this some kind of a bug?
inPF->blue = MAX ( 0 , MIN ( 1 , inBGRA_32fP->blue ) ) ;
-
3. Re: Calculations that work in After Effects but not in Premiere Pro
Zac Lam Dec 18, 2012 12:44 PM (in response to walczakb)Could it be that the BGRA_32f data is somehow getting treated as ARGB_32f in your code? The AE native pixel format is ARGB, so if you're using the same code in PPro, I'd imagine you'd have to add in a way to treat the pixels as BGRA_32f when in PPro. Otherwise, when modifying blue you'd actually be modifying alpha, which would definitely create some strange results.
Zac
-
4. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 18, 2012 1:02 PM (in response to Zac Lam)Thanks, but no. This was one of the first thoughts that I have had. But switching alpha and blue did not fix the issue. I have separate code for each color space that converts input to regular PF_PixelFloat, and only then the calculations are performed, so this should be a non-issue.
-
5. Re: Calculations that work in After Effects but not in Premiere Pro
Zac Lam Dec 18, 2012 1:49 PM (in response to walczakb)If you'd like to get to the bottom of this so you don't have to clamp the blue channel, it would be great to get a modified version of one of the sample projects, which we could build and debug while referencing the source.
-
6. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 18, 2012 2:10 PM (in response to Zac Lam)I'll send it to you today. Thanks!
-
7. Re: Calculations that work in After Effects but not in Premiere Pro
Zac Lam Dec 18, 2012 4:05 PM (in response to walczakb)Seems like somewhere in the pixel processing, there is a calculation that overflows it's range. If you can trace the processing of one of these pixels you could probably spot where exactly the overflow is occuring. Any calculation where you convert from float back to int (either intentionally or unintentionally) would especially be suspect. Previous versions of SDK_Noise had this problem, which I fixed for the CS6 SDK.
-
8. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 18, 2012 4:57 PM (in response to Zac Lam)I basically narrowed it down to the input value in the blue channel.
I separated calculations on the blue channel and found out that any will cause this effect. When I manually set the blue input value to any float between 0 and 1, I got good results on any calculation.
So it looks like the incoming value is already out of range, which is very weird. And it only happens in the blue channel. Interestingly, I have no idea why clamping the value results in the proper calculation, and even in the proper color! It would be sensible, that if the value is out of range, then it would be clamped to either 1 or 0, and change the perceptible color. Unless it's a negative number in the blue channel...
So perhaps there is some type conversion going on that causes this strange problem, or the algorithm converting from YUVA to BGRA introduces negative values in the blue channel, or some other pre-processing makes this happen.
-
9. Re: Calculations that work in After Effects but not in Premiere Pro
Zac Lam Dec 18, 2012 5:17 PM (in response to walczakb)If an effect is processing in floating point, it should be prepared to handle out-of-range (including negative) values. You can easily achieve this by placing a ProcAmp effect before the effect in the stack, and using the Brightness control to raise the value up or down.
-
10. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 18, 2012 11:56 PM (in response to Zac Lam)OK, it's a fair assumption. What I'm still wondering, is why the clamping at the end had no effect whatsoever, and clamping at the beginning does.
Could it be that the PF_POW calculation on the initial non-clamped value (whatever that is) is throwing an error (how and why?), effectively bypassing all further calculations and assignments, resulting in an unspecified value applied to the output pixel (since the manipulation is performed on the intermediary pixel)? I tried putting conditions on the err variable outside of BlendFloat function, but it did not do anything, and I'm not that familiar with AE/PPro error handling.
-
11. Re: Calculations that work in After Effects but not in Premiere Pro
walczakb Dec 19, 2012 1:21 AM (in response to walczakb)I have applied the procamp, and I am even more convinced that this must be some kind of a bug with the blue channel.
All other channels handled negative and positive values out of [0,1] range perfectly - reducing brightness in the procamp, and bringing it back in my filter works fine. Of course, all the data in the blue channel is already lost by clamping it on the input.
Which is the reason I would not want to clamp the blue channel on input, and proceed with the calculations. But so far I have not figured out how to do it.
EDIT: Stranger and stranger...
If I clamp the assignment to the proxy pixel, it works fine:
colorRGB->blue = MAX (0, inP->blue);
But if I clamp just the value in the PF_POW macro like this:
colorRGB->blue = PF_POW (MAX (0,inP->blue), gamma.blue ) ;
or like tis
colorRGB->blue = PF_POW (MAX (0,colorRGB->blue), gamma.blue ) ;
It doesn't. It also doesn't work with pow() function from math.h, and it also doesn't work if I clamp the PF_POW from the outside like this:
colorRGB->blue = MAX( 0 , PF_POW (colorRGB->blue, gamma.blue ) );



