-
BMCC alternate workflow
-
Hi Jeremy,
Thanks for the article.
For me adds more darkness.He says:
“So, why do Canon DSLR cameras use the BT.601 recommendation for SD video, instead of the BT.701 recommendation for HD video, while using the latter’s color space?! The answer is simple… The Canon DSLR video can not comply with the BT.701 recommendation in regard to frame rates and maybe even pixel count”.What I understand from the article is that the Canon is no one of the standards, or at least uses a kind of “hybrid” 601/709 standard, because what is clear is that the Rec-601 is formulated only for PAL and NTSC.
In the other hand the Canon (at least his H264) are fully HD in terms of size/pixels and time-base, unless the author is talking about the 30Fps (real) that the Canon was making when he wrote the article (Jan. 14.2011).[Jeremy Garchow] “What is confusing to me is what you and I might think is “correct” or “wrong”. “
Color spaces are languages. to describe colors, so if doesn’t matter which language you use and which path fallows your “message”, if the final receptor understand it.
If the final receptor understand the message, for me the process is “correct”. Even if haven’t fallowed the expected path.[Jeremy Garchow] “Even 5DtoRGB is consistent with every other application unless of course you like to change it for the worse! “
What’s the point to have as default an SD matrix? Who shots SD with a Canon.What is clear is that there is something “odd” with the Canon footage, other wise 5DtoRGB wouldn’t need two different matrix options.
Unless the developer is giving us some bullshit.
rafa -
[Rafael Amador] “Color spaces are languages. to describe colors, so if doesn’t matter which language you use and which path fallows your “message”, if the final receptor understand it.
If the final receptor understand the message, for me the process is “correct”. Even if haven’t fallowed the expected path. “Brother, this is exactly what I have been saying all along. There is simply no reason to transform this footage.
Do we now agree?
[Rafael Amador] “What is clear is that there is something “odd” with the Canon footage, other wise 5DtoRGB wouldn’t need two different matrix options. “
They give you the option to change, but it uses 601 by default. Once rendered to a ProRes movie, THAT movie will be assumed 709, and every single application will also assume 709. The colors themselves have not changed from the original, even though they now have a 709 assumption.
[Rafael Amador] “Unless the developer is giving us some bullshit.”
He’s not bullshitting, but if you look at the 5DtoRGB version that’s on the AppStore and compare it to the output of earlier builds, there is a lot that has changed. You can tell he learned along the way as well. And if the chroma smoothing is important to you, 5DtoRGB presents an advantage there.
I just did another test.
If you import original h264 DSLR footage in to FCPX the Color Profile is listed as 1-1-6 which is 601. (I was wrong, earlier).
You then use FCPX to transcode the movie to ProRes (Make optimized media) and reimport that clip, it has a color profile of 1-1-1, which is 709. The colors of each of them are identical.
This is further proof that FCPX (and others) are handling this correctly and there’s no user action that needs to happen. There is a 601 to 709 path, and the colors remain the same. I had thought that everything was just assuming 709, but really the initial footage is handled at 601 in the applications I have tested, and then rendered out to a file that will be assumed 709, so there’s no need to specifically transform to 709.
And we all lived happily ever after.
-
[Jeremy Garchow] “If you import original h264 DSLR footage in to FCPX the Color Profile is listed as 1-1-6 which is 601. (I was wrong, earlier).
You then use FCPX to transcode the movie to ProRes (Make optimized media) and reimport that clip, it has a color profile of 1-1-1, which is 709. The colors of each of them are identical.”
Hallelujah!!
That’s all we needed to know to see that FCPX is managing properly the Canon stuff.
But your’s is the first news on that.
That means that the H264s files are properly tagged and FCPX is able to know the color of the Canon H264 (even if was not the expected Rec-709), and apply the correct matrix (601) to go back to RGB.Then make sense both options in 5DtoRGB. Seems that 5DtoRGB can not tell the Color specs of the footage and you must set manually the matrix you need for decoding.
My point was that the Prores that FCPX or 5DtoRGb being Rec-709 means no much if those applications haven’t use the Rec-601 when importing the Canon stuff. Yes, they will be Rec-709 but the colors won’t match the originals from camera. When ever you convert RGB to YUV with whatever the matrix, you need to apply the same matrix to go back to RGB if you want to keep the same colors.
[Jeremy Garchow] “They give you the option to change, but it uses 601 by default. Once rendered to a ProRes movie, THAT movie will be assumed 709, and every single application will also assume 709. The colors themselves have not changed from the original, even though they now have a 709 assumption.”
When you say “they give you the option to change”.
is not about options. is about applying the correct matrix.
If you use the Rec-709 with Canon footage, you are changing the colors on your clips.if I use the default 5DtoRGB matrix with my GH2 footage, the resulting Prores, sure will be Rec-709, but the color won’t match the original H264 files.
What now remains fully inconsistent is the article you linked.
rafael
-
[Rafael Amador] “if I use the default 5DtoRGB matrix with my GH2 footage, the resulting Prores, sure will be Rec-709, but the color won’t match the original H264 files. “
What do the GH2 settings default to?
-
With the GH2 you must chose the Rec-709 matrix.
You have to do it manually.
if you want, I can send you a short clip so you can check how shows up in FCPX (601 or 709).
rafa -
[Rafael Amador] “if you want, I can send you a short clip so you can check how shows up in FCPX (601 or 709).”
Yes, that would be great.
-
I just wanted to follow up about the test footage from Jeremy.
As discussed above, the differences between interpreting his footage in 601 and 709, all other things being equal, are minimal: never more than 1% difference per channel. Boosting the saturation on this footage a bit pre-comparison pushes the difference all the way up to 2%. It is mathematically noticeable, but visually insignificant. In extreme examples, it would be possible to see some saturation clipping, but I didn’t observe any of that in Jeremy’s real-world test footage.
For this specific camera, I’d say the penalty for pretending the footage is Rec. 709 is negligible.
I didn’t test 5DtoRGB itself, but rather compared the same footage, interpreted in the two different color spaces, in Ae. This suggests that the big difference with files from 5DtoRGB and other decoders is not simply applying the correct color matrices, but rather dealing with the full swing (or whatever other voodoo is going in within the black box that is QuickTime). If this kind of footage is important to you, I’d suggest you verify that your application is appropriately dealing with the range.
We went off on a few tangents on color geekery and I think we lost focus on the main point: color management is a useful feature that belongs in an NLE. It doesn’t make a practical difference in this specific case, but you’d see much more noticeable differences with non-video space sources like stills or more advanced cameras with different color sciences.
Cheers,
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
Reply to this Discussion! Login or Sign Up