Welcome to our community

Be a part of something great, join today!

  • 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 :)

Apple Color REDCODE plugin 4.0 beta

Rob Lohman

Red Team
Joined
Dec 28, 2006
Messages
1,877
Reaction score
0
Points
0
Website
www.red.com
http://red.cachefly.net/redcinex/REDCODE_Color_v4_0_beta_2.zip

Added support for the new Mysterium-X sensor (plugin supports older footage just fine too!)

Added support for the new FLUT™™™ color science. This plugin will only do the new color science. If you need to use old color science with an existing project you should not upgrade to this version of the plugin or restore an older version when you switch back to an old project.

Added support for the new REDgamma gamma space and REDcolor color space

Added support for 4.5K footage. Clips recorded at 4.5K (4480 x 1920) will load as if they were shot with a resolution of 2240 x 960 due to Apple Color being limited to 4K maximum resolution. Half resolution decodes for 4.5K footage will not go through any debayer.

ISO list does not go beyond ISO 2000. Any clips shot at a higher ISO will be clamped to ISO 2000

Mac OS X 10.4 (Tiger) is no longer supported with this release


** updated QuickTime codec should be out soon as well **

** PLEASE POST FEEDBACK IN THIS THREAD ONLY! **

edit: uploaded beta 2 that should fix send to Color bug
 
Last edited:
Looking for clarification... is this supposed to work with non-MX sensor footage so long as it is late build footage (20+) that has color science?
 
Awesome Rob. Can you also please clarify a nagging question, at least with this new version- when working with 4k or less, is the decode full res? Is it always full res or is there a way to adjust?

We will have MX sensor very soon to test for ya.
 
Looking for clarification... is this supposed to work with non-MX sensor footage so long as it is late build footage (20+) that has color science?

It will work with ALL footage. It's just that it will apply the latest and greatest (FLUT™) color science to it which will make everything look better (but different from any previous plugin versions).

Thank you! When will we see a fully stable release?

When you guys don't report issues with it :biggrin: and the other parts of the Final Cut Studio installer are done (like the QuickTime codec)

Awesome Rob. Can you also please clarify a nagging question, at least with this new version- when working with 4k or less, is the decode full res? Is it always full res or is there a way to adjust?

For full res it's always doing debayer, and I *think* it's doing that too for half resolution (with the exception of 4.5K footage). I haven't had a change to verify that though.

We will have MX sensor very soon to test for ya.

As noted above this is not limited to MX footage!
 
It will work with ALL footage. It's just that it will apply the latest and greatest (FLUT™™™™) color science to it which will make everything look better (but different from any previous plugin versions).

I seem to be having an issue with it then... I installed it and send clips to color but the RED tab is not enabling when I am on the clips. I re-installed the version that comes with the FCP Studio 3 installer, the RED tab works again.

bk

**EDIT: my clips are from build 17, 20 and 21.

OSX 10.6.2, Color V 1.5.1
 
Last edited:
OK, what am I doing wrong....? It's installed correctly as far as I can tell. It shows version 4.0 beta when there under the RED tab. Yet none of the controls on the RED tab are enabled and I can't check to enable them. So far I have just loaded some older clips - shot with build 18. Clips were shot in 3K for some overcranking. I'll check a few 4K clips now and see what's up.

Oh, wait. I see Brandon is reporting the same issue...
 
Keying in secondaries still behaves unexpectedly. It seems the keyer works from the footage without the red tab metadata processing applied, meaning you are trying to key from very low contrast footage with little colour separation and saturation.

It makes sense going back to source footage for keys but shouldn't the RED tab metadata be treated as part of the footage, rather than treated as if it were a grade.

This problem means that for projects that need key based qualification the red -> colour workflow is not a viable option
 
Brandon: are you sending it from FCP using QT reference files? It's possible I borked something in the build

Jeff: are you doing a similar thing or are you loading R3D's straight into Color?
 
Keying in secondaries still behaves unexpectedly. It seems the keyer works from the footage without the red tab metadata processing applied, meaning you are trying to key from very low contrast footage with little colour separation and saturation.

It makes sense going back to source footage for keys but shouldn't the RED tab metadata be treated as part of the footage, rather than treated as if it were a grade.

This problem means that for projects that need key based qualification the red -> colour workflow is not a viable option

Daniel: you'll have to contact Apple on that one I'm afraid. We just hand off the image to Color.
 
Any chance of seeing the FLUT & the Shadows dial in Color?
 
I have same problem as Jeff and Brandon- 4k footage from b19 (I think?), tried sending from FCP using QT ref and log and import method, in both cases I see the tab but all options greyed. Footage is viewable, but RED tab is DOA.

using Snow Leopard, Color and FCP up to date.
 
Rob,

It works if I import the R3Ds directly into Color. If I have QT-wrapped native clips in FCP and Send To Color, it does not work -- no RED tab. Also, it seems that playback speed is seriously slow now with native clips sent over.
 
Keying in secondaries still behaves unexpectedly. It seems the keyer works from the footage without the red tab metadata processing applied, meaning you are trying to key from very low contrast footage with little colour separation and saturation.

It makes sense going back to source footage for keys but shouldn't the RED tab metadata be treated as part of the footage, rather than treated as if it were a grade.

This problem means that for projects that need key based qualification the red -> colour workflow is not a viable option

Exactly. It's an issue with Color. Secondaries should be keyed on the image after the RED tab and even after Primaries but they're not. This is described clearly in the Color manual. For this reason, it can be a good idea to bake in a basic white balance and grade DPX's, especially if footage was shot under tungsten lighting. You'll get much better control over secondary qualifiers.
 
Brandon: are you sending it from FCP using QT reference files? It's possible I borked something in the build

Yes I am. I also tried loading the .R3D in directly but I can't seem to get that to work.
 
Any chance of seeing the FLUT™ & the Shadows dial in Color?

Apple have to add in the controls for that. All we do is, as Rob says, pass them the image decoded as per the settings they set.

Graeme
 
Rob,

It works if I import the R3Ds directly into Color. If I have QT-wrapped native clips in FCP and Send To Color, it does not work -- no RED tab. Also, it seems that playback speed is seriously slow now with native clips sent over.

I'm seeing the same issue. QT reference and QT wrapped R3Ds doesn't work. Importing the R3Ds directly works fine!
 
Okay, I'm pretty sure I know what went wrong with this build. I'm going to do another build over the next few hours that should fix the non-R3D loading issue.
 
Cool Rob and thanks for the work on this
 
Back
Top