[Joshua Caldwell]

What’s the best way to handle that Gamma shift? Apologies, some of this stuff is new to me.

[Joshua Caldwell]

Thanks for replying, Shane.

We converted to Proxy via FCP’s Log and Transfer. Once the cut was complete we did online via Media Manager and Batch Capture to ProRes 422 HQ.

Yeah, I realize it’s a less than ideal workflow. Hoping there’s a way out of this. We were thinking of printing out to HDCam and then ingesting that print into FCP via Log and Capture as a ProRes HQ file. Do you think that will help to maintain the color?

[Joshua Caldwell]

My AE is going to be testing that soon. Our theory is that, when exporting from Clipfinder, all of the time-code should remain intact. Thus, when you relink everything, your edited portion should still line up correctly with the original R3D timecode. As long as that’s the same, it shouldn’t be a problem.

However, we have no yet tested this. Again, and this may be the case with your footage as well, it’s only a handful of clips.

[Joshua Caldwell]

Here’s a potential cause/solution to the problem:

As some of you know, there have a been a number of threads/projects on here suffering from footage turning into solid green images during import (whether through FCP’s L&T, REDCINE-X and even Clipfinder). Like others, we were experiencing the same issue on our project, inexplicably, and have managed to isolate the problem and come up with a potential (albeit laborious) workaround for those still looking for a solution (considering there are none out there yet).

We’ve managed to isolate the problem to a select number of clips and it appears that the cause is a dropped frame, actually, several corrupted, dropped frames, that appear as solid green images in the middle of the clip. We were shooting on several SD cards and it appears there wasn’t any one card that was the culprit. However, after speaking with our DIT, we learned that on any card that had a “corrupted” frame, when copying to the hard drives, he would encounter a “Source Verify After Copy Error.” Having never seen this before (and us being in the middle of the desert with no internet access), and having verified that the information/footage was there in RED ALERT, he made a note of it, labeled the folder and moved on.

(I should note that while he should have possibly recopied, we were so under the gun and so behind on copying that, having checked to make sure all the footage did get copied and played fine in REDALERT, there was no way for him to know.)

When he came in this evening and started going through it, he discovered that all of the problem files with the green frames were from the same file that gave him the “Source Verify After Copy Error.” We were able to isolate those files based off those file labels and those notes and all of the other non-issue files appear to be importing through L&T correctly. However, I’ll have an update tomorrow on whether this is entirely true. So far so good.

So, that seems to be the problem, though we still don’t know what caused the weird dropped frames.

Now, for the workaround on the damaged clips:

First and foremost, as suggested above, not ALL of your clips are corrupted. What happens when converting through L&T is that once the program hits the bad frame (the green one) it doesn’t know what to do and converts everything after that frame, whether in the same clip or all the clips following it, to green.

Regarding the clips with the green frames, what we’ve done is brought the corrupted clip into Clipfinder and set in and out points before and after the corrupted section, effectively creating two separate clips, with the section within it missing and then exported it as normal.

Sometimes this doesn’t matter because the corrupted file is in the beginning, before the marker. Sometimes, however, they’re in the middle and we have to manually go in and re-sync the audio.

The reason you can’t just say “oh, well, we cut out 10 frames, so just drop the second clip in 10 frames later,” is that, at least for us, scrubbing over the corrupted section causes Clipfinder to crash. Our AE is going to be finessing those corrupted clips and we’ll let you know what his work flow is.

The fortunate thing is that we’re only losing a few frames of footage in certain clips. Fortunately, we were shooting with two cameras and have multiple takes of each scene. The bad news is that we don’t know what caused the dropped frames, since the issue wasn’t with one card in particular. Could have been a cable issus, card reader issue, random drive issue, we don’t know.

But at least there’s more of a solution to the problem then there was before.

Let me me know if you have any questions.

Josh

[Joshua Caldwell]

Jonathan,

Out of curiosity, which camera did you shoot on? We’re currently running into the same problem. We’ve tried converting to different formats on two different machines through FCP, REDCine, everything and its the same issue.

So far, it’s only happening to footage shot on the A Camera on day one. The interesting thing about that, is that on that day, A Camera was a Red One and B Camera was a RED MX. Thus far, we’ve had no trouble with the MX based footage (after day one, we switched A Camera to an MX).

It doesn’t make sense why RED ONE footage wouldn’t work but we believe we’ve isolated it to this camera. However, some clips work fine from that camera do work.

We shot on cards the entire day and it doesn’t seem to be a card only issue, though we haven’t confirmed that. Regardless, the proxies play fine and the pre-convert file plays fine in L&T. It’s some weird glitch in the conversion process.

Regardless, even though all your clips are turning green, that doesn’t mean that all of them are “corrupted.” What happens is that the corrupted clip effects the rest of the import. Try L&T on the clips following the clip that didn’t work. We’ve managed to trim it down to only a few problem clips. (This way you’re not screwed out of all of them.)

Meanwhile, has anyone else had experience with this. Seems like a recent phenomenon.

Thanks,
Josh