3 Replies Latest reply on Jun 29, 2013 12:08 PM by Jim_Simon

    PremierePro CC send to Speedgrade CC implementation not good

    tpolson Level 1

      two major problems. 


      1. No choice of format to export to. DPX is great, but sometime you would want AVI or QT. Avi as sooms they both to fix the lack of timecode support in Speedgrade. Very frustrating. 


      2. The timecode is lost on the new files.  If it is DPX, the frame numbers should be the same as the source TC frame numbers not the frame count.  Example if I have a video quicktime whose timecode starts at 1:00:00:00, my DPX frame should start at 86400. Why would you abandon the source TC when conforming??

        • 1. Re: PremierePro CC send to Speedgrade CC implementation not good
          Jim_Simon Level 8

          It's true the integration with SpeedGrade is still in it's very early stages.  There is a LOT of room for improvement.


          With the CC versions, you can now apply a .look right in PP, so it might work out better to try that work flow.

          • 2. Re: PremierePro CC send to Speedgrade CC implementation not good
            tpolson Level 1

            I'm not color correcting. i am trying to see if it is possible for a real world professional film workflow and so far adobe still doesn't get it.  Speedgrade is not new. It's been around for years. So is PremierePro. none of this is complicated or difficult from a programming stand point and should have been solved years ago if they want compete at the pro level.  here is the simple workflow i would hope to be able to acheive.


            This is standard everyday workflow for many companies. I have an mxf file that I edit down into a new cut.  i need to export the entire sequence as DPX into a series of folders that represent each edit. I also need to make the exact same file structure as JPG. This shouldn't be treated as a new master, but a conform so all of the new DPXs should have the frame numbers as a representation of the original source timecode. Why? Because more often than not the cut will change at some point and you need a consistant reference back to the source.  If I were the change the edit and rexport is would give me a whole different numbering for the frames.  Timecode exists for a reason.  I should just be able to export the seq, add a DPX out put and a JPG output with an option to preserve TC and make a folder for each clip. Speedgrade is pretty good at this, but is doesn't read an XDCam mxf. So what I have to do is export an EDL. Reconform in Davinci and batch out my sequences.


            Which brings me to anthoer ridiculous problem. reel naming or in Premiere, tape name. There are to different metadata entries with the same name "Tape Name". One is Premiere internal info (I guess), the other is under Dynamic Media. I have a clip I want to transcode for editing purposes and I have a Tape Name entered in the premiere internal filed, when I render out a quicktime and re import, there is no info in the Tape Name field.  In order to make that work I have to enter the Tape Name in the Dynamic Media Tape Name field. Render it out. There it is now in Both Tape Name fileds. Even bigger problem.  If you don't enter the reel name in the Tape Name field for Premiere internal, your reel name won't export in the EDL. So basically to do a proper editorial dailes confrom workflow you have to a make sure you enter the reel name in both fields otherwise it breaks.  Why is this a problem? (aside from the obvious) If I start with a DPX sequence, make a QT for editorial and I want to reconform in Speedgrade, it won't work properly because the Reel Names don't make it through the loop.


            Sorry for the rant, but all of this is what pros need to operate.

            • 3. Re: PremierePro CC send to Speedgrade CC implementation not good
              Jim_Simon Level 8

              If I were to change the edit


              That is where the SpeedGrade work flow falls down.  Like I said, there's still work to be done.  Do let Adobe know you want them to do it.