Most colorists doing film targeted DI work set up in that manner, using the log images as input with no input LUT, but observing the result through a print preview LUT. There are a number of reasons for this, but one of the main ones is convenience. DI's are expected to produce multiple deliverables, only one of which is a film negative. Most color management systems (Truelight, Cinespace, etc.) are based on using a Cineon format as an input, with the target being whatever display you're looking at, and the processing being a film printing process. So by supplying a Cineon image to the output LUT, and having that LUT targeted to, say, a DLP Cinema projector but incorporating the characteristics of your chosen film recorder, intermediate stock, print stock, and lab process for the image processing, you get a very accurate preview of the film print. When you remove that LUT - in other words, render without baking it in - you get a Cineon image that will record correctly and print correctly, just as you previewed it. But you can also use a different targeted LUT - incorporating the same image characteristics, but designed to be displayed on, say, an HDTV monitor - to generate your electronic deliverables. By putting the LUT on the output, you don't have to be concerned with different grading for these different products because the source file is always the same. Since most DI's are still film targeted, this is the way most colorists are used to working. As DI's become more digital cinema centric, that path changes, but the idea of using the LUT on the output rather than the input remains - it's just that the LUT is used for deliverables other than the primary one, which in that case would be the DCDM.Originally Posted by Gunleik Groven
BTW, most of the software systems - with the notable exception of DaVinci's - have scaled their "log" controls to values expected from log originals, and therefore can offer good separation of controls for the desired control ranges, and real-world usefulness and feel for the exposure/contrast controls. If you've ever put data through a DaVinci 2K, you probably found that the "lift" trackball becomes rather useless, and the interaction and crossover range between the "gamma" trackball and the "gain" trackball is wildly different than with a video original. In fact, the gamma trackball becomes your primary control, and only by using additional layers (via PowerWindows) do you regain a usable range for the blacks and whites separately. I don't know if Resolve works the same way, but it wouldn't surprise me if it did since that was the world the original designers came from.
Graeme could go into a lot more detail on this, but suffice it to say that Redlog was designed purely as a way of getting the 16 bit processed linear light information into a 10 bit container while retaining the best precision in the process. RedlogFilm is designed to represent print density, based on the Cineon format. Graeme has always felt that print density does not represent the best way to retain precision from a linear light original, and mathematically he's probably right. But it does represent a standard way of working in the real world of film targeted DI's, and therefore drops into existing color grading systems in a much more sensible way. I don't know if he's done anything as far as the color matrix goes to accommodate the somewhat different gamut of film (I don't see a new RedFilmColor matrix, at least not yet), so in that sense it's a bit incomplete, but certainly using the print density values will go a long way to making film targeted DI systems work a lot better with Red originals.Looking at how redlogFilm works - and resonating along the lines that redlogFilm is more "right/standard" I start to maybe see why you have expressed some dislike for redlog. RedlogFilm seems to handle the latitude in the files in a much "smarter" way, for one...
