Which do colorist prefer - Cineon or rec709 for DPX write going to grading ?

[PatrickFaith]

I will be sending to color grading after compositing a DPX file. I have a choice in nuke to either do cineon or rec709 when I save to the dpx files.

I was wondering what colorists prefer?

 

[Gunleik Groven]

If you are to do a full grade with the composite and have headroom to match it with other shots and the composite itself is colormatched in the elements, I have a hard time seeing why you wouldn't go linear or cineon DPX 16-bit out of Nuke.

If the thing is "finished" in Nuke and that's it and you're happy.

Well... then you are.

 

[PatrickFaith]

If you are to do a full grade with the composite and have headroom to match it with other shots and the composite itself is colormatched in the elements, I have a hard time seeing why you wouldn't go linear or cineon DPX 16-bit out of Nuke.

If the thing is "finished" in Nuke and that's it and you're happy.

Well... then you are.

Your right, so for the colorist working in something like baselight or davinci, would you prefer dpx/cineon or dpx/rec709 coming from nuke? Currently the nuke node is set at cineon 10 bit, I'm just looking for what the best nuke node write settings should be for dpx output going to the colorist(whom hasn't been contracted yet).

 

[Gunleik Groven]

Cineon

 

[David Mullen ASC]

Isn't Cineon a log gamma, so how is that different than RedLogFilm?

 

[PatrickFaith]

Cineon

Thanks much, cineon 16 bit then - should that be "big endian" ?

Thanks

---
nuke node :

set cut_paste_input [stack 0]
version 9.0 v7
push $cut_paste_input
Write {
file /../Volumes/Pudl_1/pudl/the_film/comp//P025_C006_0811UK/nuke/renders/P025_C006_0811UK_comp_v04.%04d.dpx
file_type dpx
datatype "16 bit"
first 0
last 62425
checkHashOnRead false
version 2
name Write_dpx
selected true
xpos -464
ypos 1208
}

 

[PatrickFaith]

Isn't Cineon a log gamma, so how is that different than RedLogFilm?

I think this question is to Gunleik, I have no idea.

[if know one knows, I'll send that question over to the foundry, how they setup up their redlogfilm write node]

 

[Gunleik Groven]

Isn't Cineon a log gamma, so how is that different than RedLogFilm?

RedLogFilm is Cineon gamma. According to Graeme, it's the only camera-gamma out there which is fully Cineon compliant, while s-log, LOG-C etc, are dialects of the Cineon description.

 

[Derek Morrison]

Am I right in saying that Davinci still won't read 16-bit DPX Gunleik?

 

[Christoffer Glans]

Cinnamon


(Had to leave it there, my phone autocorrected it :biggrin: )

But yeah, Cineon. Easier to match up before setting a look.

 

[PatrickFaith]

RedLogFilm is Cineon gamma. According to Graeme, it's the only camera-gamma out there which is fully Cineon compliant, while s-log, LOG-C etc, are dialects of the Cineon description.

I noticed that "gone girl" did 10 bit dpx with redlogfilm, so I'm thinking that is almost the same thing as 10 bit dpx with cineon? One thing I do is basically copy as much as it makes sense ... lightiron and D. Fincher workflows.

 

[Blair S. Paulsen]

Cineon is the standard and is the basis for RLF. Log encoding is typically used to stuff 16 bits of linear information into a 10 bit log container with negligible loss of precision.

Most grading apps work best with 10bit log DPX.

Rec 709 is a horrible nightmare that should only be used when there is no other option.

Cheers - #19

 

[PatrickFaith]

Cineon is the standard and is the basis for RLF. Log encoding is typically used to stuff 16 bits of linear information into a 10 bit log container with negligible loss of precision.

Most grading apps work best with 10bit log DPX.

Rec 709 is a horrible nightmare that should only be used when there is no other option.

Cheers - #19

Thanks much Blair, I'll go 10bit. Editing btw wants Apple ProRes 444, so I will also make sure that I use the cineon option for prores as well as dpx (so I'm not creating some color nightmare as the files are moving around).

BTW the new foundry editor "Studio" does prores on windows now(i need to test this), also I've noticed the Prores encodes the anamorphic 4k in a nice compact format yet displays realtime on my macpro.

EDIT based on testing:

I confirmed prores 444 works perfectly under nuke9 on windows 7. I tested reading and writing within nuke anamorphic 4k prores. I was also able to generate 4k anamorphic prores on windows and send it to my mac side with no problems.

Outside Nuke, I did notice that the general windows quicktime program doesn't show anamorphic 4k correctly though (that is if you copy a anamorphic 4k prores to some random windows machine, and run it with that default quicktime program ... it doesn't use the pixel dimension information).

 

[M Most]

Cineon is the standard and is the basis for RLF. Log encoding is typically used to stuff 16 bits of linear information into a 10 bit log container with negligible loss of precision.

Most grading apps work best with 10bit log DPX.

Rec 709 is a horrible nightmare that should only be used when there is no other option.

Rec 709 is hardly a "horrible nightmare." It is a display referred color space that is used for displaying images with proper contrast and color on "standard" HD monitoring devices. That makes it very appropriate as a display or delivery color space. Log encoding (be it Cineon, Redlogfilm, Arri LogC, Sony Slog3, or any other log definition) is a container that is designed to hold a much higher dynamic range of values in order to allow for transforms into display color spaces with selective amounts of contrast and detail to better represent the real world image. Log encoded files are not meant to be looked at because they don't represent "normal" human perceptions of color and contrast. They are intended to purely store values that allow for flexibility in recreating real world images.

This principle is understood by very, very few people here and elsewhere, many of whom look at a log coded image and say "oh, that's great, it's nice and flat so I can grade it." Wrong. It's flat and has low chroma because it isn't in a proper display colorspace, and requires transforms to get to that. It should not be used as a starting point for "hand grading" unless there are proper transforms involved to both restore proper contrast (while still allowing the colorist to control exposure) and proper saturation and color representation (usually requiring a properly designed matrix transform). In the world of Red, the Redcolor/Dragoncolor settings select the matrix transform (it's baked into the result) and the Redgammas yield proper contrast. Using Redlogfilm allows you to adjust the contrast and exposure of the displayed result with more control, but to get the most accurate results, a properly designed LUT or properly designed luminance curve needs to be applied. Using lift gain gamma type approaches will not properly transform what is essentially a Cineon log coding into a sensible contrast for most current display targets. If you're good and experienced you might be able to "fake it" using such an approach, but you cannot create proper contrast through the entire image without using a "de-log" step that somewhat reverses the log encoding. Lift, gain, and gamma don't do that as those operations were and are designed for dealing with gamma encoded video, not log encoded images.

With respect to the original topic in this thread, using Redlogfilm gives you more control over the displayed result because you're starting with more information and more manipulative capability. But unless you understand what it is you're dealing with, and how to properly deal with it, you're better off with one of the Redgammas because that will give you a starting point with proper display contrast already established, albeit at the cost of flexibility in terms of exposure correction and some detail recovery.

 

[PatrickFaith]

...

This principle is understood by very, very few people here and elsewhere, many of whom look at a log coded image and say "oh, that's great, it's nice and flat so I can grade it." Wrong. It's flat and has low chroma because it isn't in a proper display colorspace, and requires transforms to get to that. It should not be used as a starting point for "hand grading" unless there are proper transforms involved to both restore proper contrast (while still allowing the colorist to control exposure) and proper saturation and color representation (usually requiring a properly designed matrix transform). In the world of Red, the Redcolor/Dragoncolor settings select the matrix transform (it's baked into the result) and the Redgammas yield proper contrast. Using Redlogfilm allows you to adjust the contrast and exposure of the displayed result with more control, but to get the most accurate results, a properly designed LUT or properly designed luminance curve needs to be applied. Using lift gain gamma type approaches will not properly transform what is essentially a Cineon log coding into a sensible contrast for most current display targets. If you're good and experienced you might be able to "fake it" using such an approach, but you cannot create proper contrast through the entire image without using a "de-log" step that somewhat reverses the log encoding. Lift, gain, and gamma don't do that as those operations were and are designed for dealing with gamma encoded video, not log encoded images.

With respect to the original topic in this thread, using Redlogfilm gives you more control over the displayed result because you're starting with more information and more manipulative capability. But unless you understand what it is you're dealing with, and how to properly deal with it, you're better off with one of the Redgammas because that will give you a starting point with proper display contrast already established, albeit at the cost of flexibility in terms of exposure correction and some detail recovery.

Thanks Mike, hmmm ... for my workflow I have to read into nuke everything in linear for the vfx compositing, that way I avoid the de-log step. So I am doing everything on my r3d in linear (technically I use dragon 2 linear ... nuke btw now supports dragon 2, I'm not sure that makes a difference though). Here's a jpeg of a shot, there is a moving "water" chicken and a "water" egg dropping down, what's important for me isn't so much that the color is right, it's that the vfx color and the r3d color are matching up perfectly(i think the color is matching up real well on this vfx shot, is a jpeg ... i couldn't for some reason upload a dpx into my web blog area).

 

[M Most]

Thanks Mike, hmmm ... for my workflow I have to read into nuke everything in linear for the vfx compositing, that way I avoid the de-log step. So I am doing everything on my r3d in linear (technically I use dragon 2 linear ... nuke btw now supports dragon 2, I'm not sure that makes a difference though). Here's a jpeg of a shot, there is a moving "water" chicken and a "water" egg dropping down, what's important for me isn't so much that the color is right, it's that the vfx color and the r3d color are matching up perfectly(i think the color is matching up real well on this vfx shot, is a jpeg ... i couldn't for some reason upload a dpx into my web blog area).

Working in linear light is very common for VFX because it is a colorspace in which the physical properties of light are maintained, allowing you to do exactly what you just described. It is not, however, a common color space for color grading because even though it is linear (i.e., it is accurate to real world physics), it is not perceptually linear. Because of that, grading controls do not feel "normal," so log color spaces (or gamma encoded spaces if you like to use lift, gain, gamma type controls) are generally preferred for that function.

 

[PatrickFaith]

Working in linear light is very common for VFX because it is a colorspace in which the physical properties of light are maintained, allowing you to do exactly what you just described. It is not, however, a common color space for color grading because even though it is linear (i.e., it is accurate to real world physics), it is not perceptually linear. Because of that, grading controls do not feel "normal," so log color spaces (or gamma encoded spaces if you like to use lift, gain, gamma type controls) are generally preferred for that function.

Thanks, gotcha, will send to editing&grading in log space using cineon.

 

[Martin Stevens]

Rec 709 is hardly a "horrible nightmare." It is a display referred color space that is used for displaying images with proper contrast and color on "standard" HD monitoring devices. That makes it very appropriate as a display or delivery color space. Log encoding (be it Cineon, Redlogfilm, Arri LogC, Sony Slog3, or any other log definition) is a container that is designed to hold a much higher dynamic range of values in order to allow for transforms into display color spaces with selective amounts of contrast and detail to better represent the real world image. Log encoded files are not meant to be looked at because they don't represent "normal" human perceptions of color and contrast. They are intended to purely store values that allow for flexibility in recreating real world images.

This principle is understood by very, very few people here and elsewhere, many of whom look at a log coded image and say "oh, that's great, it's nice and flat so I can grade it." Wrong. It's flat and has low chroma because it isn't in a proper display colorspace, and requires transforms to get to that. It should not be used as a starting point for "hand grading" unless there are proper transforms involved to both restore proper contrast (while still allowing the colorist to control exposure) and proper saturation and color representation (usually requiring a properly designed matrix transform). In the world of Red, the Redcolor/Dragoncolor settings select the matrix transform (it's baked into the result) and the Redgammas yield proper contrast. Using Redlogfilm allows you to adjust the contrast and exposure of the displayed result with more control, but to get the most accurate results, a properly designed LUT or properly designed luminance curve needs to be applied. Using lift gain gamma type approaches will not properly transform what is essentially a Cineon log coding into a sensible contrast for most current display targets. If you're good and experienced you might be able to "fake it" using such an approach, but you cannot create proper contrast through the entire image without using a "de-log" step that somewhat reverses the log encoding. Lift, gain, and gamma don't do that as those operations were and are designed for dealing with gamma encoded video, not log encoded images.

With respect to the original topic in this thread, using Redlogfilm gives you more control over the displayed result because you're starting with more information and more manipulative capability. But unless you understand what it is you're dealing with, and how to properly deal with it, you're better off with one of the Redgammas because that will give you a starting point with proper display contrast already established, albeit at the cost of flexibility in terms of exposure correction and some detail recovery.

Great post Mike! Thanks.

I have never seen this info presented so well..... ever!

Your posts are some of my all time favorites here on RedUser.

 

[Marc Wielage]

Using lift gain gamma type approaches will not properly transform what is essentially a Cineon log coding into a sensible contrast for most current display targets. If you're good and experienced you might be able to "fake it" using such an approach, but you cannot create proper contrast through the entire image without using a "de-log" step that somewhat reverses the log encoding. Lift, gain, and gamma don't do that as those operations were and are designed for dealing with gamma encoded video, not log encoded images.

Well, you can do it with curves in my experience. It helps to have cameras shooting charts, but that doesn't happen very often.

 

[M Most]

Well, you can do it with curves in my experience. It helps to have cameras shooting charts, but that doesn't happen very often.

Well, yes. I already said that. To quote my previous post:

but to get the most accurate results, a properly designed LUT or properly designed luminance curve needs to be applied...

The entire point of my post was that applying a de-log operation - be it via LUT or curve (essentially the same thing if we're talking about a 1D operation) - is fundamentally different than simply applying extreme lift, gamma, and gain settings in an attempt to somehow recreate what the proper greyscale should be.