Cinelog - True logspace conversion for DNG and CinemaDNG footage

Started by Andy600, January 24, 2014, 06:05:11 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

rtwomey

Hey Andy,

I have a job coming up which will be a mix of interviews and product shots. I want to shoot the interviews as h.264 and the rest as raw. I'm wondering which profile you'd recommend to use in a mkIII to match the ProRes files I'll get from MLV & Cinelog.

Andy600

@rtwomey - The closest Picture Style in terms of dynamic range and color is Technicolor Cinestyle. I would recommend ETTR and always use Technicolor's recommended settings or it messes up the math (-4 contrast, -2 sat, 0 sharpening and 0 color tone). Use fill-lights, reflectors if needed. Shoot at 160 ISO and use an ND if it's over exposed - this will give you the max DR to play with in post. If you have to push ISO I would only go up to 640 unless it's a 5D Mark III.

Next best thing would be ProLost Flat - i.e. the same settings as used Cinestyle with Picture Style set to Neutral - but Standard will be closer in terms of color.

The next Cinelog-C update has input transforms for both - they will not match fully in terms of color (yet) because in-camera H.264 and MLV DNG files use very different methods for color rendering but, if you shoot a Macbeth chart, you will be able to color match them better in Resolve.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

rtwomey

Thanks for the reply, Andy. Looking forward to the update.

Marvin

@Andy600

Since you're the pro, do you know why ACES 1.0 OCIO config does not include a standard sRGB D65 ODT? Closest is a sRGB D60 Sim. This is kind of bizarre since sRGB monitors are all calibrated to D65.

This question was asked here but the answers are confusing and very vague...
https://groups.google.com/forum/#!topic/academyaces/N85bt9Aqn48
Film is truth 24 frames per second.

Andy600

@Marvin - I have no direct involvement with ACES but I'm with you on this - it's a bit odd.

The sRGB, Rec709 and Rec2020 ODTs are really only a 'look' so it's not that big an big issue (D60 and D65 are very close too). It wouldn't be too difficult to chromatically adapt the white point of the current D60 sRGB ODT to D65 if needed but, for accuracy, it's much better to go from ACES to sRGB with a matrix and transfer function - or that baked into a lut.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

ruber


Sane__

Hello guys, sorry for the lame question but what is the difference and benefits between Cinelog and VisionLog?


arrinkiiii


Hi Andy,

I have send you one email with a DNG, for a profile (ACR) Did you receive it ??


Thanks  :) :) 

Andy600

@arrinkiiii - Yes, I've just checked my emails. Sorry for the delay but I've been ill for a few days. I'll send the profile asap :)

@Sane__ - in a word 'math'. Cinelog-C and all the other colorspace transforms we provide are based entirely on linear matrices (derived from the published XY chromaticity and white point of each colorspace) and log formulas provided by the manufacturers. Everything can be fully reversed and/or transformed to/from virtually any other colorspace. VisionLog is a proprietary, non-linear transform that does not map code values in a useful way.

To the untrained eye VisionLog will look like a log signal but it will not act like one. The main purpose of a linear to log transform is compression and if the compression algorithm (in this case, a log formula) is not exact (or non existent, drawn freehand etc), it cannot be uncompressed without significant loss of information and this will result in contouring artifacts, clipping and incorrect RGB values. The VisionLog ACR versions clip shadow and highlight information. The BMD to VisionLog luts are very random and, being only 3D cubes, they don't have enough resolution - my guess is that they were built using something like LightIllusion Matchlight which is ok for matching the color of 2 almost identical shots but useless for defining a colorspace.

Virtually all NLE and color grading apps used today are built on the same math we use for Cinelog.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

arrinkiiii


Thank you so much =))  It's no delay, i just thought that you didn't receive it.  Hope everything is good with you.


Thanks  8)

Pyriphlegethon

Andy, I know you had previously recommended that ML users opt for BMDFilm 4k. I noticed that the guide recommends the sans 4k version. Is there one or the other you'd recommend when using Magic Lantern?

Thank you.

Andy600

@Pyriphlegethon - It doesn't matter now because there are transform luts for both BMD Film and BMD Film 4k to Cinelog-C colorspace. The only difference between BMD Film and BMD Film 4k is the transfer function. The BM 4k camera has a little less DR than the original Cinema and Pocket Cameras. Blackmagic adjusted the TF to take this into account.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

anderSF

Why are people using BMDFilm 4k as an input profile? Or have I misunderstood something?

When using ACR, would I not want to go from Cinelog V3.0 to Cinelog-C?

Andy600

@anderSF - In the ACR version you would use the Cinelog V3.0 to Cinelog-C transform (using OCIO). The BMD Film / BMD Film 4k to Cinelog-C transforms are for the DaVinci Resolve version (using LUTs).
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

anderSF

@Andy600 - Thank you, that's what I thought! Will buy soon!

terranaut

The newer .X version of Resolve added APPLY PRETONE CURVE and APPLY SOFT CLIP to the debayer panel,as mentioned here -
http://vanhurkman.com/wordpress/?p=3208

It seems the debayering process has been reworked behind the scenes, and so will use the new way for debayering. So I am wondering, should APPLY PRETONE CURVE be turned off, since that settings is for the old way of debayering, and only there for backwards compatibility?
Also, should APPLY SOFT CLIP be left on or off, if we are doing the process of transcoding ml cdngs to cinelog-c masters?

On another matter, on the tutorials for transcoding cdng to cinelog-c masters, they mention to keep this process simple with only doing color balancing and exposure. So this means not to worry about getting the full dynamic range for luminance in this initial transcoding, that we should only to deal with the exposure of the luminance and not its range?


Andy600

@terranaut - The new raw features in Resolve are for debayering to REC709 colorspace - i.e. when you are doing an end-to-end grade with the DNG images (not a log transcode). If you use them with BMD Film/BMD Film 4K you basically mess up the log math and introduce a tone curve. The Cinelog REC709 and Film Look LUTS have built-in soft clipping and a tone curve. We have also developed a very nice new soft-clip algorithm that will be used for some new REC709 luts in a forthcoming update.

re: transcoding to Cinelog-C. The log curve in Cinelog-C holds more DR than BMD Film and maps BMD Film primaries to Alexa Wide gamut RGB. All you need to do is add the BMD Film to Cinelog-C transform lut, adjust WB and exposure while looking through the Cinelog-C to Cinelog Rec709 lut (for a visual reference) or, better still, adjust a color chart's mid grey to be at 445 (i.e. Kodak LAD 18% gray) on the waveform monitor (make sure you have set to data levels for monitoring).

The linear DR of Canon DSLR's is less than the log transfer function in Cinelog-C can store so there is a little under and overshoot room. the signal will fit nicely into a 10bit container without clipping. You can unpack a Cinelog-C ProRes or DNxHD render with Cinelog-C to Linear sRGB and still have the DR of the raw images. The only difference will be a) its debayered and b) WB is baked in - if you render to a 4:4:4 codec you have huge room for grading but 4:2:2 is fine for most work.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

QuickHitRecord

@Andy600,

Would you consider working with the folks at FilmConvert so that we have a CineLog preset in the next release?
5DmIII | January 27 2017 Nightly Build (Firmware: 1.23) | KomputerBay 256GB CF Cards (1066x & 1200x)

TrueIndigo

"4:2:2 is fine for most work" - yes, I was wondering about that. The free "LE edition" of the Avid DNxHD codecs do not include a 4:4:4 option for the 10-bit depth settings. Since we are coming from RAW, is very much lost with 4:2:2 colour sampling, Andy?

Another observation:
As an experiment, when I exported a DNG sequence from the After Effects timeline to NDxHD 185 10-bit (1080p25 in the codec dialogue box), in the After Effects render queue, I then set a different frame size (an enlargement to 2K) and shape (to fit my 2.39:1 ML material), and this resulted in a mov of that size and shape, overriding the codec's 16:9 1080. This mov played perfectly in Premiere on a timeline sequence set for that frame size.

Andy600

@QuickHitRecord - RubberMonkey approached me some time ago about this and of course I want it to happen but I deliberately delayed it.

The reason is because I don't feel default MLV color related meta (embedded by the converter apps) is optimal yet and this causes issues with white balance and color rendering depending on the app used for reading/grading the DNG.

We can control this to some extent with the ACR version of Cinelog because the embedded matrices are overridden by the camera profile but even this is less than ideal as it relies on additional HSV tables to correct any out of gamut color that occur when using Adobe standard forward matrices. The HSV table is not read by most other apps (Resolve, Nuke etc) so embedding it will not help.

MLVFS and raw2dng both now use the same matrices that are embedded by the Adobe DNG converter. This helps significantly with white balance but there can still be issues with saturation in highlights requiring some user correction (the amount of correction depends on the color app being used).

My goal is to define a standard color rendering for Magic Lantern Raw RGB to produce identical (or as near to identical) color values between all MLV capable cameras using only matrices, without requiring an embedded ICC profile or HSV table.

Without the means to measure/obtain the spectral sensitivity of every sensor (because Canon do not publish the data and I don't have $20k spare for the specialist gear or every camera to actually measure) I have to rely entirely on Adobe Labs measurements, more specifically the information contained in colormatrix1 and colormatrix2 which transform non-white balanced CIE XYZ D50 to Native Camera RGB values and then, assuming the forward matrix tags are being read by color apps, derive new forward matrices (this is limited by DNG specs).

If the forward matrices are not read then it has to be done with the actual color matrices and this is not easy without knowing/measuring the spectral sensitivity in order to compute a new, non-Adobe set. Blackmagic achieved this with the Cinema Camera and Pocket camera which have different sensors but identical color matrices, producing near identical color - it may be possible (but unlikely) to develop a single matrix set for use with MLV - something I am currently looking into.

I already have candidate matrices (different to Adobe Standard) but an additional color correction matrix (CCM) is also required to get close to uniform color rendering. This is ok for Cinelog users as I can build this into our OpenColorIO config or bake the CCM into our luts but not everyone wants or uses Cinelog. It would be unfair of me to not attempt to fix problems at meta level first plus, it will only work if Cinelog users (who do not use ACR) extract DNGs with MLVFS or raw2cdng - not everyone does and TBH, a lot of user issues I deal with are predominantly meta related and mainly caused by raw converters using only the ML source provided, single DCRaw matrix (half of the minimum requirement).

This issue has also stalled my work in development of ACES IDTs for Magic Lantern Raw Video because colormatrix1 and colormatrix2 DNG tags need to be filled by default (i.e. ML source needs this - and all converter apps need to embed the same matrix information) before doing the CDL work required for the IDT - I did it once before but it's flawed because the DNG meta needs 2 illuminants for me to produce the 2 illuminant IDTs (minimum for ACES).
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

Andy600

@TrueIndigo - DNxHD 444 is 10bit  ;)

You do of course lose some color information with 4:2:2 so it really depends on how extreme the grade will be and how much storage space you have available. I stick to 444 for maximum flexibility but 4:4:2 for any casual, unimportant raw video that I just want to archive. If you do any compositing work use 444.

re: DNxHD frame size - that's interesting. It shouldn't work. Are you sure you're getting 2k dimension? I haven't actually tried it myself but I will.

I'm waiting for the release of the DNxHR codec pack. I hope Blackmagic rework their implementation of DNxHR too because restricting it to MXF is a PITA.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

Danne

Hi!
Anybody got some experience with dnxhd transcoding using ffmpeg? Would you say it is the better choice over ProRes Transcoding to film format?

Andy600

@Danne - that's a simple one. ProRes on Mac, DNxHD (soon to be superseded by DNxHR) on Windows - pretty much industry standard.

edit: regarding FFMpeg - hmmm, it says VC3 = DNxHD in FFMpeg. Is it not actual Avid DNxHD? http://www.itbroadcastanddigitalcinema.com/ffmpeg_howto.html#Encoding_VC-3

More importantly VC3 looks limited to 8bit? - if that's the case then it's a non-starter.
Colorist working with Davinci Resolve, Baselight, Nuke, After Effects & Premier Pro. Occasional Sunday afternoon DOP. Developer of Cinelog-C Colorspace Management and LUTs - www.cinelogdcp.com

Danne