utecmifpa pt2 — Fusion Usement

The last article was heavy on theory and light on practice. Fusion users, here's a more concrete how-to.

Let's say you have a shot with a Cineon plate, a linear EXR image, and a video-space (sRGB) JPEG. You want to comp them all up real nice in Fusion in linear color space, because you are S. M. R. T.

(to make this example less highly pathetical, get yerself a Cineon plate, a linear EXR image, and a video-space sRGB JPEG, if you don't already have some of your own)

OK, so lin is where you want these images to be, so you'll be looking to the *2lin Macros. We'll chose the straight gamma version of linear for our example.

The EXR is already linear, so it needs no help from us. Add it to your comp with a Loader and display it in a viewer.

It should look dark. Right click in the viewer and select Display LUT > Edit. Enter a Gamma of 2.2. Now the EXR should look correct.

What you have just done is implement a linear color workflow! Crazy.

Now add your JPEG. It has a gamma of 2.2 burned into it. It would look fine in that viewer if we hadn't set the gamma to 2,2. But we did. So let's add a Tools > Macros > eLin_vid2lin tool after the Loader to convert our vid image to linear space. The Macro will promote the image to float automatically in the process.

The only control in vid2lin is Gamma. This value refers to the inherent gamma of the input image. You'll very rarely need to change this from the default of 2.2.

Now the Cineon. Load that puppy into your comp. Fusion will, by default, try to Lin to Log the image for you right in the loader. Bypass this with the Bypass Log to Lin checkbox under the Format tab.

Displaying the log pixels under our 2.2 view LUT will make for a heinously bright image, so add a Tools > Macros > eLin_log2lin tool after the Loader.

There are two controls in eLin_log2lin — Conversion Gamma and Gamma. Both should match the view gamma, so again, you'll probably never mess with the default of 2.2. (The only reason these are two sliders instead of one is a silly omission of publishability in the Fusion Cineon Log tool. The two sliders should always have the same value.)

Now we have linear, log, and vid images all united in one linear color space, and a view LUT that makes them look correct.

Word. Comp away.

Now, when the time comes to output, you need to use the lin2* tools. Tools > Macros > eLin_lin2vid for video space output (such as TIFF, Targa, etc.), and Tools > Macros > eLin_lin2log for Cineon log.

eLin_lin2vid has one control, Gamma, and it really is as simple as a the gamma in a BC tool. Again, you'll very rarely set it to anything other than 2.2.

eLin_lin2log has the same dual sliders as log2lin. You'll never guess what they default to.

If you load a gamma 2.2 image, vid2lin it and then lin2vid it, it will roundtrip unharmed. Same with log and the log2lin/lin2log pair.

The “looks right” state of a Cineon log image (log2lin followed by a lin2vid or the 2.2 view LUT) is based on the standard Kodak conversion with a Dispamma of 1.7/2.2.

Try it. It's way less crazy than it sounds, it will make your work look better, and with the view LUT set to 2.2, you will always know that when things look right in your viewer, they are linear and happy.

Comments

[isotropy]

I just went through these instructions today. I'm kind of confused at the end... After we have all of our merges, and we're going to output back to film, I've never onverted my images back to log.

I'm not sure why we'd need to use the eLin_lin2log and then save it... Why can't we just save right out of the last merge?

Thanks. :)

[Stu]

Most film pipelines want the input and the output to match. So if you got log Cineon scans in, you'd want to send log Cineons back to your filmer.

-Stu

[Swerve]

Hey Stu

great work on those macro's and the explanation behind them. I was doing some testing with log to lin conversions using primarly shake and nuke and seemed that to get an exact log file out you need to convert the image back to 16 bits after your lin to log conversion. A simple compare node with the orginal cineon plate and the comp in float proved that they weren't identical. Any ideas behind this? Does the lin2log need a bytes node after it set to 16 bits for optimal image quality before going out to cineon?

thanks bro.

[Stu]

Glad you're digging the nerdly goods swerve! Since most often you're lin2log-ing right before saving out to .cin where you're quantizing to 10bpc, I'm imagining the bytes call would be redundant — but I could be wrong, as I have not tested this.

[Joe]

Hey Stu,

I went through your instructions, and I'm wondering what the difference is between your macros and just letting Fusion handle it on its own.

IE: I piped in a Cineon file into your eLin_cin_log2lin macro, then compared it to a copy of the footage brought in with Fusion's default settings. The results were identical.

[Stu]

Hi Isotropy,

That's correct, the eLin_cin_log2lin is identcal to Fusion's default settings. The advantage of the macros comes when you want to get video-space images into thet same color space. eLin_cin_vid2lin does that.

Similarly, the macros without the _cin_ in the name are simple in the vid cases (just a gamma 2.2 or inverse), but more complex in the log cases.