-
BMCC alternate workflow
-
[Jeremy Garchow] “[Rafael Amador] “You can’t do a proper YUV>RGB conversion if you don’t know the Color Profile of the YUV stuff, and QT files do not flag the color profile.”
I think you might be over thinking this.
What do you mean by “proper”?
What’s done is done. FCPX does not let you transform color on video files. The “Color Override” option goes away, and there’s a non changeable “color profile” field that simply lists HD or SD.
The footage that you have has been recorded and it looks the way it looks. In the case of the few Canon DSLRs that do shoot 601, there’s zero reason to transform them to 709. I mean, you can if you want to, but there’s really no reason to. “
[Jeremy Garchow] “[Rafael Amador] “If you import Canon footage to FCPX (or whatever other application) and FCPX treat it as Rec-709, is doing a wrong conversion to RGB.”
But it’s not “wrong”. The camera should be shooting 709, but editing and outputting a 601 source in a 709 container won’t do anything incorrectly. Even if you could transform the 601 to 709 in FCPX, that wills simply cause the color to look different than when it was shot. You will probably have a more difficult time as it will look one way in one application but not the next.”
No Jeremy, and there is nothing like a 709 container. What is 709 or 601 is the content.
Anyway, i’m not talking about “if looks OK go on” (the good enaough option),
I’m talking about color accuracy and trying to get in your computer the picture the most closed possible to what was in front of your camera when you shot.If an application convert to RGB footage that is Rec-601 as if was Rec-709, is doing wrong because the two color matrix are different on both standards.
Just look at the formula of the Luma coefficients:
Is not the same to apply the formula :
Y’ = 0.299 R’ + 0.587 G’ + 0.114 B’ (Rec-601)
than to apply the formula:
Y’ = 0.2126 R’ + 0.7152 G’ + 0.0722 B’ (Rec-709)So when you convert stuff that is Rc-601 as if was Rec-709, the RGB color you are getting are different.
Applications like 5DtoRGB, aware of the fact that ALL the Canon record Rec-601, allows to correct this when converting to Prores, putting out Prores QT files with the standard Rec-709.
Is not that the Canon Rec-601 is wrong, Is that if your camera applied the first formula when going RGB (CMOS sensor) to YUV (H264 file), you should apply the same formula when converting your H264 to RGB in your NLE or graphic application.That you do not “manage color”, doesn’t means that you are not applying a certain matrix. If you ingest H264 that is Rec-601 and you do not color manage, on exporting a Prores file, it will be Rec-601.
rafael -
[Walter Soyka] “If the Canon camera uses 601, then interpreting it as if were 709 (in other words, failing to transform it to 709 for HD editorial) will cause the color to look different. That’s Rafa’s point — if you’re assuming that the Canon is working in 709 when it is not, the color is wrong.
But yes, HD cameras should use 709, and it’s puzzling that the 5D apparently uses 601.”
This is from the 5DtoRGB manual:
“Decoding Matrix: Choose the decoding matrix you want to use here. Normally, you would match the matrix that was used to encode the video to YUV (technically YCbCr). Generally speaking, BT.709 is for HD material and BT.601 is for SD. Canon HDSLRs use the BT.601 matrix, which is selected by default”.
rafael
-
[Rafael Amador] “No Jeremy, and there is nothing like a 709 container. What is 709 or 601 is the content.”
I guess when I say 709 container, I mean the resulting HD file.
[Rafael Amador] “I’m talking about color accuracy and trying to get in your computer the picture the most closed possible to what was in front of your camera when you shot. “
OK. So how does transforming to 5D material from 601 to 709 reflect accuracy? It doesn’t. You are changing, as you say, the content. As I mentioned, if you want to do that, you can, it’s a choice, but there’s no technical reason you need to as the footage is what it is.
If you do need to completely transform the content for a differing display or output, then color management makes sense, like going to a different film stock, for example. Personally, I never need to do that.
[Rafael Amador] “So when you convert stuff that is Rc-601 as if was Rec-709, the RGB color you are getting are different.”
Different from what? I guess I don’t understand what you are trying to do.
If I bring in a 601 HD file to FCPX and export it to a ProRes movie, nothing has changed color wise so what are you saying needs to change or what is “improper” or “wrong”? Please give me a concrete example to work from.
[Rafael Amador] “Applications like 5DtoRGB, aware of the fact that ALL the Canon record Rec-601”
The new MkIII is 709.
[Rafael Amador] “Is not that the Canon Rec-601 is wrong, Is that if your camera applied the first formula when going RGB (CMOS sensor) to YUV (H264 file), you should apply the same formula when converting your H264 to RGB in your NLE or graphic application.”
But why? Why transform again? There’s zero reason. If 5DtoRGB wants to do that, that’s cool. They do other things with the highly compromised dslr files as well in terms of luma sampling.
[Rafael Amador] “That you do not “manage color”, doesn’t means that you are not applying a certain matrix. If you ingest H264 that is Rec-601 and you do not color manage, on exporting a Prores file, it will be Rec-601.”
So you put a can of paint full of yellow paint inside of a white bucket, and the yellow inside in now white? No, it is yellow paint inside a white bucket.
It is not a 601 file. It is assumed 709, most everything will assume it’s 709. It is 601 colors in a 709 space just like putting an SD file in an HD timeline. Do you color manage that process? Why and what good does it do?
Jeremy
-
[Rafael Amador] “”Decoding Matrix: Choose the decoding matrix you want to use here. Normally, you would match the matrix that was used to encode the video to YUV (technically YCbCr). Generally speaking, BT.709 is for HD material and BT.601 is for SD. Canon HDSLRs use the BT.601 matrix, which is selected by default”. “
See, even 5DtoRGB keeps the 601 matrix.
Jeremy
-
[Jeremy Garchow] “See, even 5DtoRGB keeps the 601 matrix.”
No, and that’s Rafael’s point. 5DtoRGB assumes 601 instead of 709 when decoding the file. If another app assume 709 for all HD sources, it decodes these files incorrectly.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Jeremy Garchow] “See, even 5DtoRGB keeps the 601 matrix.”
No.
5DtoRGB convert H264 stuff to Prores. It works in RGB 32bFP, (Y’CbCr > RGB > Y’CbCR) and its lets you select a matrix (601, 709 or even custom) according with the imported footage.
So with the canon stuff is making: H264 (601) > RGB > Prores (709).The Canon is the only device, that I know that shots HD-601.
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.
rafael -
[Jeremy Garchow] “If you don’t touch a 601 recorded signal in a 709 container, nothing bad is going to happen, so therefore there’s nothing “improper”. There’s no reason to reinterpret this footage if working with normal video output.”
I’m not really sure what you mean by “601 recorded signal in a 709 container.”
If you fail to transform wrongly-recorded 601 to 709 for working in HD, something is improper — you are not seeing the image as intended. It’s like overriding an image tagged with Adobe RGB by interpreting it as sRGB.
[Jeremy Garchow] “I guess “wrong” is subjective then. Older Canon DSLRs record in 601. Of course this is meant to be 709 so that part is certainly wrong. So, when I edit in 709, I am not changing the colors of the original media, the colors remain just as recorded. If I change to 709, then the colors won’t be as recorded, and therefore they will be “wrong” even though they are technically now in the correct color space to match the container. You are applying an adjustment to something that doesn’t need adjustment.”
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.
The literal RGB values would be as-recorded, but the colors they were intended to represent would not be.
As you mentioned, since you’ll be presumably be making subjective changes in the grade later, you can do this in a technically incorrect fashion without compromising the final result — as long as the entire workflow is consistently technically incorrect. 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.
[Jeremy Garchow] “With photos , and certainly Raw photos, adding a color profile can certainly help you define an aesthetic look. The CinemaDNG files that we are talking about in this thread seems to come in as AdobeRGB1998. You can override them to 709, and the colors are different. Are either of those right or wrong, or are they just different? That is the advantage of raw is that you can define it, and it is just metadata so it’s not baked in and is changeable.”
If the CinemaDNG spec relates sensor information to CIE XYZ (as I suspect but am not certain that it does), then changing the working space affects any adjustments to the image (i.e., the same literal numeric adjustments would give different results in different working space), but not the unadjusted image itself.
In this case, the correct profile to use with the image is the one with in which you develop it.
[Walter Soyka] “A LUT is a pre-computed transform from one specific color space to another. “
[Jeremy Garchow] “OK. But it doesn’t have to be a specific or standard color space. It can be whatever you want when you create your own LUT similar to the Arri Looks creator. Sure I can conform it to within the 709 space, but I don’t have to. LUTs are different from color profiles, but the idea of transforming one space to another is not that much different in profiles and LUTs.”
It doesn’t have to be a standard space, but it does have to be a specific space. Color profiles are all generalized to a device-independent color space by definition; LUTs are not.
[Jeremy Garchow] “Rafael is asking about regular video and 709 QT media. There’s really not many reasons to touch this material with differing color profiles.”
I think this conversation is specifically about the 601 Canon insanity. I generalized it a bit — sorry if I made it sound like you were saying something you’re not.
Practically speaking, you’re right that you can interpret these incorrectly and still be ok (as long as you’re consistent).
Technically speaking, Rafael is right that there is a right and a wrong way to do it, and using the wrong color profile for these source files means you’re not getting the colors the camera intended.
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
OK. I think we are getting lost on what “correct” and “wrong” is, or at least I am.
Recording the HD footage as 601 is “wrong”, that’s the problem. From there it’s up to you to make teh footage look how you want it to look.
If transforming the dslr footage seems like it’s the “Correct” thing to do, then by all means go for it.
You won’t be able to do this in FCPX, anyway.
-
[Jeremy Garchow] “OK. I think we are getting lost on what “correct” and “wrong” is, or at least I am. Recording the HD footage as 601 is “wrong”, that’s the problem. From there it’s up to you to make teh footage look how you want it to look. If transforming the dslr footage seems like it’s the “Correct” thing to do, then by all means go for it.”
I’m with you.
Recording HD as 601 is wrong — but interpreting 601-encoded HD as if it were 709-encoded HD is also wrong, and as my mother would remind me, two wrongs don’t make a right.
But here’s where your point about practicality comes in: if everyone does the second part wrong and you don’t, then even though you’re right, you’re wrong (because now you’re the inconsistent one). Sorry, mom.
I’m not in front of an FCPX machine now — does the color space override do anything for stills?
Walter Soyka
Principal & Designer at Keen Live
Motion Graphics, Widescreen Events, Presentation Design, and Consulting
RenderBreak Blog – What I’m thinking when my workstation’s thinking
Creative Cow Forum Host: Live & Stage Events -
[Walter Soyka] “I’m not in front of an FCPX machine now — does the color space override do anything for stills?”
Yes, that was how this got started. It’s the ONLY place the override works is for stills (at least that I come across so far and why I said that FCPX is hinting at other possibilities).
When using it, it transforms the color, but only in FCPX and not on the actual file (which goes back to my point of leaving things alone). On the sample BMD footage, Adobe RGB 1998 seems to be what was assigned. You change it to 709 and the look changes.
None of those decisions are “right” or “wrong”. 🙂
When I render out a ProRes movie, the look I choose is baked in to the file that is now going to be assumed at 709 space. So when that happens, the incoming picture will look the same as the outgoing picture.
Jeremy
Reply to this Discussion! Login or Sign Up