11 Replies Latest reply: Dec 19, 2012 1:21 AM by walczakb RSS

    Calculations that work in After Effects but not in Premiere Pro

    walczakb Community Member

      I'm developing another Premiere Pro plugin based on AE effects SDK.

       

      The plugin manipulates pixels in a very simple way - based on lift/gamma/gain controls it changes the values as such:

       

      colorRGB->blue = PF_POW( colorRGB->blue , gamma) * gain + lift

       

      And so on for the red, and green. All in floating point, PF_FpShort. I even tried doing calculations in PF_FpLong, but the results were the same.

       

      Later the values can be clipped using MAX and MIN macros.

       

      In After Effects everything works perfectly. In Premiere Pro, once certain gamma treshold (less than about 0.5, more than about 1.4) is reached, I start getting weird artifacts. Either green pixels or black squares in random patterns, usually, but not always, corresponding to the darker parts of the image.

       

      I have no idea why, and how to correct it.

       

      Please help.

       

      EDIT: Actually any gamma that is different than 1 results in these weird artifacts, and only in the BGRA_32f mode. BGRA_8u works fine.

        • 1. Re: Calculations that work in After Effects but not in Premiere Pro
          walczakb Community Member

          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 Community Member

            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 Employee Hosts

              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 Community Member

                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 Employee Hosts

                  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 Community Member

                    I'll send it to you today. Thanks!

                    • 7. Re: Calculations that work in After Effects but not in Premiere Pro
                      Zac Lam Employee Hosts

                      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 Community Member

                        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 Employee Hosts

                          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 Community Member

                            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 Community Member

                              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 ) );