Author Topic: To Log or not to Log (from MLV)  (Read 4620 times)

TequilaKez

  • Freshman
  • **
  • Posts: 54
To Log or not to Log (from MLV)
« on: April 29, 2017, 09:04:08 AM »
As I understand it, for cameras that can record Log natively, it can provide most of the dynamic range benefits or RAW, whilst keeping the convenience of single file clips and space conservation of [barely] compressed formats like Prores. (From here on in 'Prores' is interchangeable with your intermediate codec of choice)

But being that ML users must shoot RAW to get these benefits, by the time we get MLVs into a usable format, we've already had to deal with (to varying degrees deepening on model) space/time/res limitations and extra workflow steps involved with shooting RAW. So as we're not really able to cash in on a lot of the conveniences that a true cam->NLE log workflow provides, I'm interested to know why the people that are using things like VisionLog / Cinelog-C in their workflows choose to do so.

I assume some people would like to go Log-Prores to keep dynamic range available whilst maintaining the playback/scrub speed of Prores in NLEs like FCP.
If so do you....?

1. Drop a Log->Rec709 LUT on your Log clips (or output/timeline) by default so you're viewing as Rec.709, and do cc/grading before the LUT in the chain?
   This would obviously have the benefit of allowing clipped areas to be recovered if needed, but should otherwise look like the Log step never happened. Other than that, is there also a specific benefit to applying color correction while in the Log colourspace as opposed to filming 'flat' (contrast/saturation reduced) Rec709? Another way to say this is: If I'm displaying Log footage through a Rec.709 LUT, but adjusting curves before that LUT, the function curve is affecting a very different set of values than if it were after the LUT. Do people use this to advantage? What the theory?

2. Drop a "Film Look" type LUT on the log footage that has the Log->Rec709 transfer built in?
   Since I've been playing with Log and thinking about it, this should effectively give the LUT access to values that lie outside the range of rec.709 and presumably the opportunity to map those values into more a pleasing highlight rolloff. In testing though I can't say such a subltle difference justifies the extra steps and CPU load.

3. Begin grading directly from the Log footage, working contrast and saturation back in manually?
I hear a lot that log is just an intermediate step for maintaining DR, and not intended for output. But I swear a lot of new TV series with flat look resemble Log footage with the blacks pulled down and some sat in the mids. Is this the case or am I just misinterpreting a stylistically flat, but not necessarily log grade.

TechnoPilot

  • Freshman
  • **
  • Posts: 90
Re: To Log or not to Log (from MLV)
« Reply #1 on: April 30, 2017, 10:10:49 PM »
Alright it is important to note the difference, log versus raw is very different.  It not only comes down to the dynamic range of the footage, but more importantly the bitdepth.  I will shoot with a log picture style for most of my work if I don't have to/plan to push the image to hard in my manual grade in post.  If you push the h264 files to hard the colours will heavily band and you will get blocking artifacts due to the heavy compression.  RAW on the other hand is 14bit (depending on RAW settings) versus h264's 8bit, it can be worked very hard before breaking down.  Personally my workflow is to take the RAW MLVs colour balance them and convert them to an arri standard log with some noise reduction before outputting them in Cineform, a GPU accelerated codec that outperforms ProRes and is resolution agnostic, to use in my NLE where I preform my final grade.

Sent from my SM-G930W8 using Tapatalk

Cameras: Canon 70D - 70D.111B (Beta 2B)
Lenses: Sigma 18-35mm F1.8, Sigma 50-150mm F2.8 II
Video Gear: Shure Lenshopper VP83F, Rode Filmmaker Kit, DSLR Controller w/ TPLink MR3040

mothaibaphoto

  • Senior
  • ****
  • Posts: 392
  • pesky kid
Re: To Log or not to Log (from MLV)
« Reply #2 on: May 01, 2017, 01:06:06 AM »
...Cineform, a GPU accelerated codec...
No way. Or give any proof.

TequilaKez

  • Freshman
  • **
  • Posts: 54
Re: To Log or not to Log (from MLV)
« Reply #3 on: May 01, 2017, 06:52:15 AM »
Alright it is important to note the difference, log versus raw is very different.  It not only comes down to the dynamic range of the footage, but more importantly the bitdepth.  I will shoot with a log picture style for most of my work if I don't have to/plan to push the image to hard in my manual grade in post.  If you push the h264 files to hard the colours will heavily band and you will get blocking artifacts due to the heavy compression.  RAW on the other hand is 14bit (depending on RAW settings) versus h264's 8bit, it can be worked very hard before breaking down.  Personally my workflow is to take the RAW MLVs colour balance them and convert them to an arri standard log with some noise reduction before outputting them in Cineform, a GPU accelerated codec that outperforms ProRes and is resolution agnostic, to use in my NLE where I preform my final grade.

Sent from my SM-G930W8 using Tapatalk

I wasn't talking about fake log color profiles for H.264 (IMHO you're better off trying to get the most out of your 8 bits by exposing your shot properly and using standard/neutral profiles, and getting your utilising all 0-255 data values. The sacrifice to color tones is just too great to force log into 8 bits).

What I'm referring to is converting 14bit RAW to a 10/12bit Prores using a log colourspace such as VisionLog / Cinelog-C via ACR or other method, which seems to be the workflow of choice for some people on this forum.
Real high bit depth Log colourspace files like this (like their in-camera counterparts Arri Log-C / BMD Log etc) are really not so different to RAW at all when it comes to grading latitude. But of course we don't have that option, we can only go H.264, MLV, or MLV->Log Prores.


And yeah..... if you're a FCPX user you'll know that Prores is lighting fast. I can have 4+ layers of 1080p with FX all in butter smooth realtime. Prores and FCPX were designed for each other though, if you're using Windows or another NLE, YMMV.
If Cineform can beat that, I'd like to see it.

Sidenote: With the trend pointing at universal adoption of H.265 HVEC in GPUs and camera SoCs, things are about to change rapidly for codecs. With an All-I (GOP1) highbitrate 10bit 444 H.265 file rivalling Prores 444 in quality and edit speed, at a fraction of the file size, it's not hard to see where things are going.
These new chips from Ambarella (https://www.ambarella.com/news/94/122/Ambarella-S5-IP-Camera-SoC-Delivers-4K-10-bit-H-265-Video-and-Multi-Imager-Capabilities-to-the-Professional-Surveillance-Industry) means even tiny action cams will be encoding this on their hardware very soon, and you GPU will be decoding it realtime back at the computer. That will be hard for 3rd party codecs to beat!