Cinelog - True logspace conversion for DNG and CinemaDNG footage

[cpc]

I think Resolve actually honors the forward matrix. At least Resolve 10 did last time I checked in the beginning of 2014.

[Andy600]

@cpc - I think it might still do (I need to check) but we still need the color matrix tags to do the job to ensure better compatibility across apps.

I'm sure the Adobe matrix is solved from actual spectral sensitivity measurements - I would love to do this but I don't have the funds for the lab gear required to measure - i.e. CamSpecs etc. I think the calibration (i.e. print intent) is not best suited for video, even though I know colorists who would kill to get DSLR color from some digital cinema cameras.

BMD, Digital Bolex, Convergent Design (FS700, FS7), Kinefinity etc don't use forward matrices. The problem is only significant to Magic Lantern Raw Video and when you try to use only one Adobe color matrix in Adobe apps without the second CM or forward matrix tags being filled (i.e. as with ML raw2dng source code) because the Adobe coefficients can and will produce out of gamut color (i.e. clipped neon signs, blown headlights, clipped highlights, crushed color) plus they are, by default, over saturating to ~109% - Eric Chan and John Knowles eluded to some of these things on the Adobe forums.

The color matrices need to achieve several things to remove the need for FMs, HSV or embedded ICC profiles (all/some of which will be ignored in a lot of apps).

Finding sensor chromaticity is fairly simple using DCRaw/ArgylCMS and solving color calibrated matrices is then a series of mundane matrix calculations but I want to throw something else into the mix and control saturation roll off as happens in the Alexa when using it's Film matrix.

I'm 100% sure I can build a better standard reference Rec709 color matrix set for MLV and produce uniform color across all MLV shooting cameras - we can then get away from the Adobe 'look' and any copyright issues - ML devs don't seem too keen to use the full set of Adobe matrices in ML source code anyway.

[DeafEyeJedi]

Once again great read and definitely interesting details which are important factors for many of us to know & also makes a lot sense.

Perhaps this is why I'm sticking with Adobe apps along with MLVFS to get the most out of color grading, for now.

I am 110% confident that you can and WILL build a better standard ref Rec709 color matrix set for MLV's for all supported cameras.

Also thanks for your tips n tricks from my thread/post few days ago. I'll definitely get to the bottom of using OCIO along with certain plugins within AE.

Much appreciated and keep up your eagerness on this project(s)!

[Danne]

and produce uniform color across all MLV shooting cameras

 

I think Resolve actually honors the forward matrix. At least Resolve 10 did last time I checked in the beginning of 2014

Really, I had no idea. Good information.

[Ali Oliya]

We recommend using .MLV instead of .raw and extracting/converting DNG from .mlv files with either raw2cdng (PC) or MLVFS (Mac) as they embed deeper metadata.

@Andy600

How about mlrawviewer?? .mlv files converted with mlvrawwiver embeds the camera model, F-number, focal lenght,...etc but i don't see any of them in DNGs converted with raw2cdng... please enlighten me?

[Andy600]

@Ali Oliya - Unfortunately there is presently no single raw2dng app that embeds all possible metadata but we recommend those apps as we feel color is critical and they embed a full set of Adobe matrices. Other tags can be added using Exiftool if they are critical to your workflow.

There is nothing fundamentally wrong with MLRawViewer's FFMpeg video export as MLRV uses DCRaw (actually Adobe's) D65 color matrices and DCRaw's xyz2rec709 primaries matrix but if you export DNG files then debayer them in any app that is built for CinemaDNG (i.e. most apps) you will get incorrect color for 2 reasons.

CinemaDNG, apart from having specific movie related meta (timecode etc) differs slightly when it comes to color processing than DNG standard which is aimed at raw stills processing. The main difference being that the inclusion of Forward Matrices (white balanced camera RGB to XYZ D50 PCS) is omitted from the CinemaDNG standard and there is no requirement for app devs to include the ability to read/use the forward matrix tags - Some apps will support them, some will not.

In DNG standard, and if the Forward Matrix tags are not included, the color matrices should have the white point chromatically adapted to XYZ D50 - As CinemaDNG is a subset of DNG this requirement carries over and is therefore mandatory because Forward matrices are not described in CinemaDNG - i.e. everything required must be done by the color matrix tags - this is why Blackmagic, Digital Bolex, Kinefinity and other DNG shooting cameras do not have forward matrices.

XYZ D50 (PCS) is used for connecting color spaces, devices and other color related processing in nearly all apps and is used in/by .ICC profiles which is what Adobe bases most of it's apps on but Adobe has Camera Raw and allows camera profiles - these can have forward matrices to transform the white balanced RGB primaries to PCS.

The DCRaw matrix used in ML raw2dng source code is actually 1/4 of a set of Adobe color and forward matrices and only work correctly if used with a forward matrix (and if the app supports forward matrices) - if the forward matrix tags are not used then, according to the DNG (and CinemaDNG) standard, the color matrix must have a D50 adapted white point - DCRaw color matrix 1 tag has an unadapted white point (i.e. it needs a forward matrix) but there is no relevant forward matrix to handle the required transform to PCS - even if there was it would likely be ignored in apps adhering to CinemaDNG standard.

When using only the single 'unadapted' DCRaw matrix, the resulting color difference can be significant depending on scene lighting. Daylight shots should look reasonably correct but will appear colder if the image is then white balanced using the As Shot WB multipliers. The color of shots under other lighting conditions is a crap shoot as there is no second color matrix to tell the raw reader/debayering app how the camera sees light/color under a different illuminant (i.e. it's spectral sensitivity). When you white balance an image, it should not significantly sacrifice the look/temperature of scene lighting to obtain neutrality.

You will see the difference when we publish our alternative color matrix sets for ML cameras. Each set provides 2 , independent, normalized primary matrices with Bradford adapted whitepoint. They should render color the same regardless of the debayering app (without requiring forward matrices) and, because the source white point is in the correct place (PCS) to begin with, your app's white balance temperature controls will work correctly, following the http://en.wikipedia.org/wiki/Planckian_locus. It will be up to ML devs if they want to implement what we provide.

[theartofweb]

I wonder if I can use this log profile in anyway with negative film (medium format) scanned. I would love to batain somethibng similar to cineon where the data is stored in log format, directly corresponding to density of the original negative. Because raw scan are linear I might be able to save them as tif or dng files and then apply the Cinelog profile. The color correction would take place in Resolve.

[Andy600]

@theartofweb - It depends on how you scan the negatives. You could just save the scans to cineon files or DPX. Saving as DNG could add bayer artifacts unless it's demosaiced DNG (basically a TIFF). Cinelog is based on Cineon which is a log encoding/representation of film print density but built for a linear digital negative source (i.e. it works in a reverse way to film), so as is, it's main functions will likely be little use to you because you have the real thing, real film that is effectively log (not linear) and you can just use Cineon tools/plugins to apply the black and white points plus gamma.

Cinelog print emulation looks may be useful - infact, on reversed scanned film they can look epic. We don't (yet) support film scan input in the main products but we can certainly provide a good set of tools for you to work with scanned film negatives, emulate color reversal film, emulate certain print film stocks and build any transfer functions or colorspace transforms you may want/need. It's an area we are moving into.

[Ali Oliya]

@Andy600

Very helpful and comprehensive reply! thank you

[theartofweb]

It depends on how you scan the negatives. You could just save the scans to cineon files or DPX. Saving as DNG could add bayer artifacts unless it's demosaiced DNG (basically a TIFF). Cinelog is based on Cineon which is a log encoding/representation of film print density but built for a linear digital negative source

The scanner I use can't either save to cineon nor dpx files. Its raw scans are linear, and I'm able to save them as tiff or dng files. So, all in all its a linear digital negative source. Could I ingest Resolve with these raw scans and apply a bmd-to-cinelog input lut?

[Andy600]

@theartofweb - TBH I would have to see a scan in whatever format you save it as to be able to tell you a good workflow and whether Cinelog would be of any use to you. I've worked with actual Cineon 35mm and 16mm film scans in the past but these were from the color prints. I've not worked with medium format negs from a flatbed scanner (I presume it's a flatbed!?) but there will be some common ground so I could work something out for you if Cinelog doesn't work in it's current form.

[Andy600]

@Ali Oliya and for anyone that's interested

I've done a little more research and, according to Eric Chan from Adobe, the color matrices are already using a D50 white point (the DNG spec only specifies XYZ so I had assumed it was using the camera native white point with the white point adaptation handled by the forward matrix). This means the Forward matrices are just simple color correction matrices, probably fine-tuning hue rotation (a linear adjustment) to some training data (probably reference data from a IT8 color chart). This gets the primaries into the right ballpark with the HSV tables used for targeted corrections of specific hues, or a look, picture style emulation and to correct any out-of-gamut color.

The Adobe color matrices are not nomalized (because they use forward matrices to do the job) and this means, in the absence of forward matrices there will be gamut and saturation issues with the DCRaw matrix - normalizing the Adobe color matrix doesn't really work well  - probably why they recommend using a forward matrix but you can find the chromaticity of the camera and it's adapted D50 WP (after normalizing) using:

XYZ_P=(M_npm⋅Identity Matrix)^T

then

xy_p=XYZ_to_xy(XYZ_P)

and

XYZ_w=(M_npm⋅[1,1,1])^T

then

xy_w=XYZ_to_xy(XYZ_w)



(npm = normalized primary matrix)

I have used this method to correlate with our own training data to produce a new set of all-in-one (actually 2) color matrices but I probably need to fine tune them (mainly for white balance calibration) and that will mean ML using different CameraCalibration matrices. I'll publish provisional matrix data for a couple of cameras later today for users to try. 

[dubzeebass]

And Andy I will post the c100mk2 colour chart videos today for you today. Finally have some downtime.

[Andy600]

@dubzeebass - great!

In the absence of an official IDT for the camera I'll see if I can work out a color correction matrix to ACES primaries (a temporary IDT if you will) - this should enable easier matching but it will not be perfect (if it is it will be sheer luck).

If possible, can you also let me know the exact color temp you shoot/shot the chart under?

[alexidoia]

Andy,

I am about to buy your cinelog colorspace.
I have shoot raw using magic lantern on a Canon 5D mark III. I kind of understood there were problem with RawMagic converting into DNG. What is the best option to convert from .mlv to DNG ?
How about Mlrawviewer ? Is there some special settings to use ?

Thanks for your input.
Alex

[Andy600]

@alexidoia - RawMagic isn't supported by ML due to licensing issues but you shouldn't have any problems if you use the ACR version as the embedded metadata is overridden by the camera profile. I don't know what the current RawMagic color DNG meta looks like so I can't say if/how it will affect color in other apps but if it embeds 2 Adobe color matrices (as found in the Adobe DNG converter) there will likely not be any significant color issues.

We (Cinelog) presently recommend either raw2cdng (Windows) or MLVFS (Mac) for extracting DNG files.

[alexidoia]

Is there a reason why you don't recommend mlrawviewer ?
Thanks anyway.
Alex

[ddelreal]

Mystic works pretty well for me too, any reason not to recommend that?

[alexidoia]

I guess my question is :
is there a difference in quality of the DNGs resulting from either one of these converters ?
MLVSF is interesting since it does not really convert but instead gives you a real time access to DNG, which is indeed very good.

As it is the first time I work with CINELOG, I just want to make sure I don't do something bad in the process.
Alex

[Danne]

Inside the dng files you have color matrix and forward matrix information. Dcraw, which is used with mlv_dump and raw2dng uses color matrix 1 and not color matrix 2 and the two forward matrix tags. As said at least CM 1 and 2 will be needed for professional work(controlled output).
One can easily check these tags existing or not with exiftool.

MLVFS can act as an exporter. Simply drag the dng files to desktop or wherever to get them extracted.

[Andy600]

It's a little more convoluted when it comes to DCRaw because it uses Adobe color matrix 2 as color matrix 1.

Forward matrices are the preferred method to transform white balanced camera RGB values to XYZ. They can also be used for a degree of linear color correction, so are also used as a CCM to create a look or to move RGB values closer to reference values (i.e. a color chart).

The problem is that forward matrices are not a mandatory tag so some apps will ignore them and to make things even more complicated, CinemaDNG (which is the standard we should be focusing on for raw video) does not include forward matrix tags (although some CinemaDNG readers do support them) - the best thing all round is to have a pair of normalized primary color matrices that will render color values the same in any app that conforms to DNG or CinemaDNG standard.

Don't you just love it when standards are adopted then 'adapted'!? 

edit: oh, I didn't even mention the issues you can get with blue LED lights and CMOS sensors 

[Danne]

It's a little more convoluted when it comes to DCRaw because it uses Adobe color matrix 2 as color matrix 1.

I noticed this as well. How can the dng still look so good I wonder coming from this.

Is there by the way a way to have Davinci resolve recognize as shot neutral white balance values from dng files? Or is it exclusive for ACR? I always get more control with luts and workflow with almost correct wb from scratch.
Honestly, in my pragmatic brain I can,t get all these bits together with color science. Interesting subject though and I really like your idea of creating/calculating personlized ML color matrices.
Cdng vs dng files. What about dng files with tags inserted with exiftool like in cr2hdr-r? Different grouping in subifd than with tiff tag cdng metadata but act as cdng files? Another adaptation .

[Andy600]

@Danne - If the CalibrationIlluminant tag matches it doesn't really matter what number the color matrix tag is given but if only one matrix is used it will be color matrix 1 and the other tag can be omitted.

re: Resolve WB. If the image was white balanced balanced properly when shooting (as it should be - even when shooting raw), then the As Shot setting in Resolve will be accurate. AFAIK Resolve does read the tag correctly. The As Shot XYZ values are used as an identity matrix to map the raw white point to BMD Film or Rec709 D65 white point. Resolve uses the same math as ACR in terms of XYZ but has different preset temps.

re: cr2hdr-r - no problem if it works but I think we need to adhere strictly to CinemaDNG standard in at least one app for general video use - the matrices will be useable in cr2hdr-r. The benefit over Adobe/DCRaw is in there being 2 spectral sensitivity derived normalized matrices (under A and D65 illuminants) to produce a more accurate default color rendering without using Adobe matrices. This will always be a good starting point for developing either CCM forward matrices or ACES IDTs (which we're working on).

[Danne]

CinemaDNG standard in at least one app for general video use

Agreed.

If the image was white balanced balanced properly when shooting

Gonna investigate some more. I didn,t get the as shot values and the corresponding wb visual like in acr or premiere pro CC. Might be some setting I missed or cdng vs dng problem.

[Andy600]

balanced balanced

So important I had to say it twice