Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Color.app renders wrong timecode w/REDCODE clips

M

Mel Matsuoka

Well-known member
Joined
Sep 6, 2007
Messages
92
Reaction score
0
Points
6
Location
Buffalo, NY
Anyone here experiencing issues with Apple Color rendering clips out with incorrect timecode when working with native REDCODE clips?

I'm noticing that if you set Color.app to render clips out with handles, it will render the clips out to Quicktime (doesnt matter if it's UC10bit or ProRes) with the timecode offset the same number of frames that you set in the Handles preference. So when you send the sequence back to Color, all your edit points get screwed up, and you have to reconform the clips back, by hand.

If you render the Color sequence without handles, however, everything seems to send back fine.

I use Color.app nearly every day, with many different formats, and the REDCODE workflow is the only one that exhibits this behavior. And it's not an issue of sending time-remaps, speed-changes, either. Even the simplest edits exhibit this problem.

Anyone else seen this behavior? I'm not sure if I should report this to the Apple BugReporter, or to RED...though it's smellin' more and more like a RED problem.

System Specs:

Color 1.0.4
FCP 6.0.5
Mac OSX 10.5.6 (yeah...I know, I know... :P)
Quicktime 7.5.5
REDCODE codec v3.5.0
RED FCS plugin 1.0.0
RED Build17 (v3.4.1) footage (2k/2:1/23.98)
 
Mel, interesting. If I get a chance I will test this and see if I can confirm your findings. So, the timecode is earlier or later?
 
Hey Mel,

Yesterday I came across a different timecode issue with the wrapped R3D's. See my post here, http://www.reduser.net/forum/showthread.php?p=380378#post380378

It's not the same problem, but a timecode issue non the less. I'm curious, are the sequences you're sending to color built from Log and Transfer wrapped R3D files or are they built from the R3D QT proxy (or reference) files? If they are the wrapped files, see if you get the same problem with sequences built from the proxy files. If I get a chance today, I'll try and test it out as well.
 
Sorry to have to do this, but I'm bumping this topic...I can't be the only one having this issue...it's quite a serious workflow problem.

If it helps to nail down the problem, I'm using the ClipFinder R3D reconform method. This is a consistent and repeatable bug when using wrapped REDCODE QTs. RED support, please give us some love here, guys! I'm getting tired of spending late nights manually adding handles to sequence clips before I send them to Color. This is the only workaround to this issue, and it's a real shitty workaround, when you have real, paying clients with real deadlines to meet.
 
colorfixer

colorfixer

sorry haven't tried it with handles. proxies -> send to color -> send to FCP works great for me but only after using ColorFixer. I love that little thing but I wish Apple would fix that bug too.
 
Yes, I get this problem too, and have stopped using handles in Color. It's a pain having to lock the edit precisely before grading, but it can be done. Apple needs to fix this one, but they don't have a good track record with fixing bugs in Color. Color 1.01 made Color un-usable for PAL footage, but it took months before 1.02 came out and fixed that bug.
 
Nick Shaw said:
Yes, I get this problem too, and have stopped using handles in Color. It's a pain having to lock the edit precisely before grading, but it can be done. Apple needs to fix this one, but they don't have a good track record with fixing bugs in Color.
Click to expand...

I'm not sure who to direct this bug towards. Did Apple develop the RED plugin for Color independently of RED? Or did Apple simply give the RED devs hooks into the Color API so that they could do the RED support themselves?

I'll submit this bug to the Apple bugreporter, just for the hell of it...but I'd also like to formally submit this as a bugreport to RED, as well. Is there an email address or bugtracker I can submit this to?
 
I have found another bug in Color using REDCODe files. When you grade a shot and then still store it, it doesn't save the grade correctly in the still store.

I don't know if this is because I have changed the RED settings in the Primary Room or not. Any other file I have used in Color creates an accurate still store. This makes it very difficult to match shots to shot.:mad:
 
Robert Due said:
I have found another bug in Color using REDCODe files. When you grade a shot and then still store it, it doesn't save the grade correctly in the still store.

I don't know if this is because I have changed the RED settings in the Primary Room or not. Any other file I have used in Color creates an accurate still store. This makes it very difficult to match shots to shot.:mad:
Click to expand...

What GPU are you running? I don't see this behavior with REDCODE files using Color 1.0.4 running on an ATI x1900 card.
 
You must log in or register to reply here.
Back
Top