Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

"Tattoo" project notes...

Antoine Fabi said:
Thanks Erich!

What do you mean M Most ???

Antoine
Click to expand...

The ProRes444 codec gives you a 12 bit container, but more often than not, the information that's placed into that container only contains 10 bits of information, because that's what almost all video cameras are. It is also what the Cineon format is designed for. Placing 10 bits of information into a 12 bit container doesn't magically create more bit depth.
 
OK...

I was thinking about info exported from RCX in a ProRes container :)

So i assume it is 12 bit, unless someone clip info before exporting to ProRes.

Am i right ?

Antoine
 
M Most said:
I'm not Jake, but I'll take a stab at that one. Recent experience with both Epic and MX footage has shown me that using RedlogFilm with a LUT implementation as I've already described yields a better greyscale interpretation than the Redgamma2 curve, although it takes a bit of manipulation while Redgamma2 looks pretty good as is. So I guess what I'm saying is that Redgamma2 is quite good for on set and dailies use, but for more precise and flexible final grading, the RedlogFilm approach is superior.

You didn't ask, but I (and most of my colleagues in Los Angeles facilities) also tend to use Redcolor rather than Redcolor2 in final grading because Redcolor2 is a bit too desaturated for most of our taste, and it's always less destructive (i.e., less noise-inducing) to desaturate than it is to increase saturation while color grading.
Click to expand...

jake blackstone said:
There are no rules, when it comes to creative choices. Therefore, I can only speak for myself.
In case of everything being equal, I would pick the FilmLog over RedColor2 every time, as I get more range and more familiar film type grading. Just look at the FilmMaster demo at NAB 2009, that I'd posted earlier. Other then that, everything else is subjective and should be selected, based on subject matter. It's like there is a choice of film stock, that is more appropriate, then other. You want more saturated, vibrant image, choose Fuji, more subdued, it'll be Agfa and so forth. As an example, I just finished a project, that I'd used Rec-709, because the film called for dark, desaturated, moody, harsh, gainy look, that, obviously RedColor2 wouldn't deliver, without a lot of work.
And that applies to any grading solution...
Click to expand...

Thanks Mike and Jake. I appreciate your insight and value your opinions.

I'm working with footage where the dailies were all processed with REDcolor2 and REDgamma2, and from what you've said, I think I'll start my grading using REDlogFilm instead.

As for REDcolor vs. REDcolor2, the dailies had been processed with REDcolor2 and with saturation set to 1.10, which should give me a good starting place that is closer to the more saturated original REDcolor in terms of being less destructive to start with more saturation, and that should get me close to where they expect saturation to be from what they saw during dailies. My first instinct was to set the saturation back to 1.00 and grade it up from there, so I'm glad you chimed in, Mike.
 
Antoine Fabi said:
OK...

I was thinking about info exported from RCX in a ProRes container :)

So i assume it is 12 bit, unless someone clip info before exporting to ProRes.

Am i right ?

Antoine
Click to expand...

I honestly don't know. Deanan, are you doing 12 bit QuickTime exports?
 
From what I understand, the high bit depth format Quicktime exports and imports is called r4fl which is 32bit floating point. You don't provide 12bit data to prores - you give it r4fl and it compressed that as best as it knows how.

Graeme
 
Graeme Nattress said:
From what I understand, the high bit depth format Quicktime exports and imports is called r4fl which is 32bit floating point. You don't provide 12bit data to prores - you give it r4fl and it compressed that as best as it knows how.

Graeme
Click to expand...

Are any of those 32 bits reserved for the embedded alpha?
 
Stephen Strangways said:
from what you've said, I think I'll start my grading using REDlogFilm instead.
Click to expand...

Before you jump in with both feet into log grading, make sure you have your ducks in a row-proper monitor calibration, proper Log_to_lin conversion LUT and test your deliverables. It's all good, until it goes bad...
 
Stephen Strangways said:
Hey Jake, what do you think is a better approach in Resolve, between starting with REDlogFilm and doing some serious L/G/G to increase contrast from there manually or with an auto balance to start, versus starting with REDcolor2?
Click to expand...


For Resolve I would start with the RGB curves to "normalize" a REDlogfilm image. I don't think you could ever really get there using only L-G-G because of the logarithmic nature of REDlogfilm (hence the name).

For further clarification, "Tattoo" was graded without a cineon to gamma-encoded LUT. I prefer to retain control and flexibility by building that conversion into one of the layers of my grade.

On another note, I've noticed this thread moving in the "RAW > RGB" direction. While it certainly gives you more image control options, I'd like to point out that for feature films, RAW source files in the DI are rarely possible due to VFX workflow. You can't decide you like redgamma2 better four months after vfx work has been started on redlogfilm dpx's. If there is a remote chance you need to change the kelvin or ISO from what the DP set in camera, you have to do it BEFORE VFX receives media. Workflow is all about planning ahead.

Hopefully one day we'll have a widely adopted RAW-like VFX workflow. But until then use RGB and keep the RAW file in the system should you really need it (and it's not a VFX).
 
Ian Vertovec said:
For Resolve I would start with the RGB curves to "normalize" a REDlogfilm image. I don't think you could ever really get there using only L-G-G because of the logarithmic nature of REDlogfilm (hence the name).

For further clarification, "Tattoo" was graded without a cineon to gamma-encoded LUT. I prefer to retain control and flexibility by building that conversion into one of the layers of my grade.
Click to expand...


I think that's another approach, but not one to be taken by anyone without a lot of experience, as curve grades can be very, very destructive and noise inducing unless you really know what you're doing and what you're trying to achieve. For most colorists, I would recommend a 1D Cineon to Video LUT. One really easy way of obtaining one is by going to the Arri Digital website and using their online LUT builder to create one. You can export in just about any format, including those native to DaVinci, Baselight, Lustre, and Pablo. Just make sure you make a 1D LUT using extended range for both input and output and you'll be fine. The LUT that's generated will work very, very well with RedlogFilm images.

On another note, I've noticed this thread moving in the "RAW > RGB" direction. While it certainly gives you more image control options, I'd like to point out that for feature films, RAW source files in the DI are rarely possible due to VFX workflow.
Click to expand...

While that's certainly true today, I'm hoping that going forward, ACES or something like it will help to alleviate this issue.
 
M Most said:
While that's certainly true today, I'm hoping that going forward, ACES or something like it will help to alleviate this issue.
Click to expand...
FilmLight was very clear about their entry into plugin arena with their BL plugin, as was BM with their free Resolve. If VFX, like Nuke can read the BL or Resolve color settings, it can be a very powerful tool. Something like that, combined with ACES can end up being the solution, that everyone is searching for.
 
Graeme Nattress said:
From what I understand, the high bit depth format Quicktime exports and imports is called r4fl which is 32bit floating point. You don't provide 12bit data to prores - you give it r4fl and it compressed that as best as it knows how.

Graeme
Click to expand...

Hi Graeme,

In this article: http://images.apple.com/finalcutstudio/docs/Apple_ProRes_White_Paper_July_2009.pdf

....they say that Pro Res 444 is 12 bit and Pro Res 422 is 10 bit.

...so...is it reasonable to think that if i feed a 12 bit log file (let's say a untouched ungraded file RedLogFilm, or even a linear gamma) from RCX, i should not see any banding when i'll stretch it for proper contrast in a grading tool like Color for a rec709 display ?

Antoine
 
M Most said:
While that's certainly true today, I'm hoping that going forward, ACES or something like it will help to alleviate this issue.
Click to expand...

Not sure that's really something we'll ever be able to straighten out. Compositing employs so much hackery inside the RGB channels that you really have to do a RAW > RGB conversion right at the start. I'm just thinking you wouldn't want, for instance, to start keying and then have your color temperature change, nor could you preserve the original RAW data through a de-spill operation.

Which isn't to say there isn't room for improvement in the current tools.
 
But ProRes by it's very nature is lossy, and with it not being a wavelet based codec (as far as we know, we're pretty certain it's DCT based) it can band/block. Bit depth alone is necessary, but not sufficient to prevent banding.

Graeme
 
Graeme Nattress said:
But ProRes by it's very nature is lossy, and with it not being a wavelet based codec (as far as we know, we're pretty certain it's DCT based) it can band/block. Bit depth alone is necessary, but not sufficient to prevent banding.
Click to expand...

I know we love wavelets around here, but they also suffer from a wonderful artifact known as "ringing." A more annoying artifact (at least to me) is the loss of subtle details (tiny divergences from the ideal wavelet curves); removing these is one of the main things that allows for there to be "compression" at all. When you hear "lossy", this is what is being lost. I personally can't wait for RED to deliver an uncompressed or lossless compression mode so we can A/B stuff. :-)

Of course, it's possible that RED has overcome some or all of this; RedRay (I'm told) has pretty amazing quality for the bit rates.

One of the x264 developers has a nice writeup on the tradeoffs between wavelets and DCT-based compression here: http://x264dev.multimedia.cx/archives/317

Final caveat: I am not a compression expert, but I do work with wavelets directly on another project of mine (3D rendering) and have a pretty solid understanding of how they can impact an image.
 
Erich Ocean said:
I know we love wavelets around here, but they also suffer from a wonderful artifact known as "ringing." A more annoying artifact (at least to me) is the loss of subtle high-frequency details; removing these is one of the main things that allows for there to be "compression" at all. When you hear "lossy", this is what is being lost. I personally can't wait for RED to deliver an uncompressed or lossless compression mode so we can A/B stuff. :-)

Of course, it's possible that RED has overcome some or all of this; RedRay (I'm told) has pretty amazing quality for the bit rates.

One of the x264 developers has a nice writeup on the tradeoffs between wavelets and DCT-based compression here: http://x264dev.multimedia.cx/archives/317

Final caveat: I am not a compression expert, but I do work with wavelets directly on another project of mine (3D rendering) and have a pretty solid understanding of how they can impact an image.
Click to expand...
And I'd like to know, which one indicates higher quality- numerically honest or mathematically lossless? :wink:
 
You must log in or register to reply here.
Back
Top