Cinelog - True logspace conversion for DNG and CinemaDNG footage

[Andy600]

@cmccullum

I've only just recently started exploring raw video with magic lantern, but I've done a few tests and been able to get some pretty cool results using only ACR.

Welcome aboard!

So far, I haven't introduced any flicker or other weird artifacts using the ACR sliders to adjust the images as I please.

ACR can cause flicker when there is a significant change in lighting over a few frames. There are some functions of ACR that are dynamic and change from frame to frame when certain controls are used. This is ok for Adobe because ACR's primary function is processing still images. I have had shots that didn't flicker from using the highlight recovery, contrast and other controls but also had shots that do exhibit modulation. If you can live with this then use the ACR controls but it's very difficult to fix later if at all.

I guess where cinelog really interests me so far is color accuracy. I've only recently started learning about using scopes for correcting/grading, and I still don't REALLY understand what's going on there so most of the CC I've done has been by eye, and ends up looking different between displays (I'm assuming this is pretty much unavoidable).

The scopes are your get-out-of-jail card and give you a visual warning where your eyes or monitor might not indicate any problem. Each scope has a specific purpose and learning to use them is very important for accurate and 'safe' color correction/grading. I say safe because there are very strict standards for broadcast and understanding what the scopes are telling you is 9/10s of the battle. Even if you are not doing broadcast or cinema work you will still benefit from this knowledge especially if you upload to Youtube or Vimeo.

Your video will always look different across different displays for a lot of reasons. Manufactures like to add tweaks to make their models stand out in the showroom. Users tweak the settings to a look they like and then there are the differences between LED, LCD, Plasma, Retina etc etc but fundamentally, each display has a gamut, a colorspace, mostly Rec709/Rec2020 (HD and 4K TVs) or sRGB (computer monitors). A professional reference monitor is very expensive but can be calibrated to display Rec709 or sRGB gamuts (sometimes other colorspaces) accurately with very little error and when you grade with a reference monitor you can be sure that your corrections are also accurate even if the viewer sees a completely different image because of their own TV 'tweaks'.

A good monitor is vital to good grading. At the very least you should calibrate your monitor using something like an X-Rite i1 Display Pro but consumer displays are rarely accurate enough and a lot simply cant be calibrated well. Understanding the scopes will help you a lot when you cant trust your monitor but there really are no shortcuts or cheap solutions.

I guess the short answer is that I don't really know what it is I'm looking for. Just looking to explore options, and the "proper" ways to work with these things, I from what I've read, I feel that using Cinelog might be a good way for me to do some hands on learning about a Proper raw/log workflow.

Cinelog is certainly an option if you process your DNG files through ACR and want to render high quality log intermediate files but before you make a decision I would suggest having a play with the free DaVinci Resolve 12beta if your computer can handle it and you don't mind learning another system. It has a good color management system builtin and does a lot of what Cinelog-C can do (but not everything). If you don't like it then Cinelog-C for ACR could be very useful to you.

I'm far from a professional colorist (I'm sure that goes without saying), but I think I do a pretty damn good job, and haven't really run into a situation in which I can't do something I'm trying to do.

Even professionals colorists were once amateurs. If you stick at it there is no reason you cant become one too!:)

Also possibly worth noting, I haven't come across any "looks" (lut or otherwise) that I particularly care for, but I figure people use them, so there must be something to it and I'm trying to find the allure I suppose

Looks are purely subjective and you don't have to like them or use them just because everyone else is. There is nothing wrong with being different, infact I would encourage it. Even if you do use a preset or lut you can still make it your own by what you do under it. One bit of advice about luts I will give is to be aware of what exact input colorspace the lut expects because you can get very bad results if the input is wrong.

[mothaibaphoto]

@Andy600: I'm very sceptical about that "scary flicker" myth. Due to my expirience this occurs only with non-video tools(Lightroom, PS batch conversion).
Can you please share any DNG sequence(along with ACR settings) that introduce flicker with cmccullum's workflow (Import DNG sequence into AE)?

[cmccullum]

@andy600 thanks for the detailed response. It really helps a lot, and it seems cinelog would be a great addition to any toolset.

@mothaibaphoto In my limited experience, I haven't had any issues using ACR from within AE, but when I first tried shooting raw, I selected and opened all of the individual DNGs in ACR (photoshop/lightroom) and used "select all" to make changes to the entire sequence. This way of working with the DNG sequence caused A TON of flicker, and nastiness so I can say that much. As for the ACR within AE, I'd say it's probably better to trust the many other users, and save yourself the headache

[Terry Tibbs]

Just wanted to say thanks to Andy and also to highly recommend this to anyone considering it. It's worked a treat for me, and I am not even a DOP.

I'll provide a link to my film when done and you guys can see if you can tell which shots are ML RAW and which are C300!

TT

[baldavenger]

@Andy600

Did you take note of changes in saturation when profiling cameras with charts?  What I mean to say is, different camera models and brands see a different change in saturation levels when exposure is altered.  The Alexa registers peak saturation with middle grey at about 35 IRE and maintains that level even as exposure is increased (up to clipping).  The Sony F55 doesn't see saturation peak until 65 IRE.  As the Alexa has the most convincing film aesthetic of current digital cameras, I was wondering if you had any information with regards to these matters in relation to the 5D Mark III.

By the way, your Cinelog Lut packs have been of great use to me

[Andy600]

@baldavenger - This is really only relevant to in-camera log or Rec709 capture because CFA raw has no saturation, only measurements of RGGB channels - Saturation, white balance and color are assigned later by DNG metadata and post processing.

I did consider building EI (ISO) linked profiles in the beginning but it proved highly impracticable as you need one profile per ISO multiplied by the number of cameras we support plus the user would have to expose accurately everytime to 18% (you should anyway but many still don't) and choose the relevant profile which can sometimes mean an extra job of extracting metadata for every shot. This would run into hundreds, if not thousands of DCP profiles and Resolve shaper luts so as you can imagine, management of those files alone would be a nightmare for us and the end user.

Part of the reason we chose the Alexa's colorspace was to help manage saturation. Mapped properly, this gamut produces a progressive reduction in saturation from black to white and shapes the colorspace in a way that can't be done with a matrix alone - what you end up with is a gamut that, when viewed in 2D, has a locus much like the horseshoe shape or a triangle with rounded lines you see in CIE diagrams. What this does is give you more room to push relative saturation before clipping occurs i.e. you can get more color and see more gradation between close pixel values when you put the image into a display space (sRGB/Rec709 etc). If you view the colorspace side-on in 3D (i.e. a cube viewer) you see saturation decrease with brightness and lower saturation near black. It also keeps everything in-gamut.

The current V3.0 camera profiles are mainly there to ensure data can be passed from ACR to AE in 16bits without clipping and without using ACR controls - the log curve ensures we can invert the process in AE to produce a linear signal (linear in terms of how OCIO works i.e. HDR with 18% maintained at 18% and 90% white diffuser scaled to 1.0 in float) . ACR is used purely as the debayer with some control over exposure, sharpening, noise reduction and lens corrections. Color is mainly produced by the forward matrices and there are hsv tweaks that can help with correcting out-of-gamut issues that the forward matrices cause when the image is viewed under an ICC display profile. These corrections attempt to keep hue shifts under control and target saturation levels at the locus of display colorspaces otherwise you can see severe clipping caused by spectral spikes in some lighting (i.e. the blue LED issue Sony cameras exhibit). The colorspace transform to Cinelog-C that happens downstream in AE happens in relation to OCIO scene linear which has huge DR and makes sure everything fits into a minimum of 10bits.

As for peak saturation data, we have now built Cinelog-C into a Picture Style for JPEG/H.264 and DPP use (it's currently an internal beta). It is built with reference to 18% gray at base exposure (usually ISO 100) but it should be possible to find what, if anthing, happens to saturation in relation to ISO in Canon DSLRs in logspace. I haven't done this yet and I suspect, as the PS is a static profile, it will have no impact - These are not an Alexa unfortunately but you never know incidentally, we can't offer IE linked Picture Style profiles either as the camera can only hold 3 custom styles at any one time but the Cinelog-C PS will make it very easy for users to mix H.264 with Magic Lantern Raw.

[baldavenger]

Thank you @Andy600 once again for such a substantial, considered, and technically precise explanation.

My original inquiry was inspired by a couple of articles I read:


http://www.dvinfo.net/article/post/making-the-sony-f55-look-filmic-with-resolve-9.html


http://www.dvinfo.net/article/production/camgear/what-alexa-and-watercolors-have-in-common.html



I was really just wondering if there was a more specific approach to modifying saturation with 5D Mark III raw footage in Davinci Resolve using the Luma Saturation curve (as featured in the first article).  The author claims Canon cameras are similar to Sony when it comes to saturation behaviour, so would the curve used in the article work in a similar way with Magic Lantern footage?

[ruber]

Hi @Andy600,

a couple of points in order to help me to better use cinelog:

1) following your indications, I always use raw2cdng to convert my mlv files to use with cinelog. (davinci resolve luts).

Now, I see that there is a tool under development:  "MLVProducer for Windows". Is it possible to use it for conversion? In other words: is its output reliable as raw2cdng?

2) I'd also be interested in purchasing the AE & Premiere Version of the luts since I have to work with Green screen and I am looking for a suitable process:
At the moment my process is:
a) Import DNG into resolve
b) apply Cinelog lut adnd white balance (as you well describe)
c) export in DNxHD applying a Cinelog --> 709 rec output lut because I need to import it in Premiere and match the clips with RGB images of the background imported from photoshop.
d) import 709 dnxhd clips into Premiere, as well with jpg backgrounds
e) eliminate the green screen by a keying plugin
f) edit and export (to Resolve for CC or not)

With this process, I have to use a lot of hard disk space, since I mainly export the dng clips  DNxHD both with a Cinelog -> 709Rec  (to use with premiere) and one version without the output lut for backup purpose. So I double the used space.
at step c) I'd like to export only the version without the "Cinelog -> 709Rec" output lut
d) import in Premiere and either:

dI) apply a "Cinelog -> 709Rec" lut to the "cinelog" clips in order to have the right "final" curve to work with the jpg background
dII) best: apply a sort of "inversion" lut (also in photoshop, or in premiere) to the images of the background in order to have a "flat" background matching with the "cinelog" clips
This would be the best option, since I could keep working with a Cinelog curve and export to Resolve for a final CC still with the cinelog curve.

Do you think that buying the AE & camera raw version of the Cinelog luts this would be possible?

Would you suggest a better workflow?

Thank you. Cheers. Carlo

[baldavenger]

.

[Audionut]

Phew.............You guys probably should have just kept this in PM.

We, the Magic Lantern development community, prefer open source development.  This should be immediately comprehensible, since the development project releases solely under the open source GPL license.  The GPL license provides some manner of protection against plagiarism.  The GPL license does not prohibit commercial application of said code.

Andy600 has been a significant contributor to this project for some time, and while deep down we probably prefer him to follow the open source nature of the project, the man needs to make a living, and his choice of providing commercial applications based around this project is not up for debate!  Let me make this last point absolutely clear.  He has a right to make commercial applications based from the Magic Lantern codebase, and the license that this development project is released under, specifically gives him this right.

http://www.magiclantern.fm/forum/index.php?topic=13335.0

What this development community does not want, is a useful contributor to the project, leaving the project, based solely on personal opinions.

Raw recording is not the reason I contribute to this project, and I only keep up to date enough to try and maintain some knowledge to help others, and to keep an eye on the development progress of this specific function of ML.  baldavenger, please do not allow my ignorance regarding raw recording, and all manner of third party development, workflows etc, to be construed as neglect towards contributions you have made towards this project.

I think the only advise I can give you guys from here, is to give each other a wide berth.  Respect that you both contribute to the project, and while your contributions differ with regards to the costs involved, the net result is the same, contribution to the community.

Cheers,
Lionel.

[squig]

I concur with Audionut (for a change)

[DeafEyeJedi]

*amen* @Audionut and very well said! [emoji482]

[mothaibaphoto]

To be honest, i'm not a LUT fanboy either.
And what I see: one man advertise his LUTs and workflow in dedicated topic named "Cinelog - ... and so on". No problem for me.
Next, another man started topic "DaVinci Resolve 12 and ML Raw". http://www.magiclantern.fm/forum/index.php?topic=15801
No more, no less. And what I see inside?
Yes, the same, advertising LUTs and workflow.
Moreover, that topic contains false statements regarding ML RAW.
And when I pointed him, that topic content didn't correspond to theme, he didn't find any better than insult me and asking to shut up.
Yes, everything in that topic for free yet. But what if baldavenger will announce commercial prices for his Mudak LUTs v2.0?
Why to impose all that as the only "true" way and posting so much LOG fiction as not to intend to sell something?
So, @Audionut, please, inspect that topic too.

[Audionut]

I'm not sure what your agenda is here mothaibaphoto, but I suggest if you're not a LUT fanboi, then you just refrain from posting in such threads.

This thread needs to find it's way back on topic very fast.

[Andy600]

Thankyou @audionut. I appreciate your input and will take your advice.

I would like to point out to all readers, something fundamental about CinelogDCP and our products. We don't actually make products specifically for Magic Lantern. Our focus is aimed at workflow improvements to NLE and color grading applications that do not or did not previously offer enough capability to users of DNG based workflows. We have never used or had anything to do with ML source code but the application of our products has been relevant and useful to Magic Lantern Raw Video in it's DNG state.

I can fully understand the frustration of waiting for updates but we deliberately chose not to go down the incremental path as rushed updates to the products usually leads to error and requires more time to fix. This should not be confused with us doing nothing. The time needed to complete the level of work we set ourselves was vastly underestimated (by me) and this has had a direct knock-on effect delaying our involvement with other parties such as Crumplepop (Koji) and RubberMonkey (FilmConvert).

Even though our products have to date been purely DNG centric, much of our research and development over the last few months has been specifically related to Magic Lantern Raw Video and has produced data that will hopefully be useful to the community and developers of ML raw video apps. This will of course be a contribution under GPL and in keeping with the open source ethos of Magic lantern. 

An open conversation about the pros and cons of lut based and non-lut based workflows is a very valid one to have. There is a great deal more to the subject than producing a nice look, especially where colorspace management is concerned.


edit: Incidentally, I'm not sure if it was intentional (probably not) but Mudak translates to something very offensive in Russian.

[Andy600]

Back on topic.

This is something very important about Resolve 12 Color Management (RCM) related to DNG files.

Take a look at these images. These are high ISO without any NR and are manually white balanced in Resolve using patch D3 (the most spectrally neutral of the 24 patches shown) . No luts are involved except for BMD Film to Rec709 in the final comparison image).



The first image is how BMD Film looks when debayered using RCM (RCM input set to bypass, workspace and output BMD Film).





This is when the image is debayered to BMD Film in normal YRGB mode.





This is the difference when the non RCM BMD Film patches are viewed against the RCM BMD Film. The outer squares are RCM.





and finally, as above but with BMD Film to Rec709 lut for a display space comparison.






Conclusion: RCM does not honor forward matrices but BMD Film YRGB does. RCM sticks rigidly to the CinemaDNG specification and will produce a different color rendering.

If RCM is fully conforming to the CinemaDNG standard the DNG metadata should provide normalized color matrices to comply with the specification - they currently do not.

This is one of the areas of research we followed and we will provide the normalized color matrices to MLV devs shortly.

This however, will not yield a different color rendering and may actually conflict with the inclusion of forward matrices and not pass validation. i.e. there may need to be a decision made as to which standard MLV adheres to because CinemaDNG is slightly different than DNG in terms of recommended color related metadata.

[Danne]

Hi Andy. Why not publish the matrices you created? Would be possible to compile a forked mlv_dump for people to try out with new metadata. It, s a start at least.

[Andy600]

We will Danne but please pay attention to the last sentence of my previous post. The matrices must pass DNG validation which means you may (and probably will) have problems when coupling normalized color matrices with forward matrices as you are mixing specifications. Some apps will throw an error and it will almost certainly conflict with Adobe apps (I have experience just that with ACR camera profiles built around normalized matrices).

I have a full set of normalized matrices for every camera and will release the data shortly but I strongly suggest MLV app devs do not jump straight in and release any app to users before thorough testing.

My personal view is that ML Raw Video should adhere to CinemaDNG standard without exception. This would negate the perceived color enhancements of using forward matrices but we have other ways to get the color back - but it's not as flexible as FMs and will likely rely on luts.

[Danne]

Ok, I was thinking for testing purposes only like suggested.

[Andy600]

I need to format the data to the correct order for ML source first but I'll do it and post asap.

I should probably dampen any expectations of dramatic color changes because you will likely not see any change except possibly a very minor shift in saturation levels. The color matrices are really only intended for white balancing. The change is merely for specification conformity.

[Danne]

Sounds fine too me.

[mothaibaphoto]

This one really interesting information, thanks, Andy.
First, please answer: did Rec.709 colorspace produce "correct" colors with current version of MLV? For me this setup looks very Adobe-like, something I'm used for many years. I'm close to completely switch to DR.
Second, if your corrections will be applied to MLV code, I'll be forced to use color managed workflow in DR and Adobe Camera Raw will no more output accurate colors?

[Andy600]

A tricky question to answer because 'correct' color is subjective unless you attach it to a specific colorspace.

The actual color you see depends on the app you use to get the DNG or CinemaDNG files and the app you use to debayer the file.

At it's most basic level of metadata (as in original .raw) there is a single color matrix which comes from DCRaw. This in turn came from Adobe Labs (it's the D65 color matrix of Adobe Standard - there is a second color matrix for tungsten but this is not used). The D65 matrix maps non-white balanced sensor RGB values to non-white balanced CIE XYZ (CIE XYZ has a D50 white point). This is means that daylight shots will tend to look very good as the color matrix is based on the sensor being calibrated to typical daylight use.

Adding the second color matrix (Standard A - Tungsten) as would be the case were you to debayer DNGs from raw2cdng or MLVFS in Resolve 12 using RCM will give you more accurate white balancing between daylight and tungsten color temperatures and this can be seen as perhaps the most accurate rendition of color from the camera - but accurate color doesn't necessarily mean nice color, especially if you are used to the additional color processing in DSLR cameras.

In addition to the color matrices which handle white balancing, the DNG specification allows 2 forward matrices. These matrices can be independent or duplicated but their function is to map the white balanced color to white balanced XYZ D50. There is scope in the forward matrices to alter color saturation and hue.

MLVFS and Raw2cdng embed the Adobe Standard matrix set and you effectively get something close to Adobe Standard color but if you were to debayer these files in Resolve 12 using RCM the forward matrices will be ignored - this is correct and is one of the differences between DNG and CinemaDNG specifications.

Adobe Camera Raw works a little differently. The DNG file should contain a meta tag that identifies the camera model and this allows ACR to apply different profiles and override much of the embedded color related metadata. This is versatile and means even an original ML raw image with a single embedded matrix can still produce enhanced color because ACR adds the extra matrices during processing (if selected).

If you use ACR you will be using whatever the camera profiles contains and these profiles can have 4 matrices plus 2 sets of HSV lut tables (one for each illuminant). ACR always passes data to After Effects in sRGB colorspace but alternative colorspaces can be selected if using ACR with Photoshop or Lightroom. Adobe color management is based on .ICC profiles.

ICC has its own own limitations and advantages but that subject is for another day.

If you use Resolve 12 and debayer to BMD Film using normal YRGB it will use all the embedded matrices but there are no embedded HSV lut tables.

If you use Resolve with RCM you will only be using the color matrices - this is the most accurate in terms of how the camera sees light but will look very different to what you see in Adobe apps and you may not like the default rendering.

When it comes to raw processing in Canon's own DPP software, things change again because everything is managed through .ICC profiles.

[mothaibaphoto]

Too much words but no clear answer
Why not just to add another image to comparison?
Anyway, thanks for so detailed reply.

[Andy600]

@mothaibaphoto - Don't worry. If and when any changes happen to MLV related apps, I will provide a way for you to get the default color you are used to.

Sorry if my answer wasn't clear to your specific question and I know it is very confusing but I was trying to describe how you will get different color depending on two things:

1) The level of metadata in the DNG file and 2) how the raw reader (ACR, Resolve etc) uses the metadata.

I think it is important that ML users understand some of the back-end processing and how color is produced and managed across different applications.

You are used to Adobe color and the only way you will get full Adobe color is to use ACR. It will be the camera profile in ACR that provides the color information and this is completely independent of any metadata in the DNG file.

The Colorchecker images I posted will give you an idea of the basic differences that can occur but I will post some additional images when I get a chance. The difference in color in those images is due to how Resolve has been set-up (image 1 and 2 are the same image but are debayered to BMD Film colorspace in different ways) .

When you use the new color management in Resolve (RCM) it will ignore the forward matrices contained in the DNG file because RCM uses the CinemaDNG standard which does not allow forward matrices. If you debayer to BMD Film the old way (YRGB) it will use the forward matrices and will alter the color. YRGB must be fully or partly compatible with DNG standard  - confusing, yes.

CinemaDNG standard is technically the correct standard for DNG raw video and Resolve 12 RCM, Premier Pro default CinemaDNG debayer and most other apps that debayer CinemaDNG will be based on that standard. DNG standard is aimed at stills photography.

At the moment, MLVFS and raw2cdng both embed forward matrices and are closer to DNG standard than CinemaDNG standard but because they do include these extra matrices they will give you something very close to Adobe color but only when you use an app that is based on DNG standard.

If MLV adheres to CinemaDNG standard it means we will lose the forward matrices but I will provide a set of high precision linear luts for ML users that will give you something very close to Adobe color if you want it.

Any change to the color related parts of MLV will not affect ML source code but would be used by the developers of raw2dng apps to provide the same color rendering between every app at default settings.