When Apple Color loop bug is so stubborn

[Kaku Ito]

Hello,

I don't know if anyone posted already, but when Apple Color loop bug is so stubborn sometimes and Clipfinder's fix does not even work, I found out some facts that might cause this issue and figured out how to over come this issue.

Facts:

You shoot with pre-build 30 camera and the proxies are generated by the camera.

Then edit using the proxies in FCP with the latest color science. In FCP timeline there's no indication of problems like the screen turn green.

Send the timeline to Color, then you would have some clips especially, with single R3D file (short clips that only takes one R3D file) that work fine. Then you would have some clips that are stuck and won't play. You can normally fix this issue with our familiar Clipfinder Color loop bug fix, but under some situations like footage are from pre-build 30, then you are editing with FLUT color science with all of the latest REDLINE and all, then some footage won't get fixed even with the Clipfinder.



Solution:

I found that some problems happen wether you used the edge code or TOD during editing. The timecode choice inconsistency could result in this? I don't know, but if you find that you have some clips don't get fixed with loop bug, try to switch the timecode choice other way around. You can do this with Clipfinder's edit loupe function.

Then next important thing to do is that when you change the timecode (thus affects the RSX setting which won't do anything for FCP and Color), you must regenerate the proxies to take this in effect. Also you might have to reconnect the proxies on the FCP timeline after you rengenerate the proxies. This is so, because FCP figures things out like timecode from the proxies (for proxy editing). Then you would have to send the reconnected timeline to Color, go through normal Clipfinder loop bug fix and there you go.

To regenerate the proxies, please be warned that with the latest RED software, Clipfinder has problem generating proxies in bulk nor single proxies. I use old RED software with Clipfinder in another computer to be able to regenerate in bulk.

[Dustin Cross]

Kaku,

There are also a few versions of RedcineX and Redline that generate proxies (wrappers) with wrong timecode. They work fine in FCP, but crazy things happen in Color. I had a nightmare with this until we figured it out and Red came out with new versions that fixed the problem.


Dusty

[Kaku Ito]

Dustin,

Yeah, so when those crazy things happen, then this is maybe how you can over come.

[Kaku Ito]

I also ran into problem with clipfinder on FLUT redline that the edge code radio button flips back by itself after you uncheck it then go to RED Rush to create QuickTimes. So in this configuration you won't be able to create proxies with TOD timecode. Clipfinder in this situation does not let you create proxies neither.

[Kaku Ito]

Important aspect I maybe did not mention is that you would have to regenerate the proxies with old REDLINE instead of the new ones.

If you shoot with older camera firmware build, generate the proxies with older REDLINE.

Doing above with new REDLINE versions after FLUT science does not seem to fix this problem.

[JJC]

I had the loop bug in Color with some footage from a RED build where the camera generated proxies. I had previously exported proxies from the latest version of REDCINE with a one light pass and worked with those proxies (half-res) in FCP. When I sent the XML to Color: loop bug. I tried Hamingja's colorfixer tool but it just caused unlinked media in the Color project.

The solution I found was to link the QT proxies in FCP to the QT proxies created by the camera instead of the one's from REDCINE, export the XML for Color and use the colorfixer tool on the Color project and voila, no more loop bug.

The only thing about this is that it means my QT proxies no longer have any of the one light pass data, they are the one's created by the camera. As near as I can tell this doesn't really matter at the point where I'm going to Color for final CC work because it seems to me that Color ignored the one light pass data anyway and accessed the R3D raw data for me to color grade.

Am I correct in this? I'm new to RED, this is only the second time I've worked with it and the first time I've used the QT Proxy workflow. Before we just rendered out ProRes files from REDCINE and finished with those because it was a web video project and we didn't have the time to go back and finish on the R3D files.

[Josh Cass]

Yeah ok, use my full name. Awesome.

I had the loop bug in Color with some footage from a RED build where the camera generated proxies. I had previously exported proxies from the latest version of REDCINE with a one light pass and worked with those proxies (half-res) in FCP. When I sent the XML to Color: loop bug. I tried Hamingja's colorfixer tool but it just caused unlinked media in the Color project.

The solution I found was to link the QT proxies in FCP to the QT proxies created by the camera instead of the one's from REDCINE, export the XML for Color and use the colorfixer tool on the Color project and voila, no more loop bug.

The only thing about this is that it means my QT proxies no longer have any of the one light pass data, they are the one's created by the camera. As near as I can tell this doesn't really matter at the point where I'm going to Color for final CC work because it seems to me that Color ignored the one light pass data anyway and accessed the R3D raw data for me to color grade.

Am I correct in this? I'm new to RED, this is only the second time I've worked with it and the first time I've used the QT Proxy workflow. Before we just rendered out ProRes files from REDCINE and finished with those because it was a web video project and we didn't have the time to go back and finish on the R3D files.

[Ben Brainerd]

Generally speaking, I keep the camera-generated proxies around for exactly this reason. I've run into various problems with regenerated proxies coming from pretty much ALL of the software tools. And like Josh said, once you're moving into Color, the one-light data isn't as critical. Helpful, but with a little note-taking you can replicate the data.

One thing that keeps cropping up, yet people seem to keep forgetting: If you're running TOD TC and you roll over midnight (Or whatever the camera thinks is midnight. Check your settings) You'll end up with similar problems. FCP reads the TC jump without any problems but Color chokes on it.