Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Creative Community Conversations BMCC alternate workflow

  • Jeremy Garchow

    September 10, 2012 at 6:23 pm

    [Walter Soyka] “If you can’t set an input profile to 601, and instead interpret the colors as if they were encoded with 709 values when they were really encoded with 601 values, it is objectively wrong. “

    But lets look at practically wrong.

    You CAN’T set an input profile in FCPX, or Pr, or FCP Legend. So, what comes in is what goes out as there’s no transformations. If that’s “wrong” to you and Rafa, so be it. I’ll keep my version of right that the input matches the output on passthrough renders. If I change anything in that pipeline, they don’t match

    [Walter Soyka] “For example, if you took a file to another application for FX work, you’d have to make sure that none of them correctly transform from 601 to 709 or else you’ll have an inconsistency. “

    I would disagree. This is exactly what I do (don’t touch it) and everything comes out looking like it went in, unless of course I don’t want it to. Again, maybe the matching colors is wrong. It’s easy and clients don’t complain, so I guess I’m OK with it.

  • Oliver Peters

    September 10, 2012 at 6:56 pm

    My apologies, as I’ve been glazing over most of this discussion 😉 , but here are my 2 cents…

    It’s important to understand that color space specs are based on DISPLAY profiles. Rec 601 or 709 are not based on camera specs, but rather how to define the way an image looks on a TV or monitor. This information is part of the definition of a file or a codec’s specs. In the case of Apple, QuickTime (and other converters using the QT kit) make certain assumptions about the correct profile when a file is imported. Apple relies on the manufacturer to create files that adhere to the spec they expect to see.

    If you import a file into FCP X that uses a professional digital video codec (like uncompressed or ProRes) it will scale the values to correspond to Rec 709 color space. If you import a TIFF, FCP X knows the file has RGB (“full swing”) values, but it will scale the levels into Rec 709 space (“studio swing”) since it’s being edited in an environment based on digital video standards. OTOH, the GUI display is actually being shown with an extended luma range designed for the RGB space of the computer display. If you import a ProRes file into FCP X, edit it to a project timeline and export it again as ProRes, I’m not sure this is the same “transparent” (media-copy-only) process that it used to be in FCP “legacy”.

    As an aside, I have been testing the display levels of various players using a series of 8-bit greyscale files as QT movies (uncompressed, ProRes, DNxHD, AVC-Intra). Absolutely no player and no compressed codec displays the correct gamma value. Only uncompressed is properly displayed in the players. IMHO Apple has chosen to alter the “proper” gamma for something that they feel looks better on their displays. Yet, by eye and by the scopes, all of these files appear correct in FCP X.

    The application of camera LUTs (like an ARRI LogC-to-709 filter) is a mathematically correct conversion to change the LogC profile back into an appearance that matches the Rec 709 appearance of the image from the camera at the time of that recording. If this is an image that is going to be heavily graded anyway, the LUT may or may not be all that important. You can get back to that image (or reasonably close) with standard grading and no LUT. Odds are you are going to change the grading anyway to look different than the 709 appearance on set or in studio, so it probably doesn’t matter whether you are using a LUT or not – other than ease of use.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Jeremy Garchow

    September 10, 2012 at 7:07 pm

    [Rafael Amador] “I shot with a GH2, and that shots Rec-709. If I’d leave the default Rec-601 matrix (the application was first designed for Canon), I will be getting wrong colors on the Prores files.”

    That’s because you started with 709 in the first place and you are physically changing them to 601.

    With the Canon workflow you start with 601.

    You seem to think you need to transform the colors, I’m saying you don’t.

    When you bring it in to an NLE, those colors aren’t going to change, although you and Walter seem to think they will.

    To each their own workflow, I guess.

  • Jeremy Garchow

    September 10, 2012 at 7:11 pm

    [Oliver Peters] ” other than ease of use.”

    During the rough cut stage.

    I typically strip a LUT for any final grading, but I certainly use a LUT for editorial and client reviews so I don’t have to “regrade” the piece for every review.

    Plus, in the case of Alexa, the Log-C to 709 LUT is what is typically used on set, so the client is familiar with it.

  • Jeremy Garchow

    September 10, 2012 at 7:12 pm

    [Oliver Peters] “My apologies, as I’ve been glazing over most of this discussion 😉 “

    Oh, and there’s certainly no reason to apologize for this.

  • Oliver Peters

    September 10, 2012 at 7:18 pm

    [Jeremy Garchow] “I typically strip a LUT for any final grading, but I certainly use a LUT for editorial and client reviews so I don’t have to “regrade” the piece for every review.”

    If my grading goes out-of-house, then I send the colorist the QuickTimes, so no LUTs baked anyway. I’ve found that for F3 S-log and C300 Canon log, a basic grade in FCP X’s color board is more than adequate for both a rough cut grade and a final grade.

    For ALEXA, I apply the Pomfort filter and color board on top for a final grade. Pomfort has some built in grading controls, too, so a tweak of both gets you a great image.

    If I’m working in FCP7 with ALEXA, I add the Nick Shaw LUT, export baked “proxy edit” PRLT files. Offline with those and then access the PR4444 “clean” files for the final grade.

    – Oliver

    Oliver Peters Post Production Services, LLC
    Orlando, FL
    http://www.oliverpeters.com

  • Jeremy Garchow

    September 10, 2012 at 7:19 pm

    [Walter Soyka] “but interpreting 601-encoded HD as if it were 709-encoded HD is also wrong, “

    Walter, this is kind of what I have been saying.

    You DON’T interpret (or transform), you simply leave it alone.

    Earlier, you and Rafa seemed to be saying you need to interpret the 601 colors to 709. I don’t see why one would do this. You simply take the colors that were shot in 601 and carry on. I don’t see the point of interpreting the 601 recorded material to 709, it does nothing but change the original colors to something different.

    It will be assumed it is 709 and no colors will change. If you actually transform to 709, you will change the colors, and most likely you will only change them in that application unless you “Bake” the profile in to a new QT movie. This could cause some confusion if you would ever need to reconnect to the original unbaked movies for whatever reason, or you do another transcode and forget to transform the colors from the original.

    Again, I’m losing track of right and wrong.

  • Rafael Amador

    September 10, 2012 at 7:41 pm

    [Jeremy Garchow] “[Rafael Amador] “I shot with a GH2, and that shots Rec-709. If I’d leave the default Rec-601 matrix (the application was first designed for Canon), I will be getting wrong colors on the Prores files.”

    That’s because you started with 709 in the first place and you are physically changing them to 601.

    With the Canon workflow you start with 601.

    You seem to think you need to transform the colors, I’m saying you don’t.

    When you bring it in to an NLE, those colors aren’t going to change, although you and Walter seem to think they will.

    To each their own workflow, I guess.”
    No Jeremy,
    Is about the two formulas I wrote up there.
    With the GH2 you make;
    – In Camera: RGB > YCbCr applying formula 2 (R-709)
    – In 5DtoRGB YCbCr > RGB applying formula 2, then RGB > YCbCR Applying formula 2.

    With the Canon you make:
    – In Camera: RGb > YCbCr applying formula 1 (R-601)
    – In 5DtoRGB YCbCr > RGB aplaying formula 1, then RGB > YCbCR Applying formula 2.
    Both processes are correct.
    The oddity of the Canon being 601, is corrected when you apply the 601 matrix in 5DtoRGB.

    [Jeremy Garchow] “Recording the HD footage as 601 is “wrong”, that’s the problem. “
    I would say wrong, Jeremy. The point is that the application that will convert it to RGB understands that although is HD is not R-709.
    If you import the Canon stuff to FCPX and FCPX is aware that is R-601, when you export the movie as Prores, the Prores file will have exactly the same colors than the original H264.
    But not only with Prores, if you export as a Tiff sequence (with whatever Color Profile you want), the colors wont match the original.
    The error is in the first YUV to RGB conversion.

    Is similar to the issue that we’ve been having for years with FC and the Interlaced material or the Alpha channels. FC by default set any Animation codec file as “Upper first” even when being Lower, or took any Alpha channel as Strait, even when being premultiplied.
    Is all about “interpreting footage”.

    If FCPX knows he proper color profile of the file you import, will do the correct YUV > RGB conversion.
    This is what the “Color Profile override” in FCPX is for, No?
    That doesn’t change the Color Space of the whole project, but individual clips or stills. isn’t it?
    I can’t imagine FCPX (which is very little customizable on exporting), exporting a non-standard HD file (R-601).
    So my believe is that the “Override Color Space” is to fix those issues on importing.
    With the proper color management and working in 32b shouldn’t be no problem with that canon stuff.
    rafael

    http://www.nagavideo.com

  • Jeremy Garchow

    September 10, 2012 at 8:11 pm

    [Rafael Amador] “No Jeremy,
    Is about the two formulas I wrote up there.
    With the GH2 you make;
    – In Camera: RGB > YCbCr applying formula 2 (R-709)
    – In 5DtoRGB YCbCr > RGB applying formula 2, then RGB > YCbCR Applying formula 2.

    With the Canon you make:
    – In Camera: RGb > YCbCr applying formula 1 (R-601)
    – In 5DtoRGB YCbCr > RGB aplaying formula 1, then RGB > YCbCR Applying formula 2.
    Both processes are correct.
    The oddity of the Canon being 601, is corrected when you apply the 601 matrix in 5DtoRGB.”

    I’m sorry, Raf. I’m not smart enough. You are losing me.

    [Rafael Amador] “when you export the movie as Prores, the Prores file will have exactly the same colors than the original H264.”

    Yes. You don’t want this?

    [Rafael Amador] “But not only with Prores, if you export as a Tiff sequence (with whatever Color Profile you want), the colors wont match the original.”

    If you export with NO PROFILE, the colors will match, there is no reason to color profile this material, unless of course, you want to for whatever reason.

    [Rafael Amador] “Is similar to the issue that we’ve been having for years with FC and the Interlaced material or the Alpha channels. FC by default set any Animation codec file as “Upper first” even when being Lower, or took any Alpha channel as Strait, even when being premultiplied.
    Is all about “interpreting footage”.”

    No. It’s not the same.

    Let me ask you this, when you add true 601 material (SD) to an HD timeline, do you mean to tell me you actually color profile the 601 material to 709? Why or why not?

    If a file is CREATED as upper filed first, and the NLE says it’s lower field first (transform), and you are playing back through an upper field pipeline as through a capture card to a video monitor) , that is an incorrect interpretation and your file will not playback properly.

    If a file is created at 601 and played back in a 709 space (as through a capture card to a video monitor) there will be no shift in color as the file is assumed 709. It does NOT transform the 601 to 709. There is no transforming that needs to happen.

    The Canon files are not simply mislabeled. Misinterpreting a field order or alpha type is a totally different scenario.

    [Rafael Amador] “This is what the “Color Profile override” in FCPX is for, No?”

    I will say this again, the color profile override only works with stills. It does not work with video.

    [Rafael Amador] “That doesn’t change the Color Space of the whole project, but individual clips or stills. isn’t it?”

    Yes, just the stills that you choose to change.

    [Rafael Amador] “With the proper color management and working in 32b shouldn’t be no problem with that canon stuff. “

    Oy. The “proper color management” would have been to have shot it in 709 to begin with. After that, anything you do will be diverging from the original file. You of course can change it if you think that is the best way to go about it, but that is not the “right” way. You are simply transforming the colors for the sake of it, not to do anything “correctly” or match a color or display.

    I think you will potentially cause way more trouble than is necessary.

    Besides, I thought the older Canon stuff was RGB anyway, not YCrCb. It can’t conform to 709 as the pixel count or frame rates weren’t up to par, or something of that nature, but I don’t really know.

    Jeremy

  • Jeremy Garchow

    September 10, 2012 at 8:34 pm

    [Oliver Peters] “If I’m working in FCP7 with ALEXA, I add the Nick Shaw LUT, export baked “proxy edit” PRLT files. Offline with those and then access the PR4444 “clean” files for the final grade.”

    I happen to use the GlueTools plug that works in a more or less real time even on my crappy lappy.

    In X, I Pomfort as well.

    I also find grading out of Log in X to be superior quality wise than FCP7. FCP7 turns to noise much more quickly. In 7, I still go to Color so the LUT is for preview and review purposes only.

Page 8 of 10

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