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

[Blair S. Paulsen]

Evidently I should have specified that a display LUT appropriate to the display you are viewing would be in the appropriate location in the editor's signal chain by default.

In any case, My point was that you don't want to create transcodes for later color work that have rec 709 baked in during export.

@Mike - my distaste for rec 709 might have been a bit too strongly worded ;-). That said, I've never liked the shape of it's gamut, but that's another thread.

Cheers - #19

 

[Stacey Spears]

That said, I've never liked the shape of it's gamut, but that's another thread.

Gamut or gamma? When I think of gamut, I think size or volume, not shape.

 

[Blair S. Paulsen]

When I say gamut...

When I say gamut...

I consider the impact of gamma on color reproduction as part of the transformation process that has an effect on the "available" portions of the theoretical gamut.

I imagine a color cube in 3D space with a "blob" floating inside the cube that represents the color space parameters. Since rec 709 struggles to display certain colors I imagine that blob looks like it has some hollows in it, which could push two colors with very similar spectral information in the original camera data too far apart.

For instance: if one pixel has code values 233R, 786G, 465B and the other is 244R, 788G, 457B they should both "read" about the same at display, but if one of those values is in the "indentation" in the "blob" - and the other is not - you have a shift. That's just how I happen to visualize it.

Cheers - #19

 

[PatrickFaith]

I consider the impact of gamma on color reproduction as part of the transformation process that has an effect on the "available" portions of the theoretical gamut.

I imagine a color cube in 3D space with a "blob" floating inside the cube that represents the color space parameters. Since rec 709 struggles to display certain colors I imagine that blob looks like it has some hollows in it, which could push two colors with very similar spectral information in the original camera data too far apart.

For instance: if one pixel has code values 233R, 786G, 465B and the other is 244R, 788G, 457B they should both "read" about the same at display, but if one of those values is in the "indentation" in the "blob" - and the other is not - you have a shift. That's just how I happen to visualize it.

Cheers - #19

I think your right, what I have noticed if I round trip a lot doing batch composites in nuke, is the color spaces slowly goes wonky if I am doing anything but exr 16 bit float linear. It's also far worse if i do this wrong in round tripping, because it's not a simple linear color shift that is occurring, it's more like a subsection of bits that slowly are shifting in one direction or another on the color wheel. For final editing I'm btw really liking prores 444, it's so much easier to organize then a ton of dpx files in folders(about 5x smaller too). I've also noticed in big shops that they are mixing dpx and prores in there timelines, I really need to learn proper prores workflows for feature film.

 

[Marc Wielage]

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

David is right, as usual. DPX can be Log every bit as much as Cineon or even Pro Res. There is virtually no difference at a high enough level.

As to 16-bit, I think it's gross overkill, but here's what BMD says:

Bit Depth: Resolve can decode R3D files with 8-, 10-, or 16-bit image data for processing. Choosing 16-bit for maximum quality may impact playback performance on some hardware.

To my knowledge, you can't monitor in anything higher than 10-bit out of Resolve, but again, the number of displays higher than 10-bit is very rare.

There's a huge difference between 8-bit and 10-bit, but there's a point of vanishing returns above that, IMHO.

For final editing I'm btw really liking prores 444, it's so much easier to organize then a ton of dpx files in folders(about 5x smaller too). I've also noticed in big shops that they are mixing dpx and prores in their timelines, I really need to learn proper prores workflows for feature film.

I don't think ProRes 444 workflows are that complicated. They're used every day in LA and NY for network TV series, and it generally works very well. I think the key is to get everybody on the same page in terms of monitoring, calibration, and gamma curves so there are no surprises.

There is technically an uncompressed form of QuickTime, QuickTime Animation, but Resolve can't play them and it's ridiculously huge in terms of file size. DPX is actually easier to deal with. For a modest-budgeted indie project, I think going ProRes HD 444 all the way or even 4K ProRes can work very effectively.

 

[Blair S. Paulsen]

I think there's a case to be made for using ProRes444, in RLF, as the format for color work. If you have fast Apple hardware and a decent RAID you should be able to get satisfaction in terms of responsiveness. If you dig FCPX, you're probably already there.

Cheers - #19

 

[Gunleik Groven]

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



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.

Mike. Your points are well put and I hope you'll post more here again in the future.
It's always great and precise input from you.

 

[Björn Benckert]

I think your right, what I have noticed if I round trip a lot doing batch composites in nuke, is the color spaces slowly goes wonky if I am doing anything but exr 16 bit float linear. It's also far worse if i do this wrong in round tripping, because it's not a simple linear color shift that is occurring, it's more like a subsection of bits that slowly are shifting in one direction or another on the color wheel. For final editing I'm btw really liking prores 444, it's so much easier to organize then a ton of dpx files in folders(about 5x smaller too). I've also noticed in big shops that they are mixing dpx and prores in there timelines, I really need to learn proper prores workflows for feature film.

I don't know the correct output settings for nuke my self, the guys at work do. But it´s essential to get all the parameters right or your stuff will drift. It´s as I understand quite complicated to get it right as the guys at the office keeps coming back doing this mistake. I don't know exactly how it works but nuke reads the dpx header a bit different than for example flame and cineon (that created the format) so it´s important to set all parameters right. The best way to check it is to create a "round trip loop" with difference matte in the end. And before you got no difference you simply got some parameters wrong in your import node or export node. Compared to using quicktime / proress dpx files are a bit sketchy as they got so much in their header and if not treated right different applications will interpret the footage differently. You can look at it as 16 bit tifs are just 16bit tifs and then the rest need to be sorted with downstream nodes but the DPX got tags in their header that some software reads and treats the content accordingly but some softwares does not follow that protocol.

But I préfère dpx for short format / compositing work. We do master in progress 444 most of the time. But also the quicktime protocols are quite sketchy with different look files applied when looking at the material on different computers and so on. don't really know the background off that but as I understand quicktime, in some applications and depending of how the quicktime applications are installed, bakes in the screen icc file into the quicktime renders. So having a proress file and simply rendering a new proress file from it very much alter and some times clips the color of the given file... which is not right in my book, so same thing apply when dealing with quicktimes. Important to check so your procedure does not alter the image in a way it should not.

 

[PatrickFaith]

I don't think ProRes 444 workflows are that complicated. They're used every day in LA and NY for network TV series, and it generally works very well. I think the key is to get everybody on the same page in terms of monitoring, calibration, and gamma curves so there are no surprises. There is technically an uncompressed form of QuickTime, QuickTime Animation, but Resolve can't play them and it's ridiculously huge in terms of file size. DPX is actually easier to deal with. For a modest-budgeted indie project, I think going ProRes HD 444 all the way or even 4K ProRes can work very effectively.

Your right, I think a big thing for a Indie project like mine that is taking a long time is just being consistent and staying organized. I'm really liking the 4k anamorphic prores for editing. Also with weapon coming along I think I'm just going to put a nail down and do all my editing in 4k Ana Prores 444.

I think there's a case to be made for using ProRes444, in RLF, as the format for color work. If you have fast Apple hardware and a decent RAID you should be able to get satisfaction in terms of responsiveness. If you dig FCPX, you're probably already there.

Cheers - #19

Currently i've been mixing the prores with DPX, but I like your idea of just sticking with one format. My raid is over 2 gigabyte per second on reads/writes so i'm fine there. If anything my main problem is just keeping organized and doing regular backups, so the prores just makes that easier. As I'm doing more of my editing in prores, also with the weapon coming along, I really like the idea of sending to the colorist prores files.

I don't know the correct output settings for nuke my self, the guys at work do. But it´s essential to get all the parameters right or your stuff will drift. It´s as I understand quite complicated to get it right as the guys at the office keeps coming back doing this mistake. I don't know exactly how it works but nuke reads the dpx header a bit different than for example flame and cineon (that created the format) so it´s important to set all parameters right. The best way to check it is to create a "round trip loop" with difference matte in the end. And before you got no difference you simply got some parameters wrong in your import node or export node. Compared to using quicktime / proress dpx files are a bit sketchy as they got so much in their header and if not treated right different applications will interpret the footage differently. You can look at it as 16 bit tifs are just 16bit tifs and then the rest need to be sorted with downstream nodes but the DPX got tags in their header that some software reads and treats the content accordingly but some softwares does not follow that protocol.

But I préfère dpx for short format / compositing work. We do master in progress 444 most of the time. But also the quicktime protocols are quite sketchy with different look files applied when looking at the material on different computers and so on. don't really know the background off that but as I understand quicktime, in some applications and depending of how the quicktime applications are installed, bakes in the screen icc file into the quicktime renders. So having a proress file and simply rendering a new proress file from it very much alter and some times clips the color of the given file... which is not right in my book, so same thing apply when dealing with quicktimes. Important to check so your procedure does not alter the image in a way it should not.

Great info. One thing I've finally done is standardized on vfx roundtrip formats more fanatically, so all my nuke comp files are now in linear exr 16 bit float. I am btw using the 16 line compression setting and the 4k files are about 20% of the size of the dpx files. Also I was just getting into too much problem doing slightly different things with dpx for my comps, by staying linear through the entire compositing step I hope to avoid some of the problems I've been having.

So now its all r3d into nuke, all compositing intermediary files are exr, and output to editing is prores. I'm really liking Blair's idea on coloring, and doing that in prores which will allow me to avoid a conform. I'm also now not messing up the colors during compositing by staying in linear all the time, so the prores output is looking better. (i.e. when I screw up the color space, things are more recoverable in dpx, but of course it's much better for me to not mess things up and do a nice clean prores output from compositing and editing to grading)

Thanks for all the help guys.

 

[fred gasc]

...

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.

Exactly.