Timothy Gassen
Forum Replies Created
-
Timothy Gassen
August 30, 2012 at 4:12 pm in reply to: FCP gamma shift on export, final QT file codecs & print to tape problemsFYI: here’s some info I found on M-JPEG vs P-JPEG. I’m new to using either as a final QT codec, so I’m learning! 🙂
“Both the M-JPEG codecs (A&B) allow fields and a field order to be specified, and if used the fields are compressed separately and then combined. This prevents artifacts from mushing fields together, and at lower quality settings this can make a significant difference. For this reason alone, anyone working with interlaced video should use the MJPEG codecs and not the Photo JPEG codec.
At quality levels below 100%, chroma is downsampled respective to the
quality level selected, but Photo JPEG samples at 4:2:0 (ie. vertical
samples) while the MJPEG codecs sample at 4:2:2 (ie. horizontal
samples). In terms of video footage, this relates to a fields issue and is another reason why you should use MJPEG codecs for interlaced footage instead of Photo JPEG.”I hope the info helps other users…
Timothy Gassen
Director/Producer -
Timothy Gassen
August 30, 2012 at 3:55 pm in reply to: FCP gamma shift on export, final QT file codecs & print to tape problemsHi Rafael,
Thanks for your comments!I haven’t found any resources that confirm P-JPEG is for interlaced SD footage. In any case, it doesn’t render correctly for our SD footage, showing field-dominance issues on export of the kind I’ve seen with progressive-interlaced conflicts.
M-JPEG, I’m told, can be re-inserted in FCP as a legacy export option, and I’ve read it’s an option many FCP users wish had never been deleted.
The Media 100 DV input to M-JPEG was as a firewire import, not an analog encode. DV has been a great acquisition format, but degrades greatly as an edit format. Working natively in DV is not the best quality solution, at least in FCP. The M-JPEG-encoded DV footage in Media 100 has been great in image quality. (I’m not knockingh FCP as a whole — different apps do different things well.)
Regardless, it seems I’ve been unable to get the firewire on the FCP machine at the facility I’m working at to give the actual rendered file out to tape. It could be the “print-to-tape” function is not working correctly in this install — but it appears to be sending draft quality out, not the rendered sequence. I’m thinking I’ll have to bring final QTs back into a Media 100 if I want a quality firewire out to DVcam…
Thanks again for everyone’s help.
Timothy Gassen
Director/Producer -
Timothy Gassen
August 28, 2012 at 10:15 pm in reply to: FCP gamma shift on export, final QT file codecs & print to tape problemsYes, that is what firewire SHOULD deliver — send a data copy — but our video seems to be re-encoded on the fly, with added mosquito noise not visible on playback of the actual rendered timeline.
We did a test “print to tape” form a non-DV timeline and it output immediately to DV without a re-encode — something that I think is not supposed to happen, lol — so this is why I’m guessing there is a bug in the “print to tape” function on this machine. It appears to be sending draft quality, not making a data-copy from the timeline.
Suggested fixes? 😉
Timothy Gassen
Director/Producer -
Timothy Gassen
August 28, 2012 at 10:06 pm in reply to: FCP gamma shift on export, final QT file codecs & print to tape problemsThanks again, Shane.
Photo-JPEG is for progressive files; Motion-JPEG is for interlaced (SD footage).
Yes, we’ve created a DV sequence and re-rendered specifically for the purpose of going out to DV via firewire. Quality in the sequence is fine — but that is NOT what is being sent out by FCP through the firewire. It is as-if FCP is still sending out draft-quality even though the timeline is rendered as DV. My thought that this was a bug with THIS machine, but perhaps it is a FCP limitation?
(Media 100, BTW, can send superior DV quality out because it converts its DV on import to the M-JPEG codec, not using DV at all for edit, and then can export back through firewire without a re-encode.)
So perhaps this is another limitation of FCP — the inability to send out DV in actual resolution through firewire?
Timothy Gassen
Director/Producer -
Timothy Gassen
August 28, 2012 at 9:35 pm in reply to: FCP gamma shift on export, final QT file codecs & print to tape problemsThanks again for your thoughts, Shane.
Yes, ProRes is a good delivery codec. Since you are sure networks “do something” to your files then my guess is they are correcting the gamma at their end, for their use.
My footage in this issue is all SD material, BTW.
Any FCP users have thoughts on M-JPEG as a final master file codec and how to get full-res firewire output to tape?
Thanks! 🙂
Timothy Gassen
Director/Producer -
Timothy Gassen
August 28, 2012 at 8:27 pm in reply to: FCP gamma shift on export, final QT file codecs & print to tape problemsHi Shane,
Thanks for the response. I do understand that re-importing a FCP- exported QT back into FCP will appear correct. I am attempting to use FCP QT exports in OTHER applications. Importing back into a PC editor shows the gamma shift. Encoding for DVD and Blu Ray show the gamma shift. Encoding for Web use shows the gamma shift.
I could accept that the export file will display incorrectly in QT Player if the actual file was in the correct gamma. (Also, the “enable FCP compatitbility” box has been checked.) Am I correct that FCP can only export a correct gamma QT if that file is used back within FCP?
Are your digital exports being used in anything other than FCP? Have you encoded for web, DVD or in another (non FCP) editor without a gamma shift? If so then please share your export settings/procedure — I want this to be my incorrect user setting, not a FCP limitation.
I know this is not only my issue — I’ve read hundreds of similar posts from much more experienced FCP users than me.
BTW, whether using direct QT Export, Conversion or Compressor, the gamma shift happens even when rendered out to the same codec as the sequence.
Thank you again for your help! 🙂
Timothy Gassen
Director/Producer