Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Avid Media Composer Exporting and keeping Log S color/gamma look?

  • Exporting and keeping Log S color/gamma look?

    Posted by Nick Ravich on February 18, 2016 at 8:36 pm

    Hello-

    Export question.

    Been exporting 1080 29.97 footage – primarily Log C shot C300 & Long S shot F5/Fs7/F55, then consolidated in Avid – for our motion graphics guy to build graphics from. Footage will be full frame and relatively unmediated in his graphics. Goal is to deliver uncolor-corrected HD res level exports that function more or less as the master media, ie we don’t want to re-conform/matchback his work later in online/finish.

    Per his recc, I’ve been exporting ProRes 444 HQ (color space is overkill I’m guessing given our footage) and generally those exports’ color looking pretty close to the originals in Avid. But for some footage – esp our S log stuff – exports definitely look more visually punched up. More saturated color, higher contrast. Doesn’t seem to be any hidden frame flex color correct on these. Maybe I’m not understanding how Log S works.

    Any recc.s for an HD codec that will best maintain original color across these var camera formats? Important bec/ in all likelihood our colorist will want to do his own pass on the motion graphics work. And again, don’t want to matchback. It’s a LOT of very short shots.

    Thanks in advance, Nick.

    Bill Ravens replied 10 years, 6 months ago 3 Members · 12 Replies
  • 12 Replies
  • Michael Phillips

    February 19, 2016 at 1:46 am

    There have been other threads that have raised issues with Sony Log file giving a different look. Have you tried a different wrapper other than QuckTime to eliminate that as being an issue? (MXF, DPX, etc.)

    Michael

  • Nick Ravich

    February 19, 2016 at 4:24 pm

    Thanks Michael. Someone on Avid forum suggested DNxHD175x/185x/220x.

    Here’s what he wrote – Welcome to ProRes. Inside MC, that is defined as Rec709, and when you export Same As Source, the resulting file is fine, but QT player will have a flag that ‘corrects’ the display mode so that Rec709 legal is expanded to sRGB (for display on computer monitors).
    I’d opt for DNxHD175x/185x/220x.

  • Michael Phillips

    February 19, 2016 at 4:30 pm

    The issue is not so much the codec, but QuickTime Movieplayer being the culprit in trying to “correct” for optional viewing. ProRes and DNxHD will behave the same way. QuickTime Player 7 is better than QuickTime Player X.

    Michael

  • Nick Ravich

    February 19, 2016 at 4:37 pm

    OK, so I think I misread you.

    It’s not that the outputted file had some kind of natively baked in color correct, it was that QT app played it with a default/ applied correction.

    So theoretically, if the designer brings these files into Premiere and/or After Effects that QT player correction shouldn’t happen? The files color should read more natively?

    Nick.

  • Michael Phillips

    February 19, 2016 at 4:41 pm

    If I know I am going to Adobe, Resolve, or other similar system, I have switched over my workflow to exporting MXF OP-1a and avoid the whole .mov fiasco. It is also a faster export as per my blog:
    https://24p.com/wordpress/?p=278

    Michael

  • Bill Ravens

    February 23, 2016 at 1:34 pm

    Michael,
    After reading your blog on OP1A, I’ve been transitioning my workflow to using OP1A as my D.I. coming out of Resolve. However, I’m seeing some odd behavior. I understand that MC (v8.5) only reads OP1A wrapped DNxHD, however, even DNxHD out of Resolve 12.3 seems to choke MC8.5, as it won’t open. Attempts to playback the Resolve generated OP1A’s results in limited success. QT7 will only playback the first 30 secs of the clip. The entire clip seems to playback ok in VLC or Switch.

  • Bill Ravens

    February 23, 2016 at 1:38 pm

    oops…forgot to add that if I run an OP1A generated by Resolve 12.3 thru Adobe Media Encoder, rewriting back to OP1A, the resulting OP1A will link ok in MC. It seems the Resolve configuration is incorrect. Note that the OP1A is a VERY loose specification.

  • Michael Phillips

    February 23, 2016 at 1:40 pm

    In the clips that won’t play, is audio included? I try to avoid audio in exports from Resolve -especially with AAF but there might be a related issue with MXF OP-1a. I have done 10 and 20 minutes as MXF OP1a out of Media Composer to encode via Adobe Media Encoder and have had no issues.

    Coming out of Resolve, I typically do MXF OPatom (Avid native) and not 1a, but I have, from time to time, also done 1a for quick checks where I did not want to do go through the whole AvidMediaFiles dance.

    MXF-OP1a has been supported for a while in Media Composer, and not just 8.5. Avid includes the MXF AMA plug-in which reads OP1a but you need to make sure you manually select the plug-in and never, never use Autodetect.

    Michael

  • Bill Ravens

    February 23, 2016 at 1:48 pm

    yeah, I manually select the MXF plugin. BUT, yes, there has always been audio included. Thanx for the feedback, I’ll try exporting without audio. Of course, for bringing back into MC, using OP-Atom is the best practice. I like the OP1A arapper as being a wee bit more flexible than OP-Atom….if it works, that is.

  • Bill Ravens

    February 23, 2016 at 2:10 pm

    ahhh, sadly eliminating audio from the Resolve export did not fix it. It links OK, but, when I load it into the source monitor, I get an error message: “Failed to get the sample size from the AMA plugin.”

Page 1 of 2

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy