Complete Workflow using Matrox MXO

[Kaku Ito]

I came up with new workflow using MXO.

1. Open R3D files with Clipfinder.

2. You can set it so the Loupe window (for the edit look function) display on the MXO desktop, so the Loupe window gets displayed on your video monitor.

3. You can edit the metadata while you see the results on the video monitor with MXO.

4. Now drag the clips you need to FCP for proxy editing.

5. You can set up FCP's video output as digital cinema desktop with MXO. Why not the mastering mode? I'll tell you why later.

6. Use 1K size proxies for editing offline, it is efficient and MXO (or open timeline) enlarges to HD on the video monitor. You'll be able to have joy of editing watching good enough quality with proxies using MXO.

7. Now, if you see some clips are not quite matching in color, then go back to the Clipfinder, adjust the metadata, then RSX gets saved, conduct "Make QuickTime" so the look gets burnt to the proxy.

8. You can go back to FCP then the look gets updated automatically. At this point you will notice that by switching between FCP and Clipfinder, the video monitor switches very quickly without rescanning. If you have the FCP video out as mastering mode, it takes few seconds for the monitor to switch the mode and that gets really annoying if you are using CRT, that is the reason why I suggest to use the digital cinema desktop mode (correction, unfortunately, I found that the digital cinema desktop mode with MXO ends up in gamma shift, so I'd recommend to use the mastering mode instead. I will report this to Matrox and ask them to come up with the solution).
9. After editing, you can save the timeline as XML. You can use the XML to load only used R3D files to Clipfinder, so upon further metadata color editing, you can easily find the clips you need in the list.

10. You can have both FCP's timeline and the list of used R3D on the Clipfinder, switching back and forth, you can fine tune the look of the clips with Cllipfinder, conduct make QT, go back to FCP and play the timeline right through.

11. After finishing the edit and the one light grading, export the XML again, then I open up the Monkey Extract, go to the rendering page, read the XML, locate the original R3D file location, set it up so it reads each RSX from the clips, then render to DPX to hand them to the compositing people, also for the video finish, conveniently render to QT 444 or 10-bit 422, ProResHQ, or whatever you like. The rendering result look identical to what you were monitoring through MXO/Clipfinder, when you place the QT clips on the FCP.
Because of this method, I found out that Apple Color changes the look just by bringing R3D natively. It wasn't the gamma shifting issue, because I couldn't compensate it via gamma change calculation.

*This way, you can really accelerate the rendering with more robust CPU usage of Monkey Extract's rendering, more over, you can utilize the renderfarm function when you purchase the multiple license version of the Monkey extract.

*At this point, Monkey Extract uses more robust support on the RED SDK, where Apple Color doesn't provide OLPF compensation. Result looks a lot sharper on the Monkey Extract than Color rendering.

After rendering with Monkey extract, you can use the XML that Monkey Extract generate to comform back to FCP. Then you've got a lot sharper images on your QT, then you can do more color grading with Apple Color. Of course, you can set the Color to monitor the picture on MXO and your video monitor.

 

[Loren White]

I have been basically using this method with my MXO. I have also been happy with the results.

I noticed you said

"Because of this method, I found out that Apple Color changes the look just by bringing R3D natively. It wasn't the gamma shifting issue, because I couldn't compensate it via gamma change calculation."

Sounds like your are recommending bringing DPX's into Color via Monkey Extract?

So Color is causing an actual gamma shift when sending to Color from FCP using the proxy method? and it is not a monitoring issue?

 

[Luca Immesi]

Hi Kaku, it looks very interesting but why can't we use only clipfinder for dpx output?

 

[Meryem Ersoz]

Kaku's workflow allows for secondary color grading in Color, Clipfinder's integration with RA only allows one-light or primary grading.

I'm interested in trying this out.

 

[Kaku Ito]

I have been basically using this method with my MXO. I have also been happy with the results.

I noticed you said

"Because of this method, I found out that Apple Color changes the look just by bringing R3D natively. It wasn't the gamma shifting issue, because I couldn't compensate it via gamma change calculation."

Sounds like your are recommending bringing DPX's into Color via Monkey Extract?

So Color is causing an actual gamma shift when sending to Color from FCP using the proxy method? and it is not a monitoring issue?

Hello, on the Apple Color part, I'm saying that the current Color adoption of RED SDK is not treating the metadata the same way as others like Clipfinder , Monkey Extract and other RED apps. Try to read one R3D, change ISO, render out in the Color and Monkey Extract for say. What you see while you are grading and the rendered image look consistent in apps like Monkey Extract, but Color would give you different look in luminance level just by bring in to Color.

Color shows RGB material in gamma 1.8. So in case of proxy method, you'd have to apply 0.810810 to make it look 2.22. Then if you are rendering to QT, leave it and burn the change, but DPX, set the value back to 1 before rendering.

 

[Kaku Ito]

Hi Kaku, it looks very interesting but why can't we use only clipfinder for dpx output?

Of course you can, but I'm finding Monkey Extract more flexible in ways of rendering.

 

[Kaku Ito]

Kaku's workflow allows for secondary color grading in Color, Clipfinder's integration with RA only allows one-light or primary grading.

I'm interested in trying this out.

Meryem, I don't even open RA any more because Clipfinder's "edit look" gives me pretty much the same, but you can also display RA on MXO to monitor the picture.

As you sorted out for my long sentence, to make things clearer, I'm saying that by not using Color's RED metadata to develop, I'm getting better picture and consistent result. Even Monkey Extract's half-high looks more detailed than Color, because of the OLPF. So, give it a try!

 

[Michael Cinquin]

how about RedCine ?

how about RedCine ?

for steps #10 and #11 (getting dpxs from the r3d files), wouldn't RedCine be better (more options / nice interface to make a "pre-development" of r3ds / great flexibility) ?

Plus an advantage of sending the whole timeline to RedCine and rendering the clips as dpxs, is that there is no more conforming involved afterwards on the color-grading suite (there are no more clips, just a dpx sequence of the whole editing).

Crimson workflow or the red tool on my website would do the trick to send the fcp timeline right into RedCine.

 

[Kaku Ito]

Michael,

I do use REDCINE with MXO and Crimson depending on the client, especially when multiple edits are used from one clip with different metadata settings.

But this workflow has these advantages. First, you are fine tuning the look of the clip from the ground, so your FCP timeline would look closer to how it should look. Also when you just open the clips with QT, it'll have the look edited.

Monkey Extract has wider control in rendering. REDCINE does not provide render farm nor the control in setting up the CPU usage.

I wish REDCINE can save the RSX then I'd use it for metadata editing.

 

[Luca Immesi]

I'd like to stay with clipfinder all the process. About the output codec: what is QT 444? Aja, Blackmagic,,Raw? Color has problems with 25 fps DPX (actually monkey extract has the fix), do you think we could use other codecs without gamma shift between applications with this workflow?