Results of testing various 5D3 RAW workflows

A dng image with all the matrix metadata intact describes the color space of the camera through the XYZ transforms. Converting this to rec709 is trivial and in fact Resolve's rec709 import from DNG might be sufficiently mathematically correct already. I believe later raw2dng builds incorporate the matrices based on camera model. If not, it is very easy to add them to your files with exiftool.
I admit I don't care for looks LUTs. No point in using one of the most powerful grading solutions to apply some god-knows-how-devised "film" look. The fact that a lot of these are cringeworthy doesn't help.
 
I'm not a Resolve user, the AE/ACR workflow is a lot simpler for me, if a lot slower too.
In terms of IQ, I think they're basically the same. If you're an AE/ACR user, you'll probably get better results on that one (as it happened in the first posts of this thread). If you're a Resolve user, you can also find that it gives you a cleaner image (here).
 
Celluloid Dream- yeah, I checked those out. Interesting look but not accurate compared to Rec 709 color space in Resolve (or ACR). For example, blue highlights went to purple (looks cool, but not accurate).

Again, I think log encoding makes sense before a compression/truncation step (14-bits to 10-bits for example) but not if we have access to RAW data. It looks like the 5D3 RAW is close to (or is?) BT.709 (Rec 709), so that's the best place to start. I think it's also helpful to see footage and compare to the real-world to make sure it's accurate. Converting 5D3 RAW to log (and BMD Film color space in Resolve) doesn't make sense to me; just a lossy step with no benefit other than perhaps compatibility with a 3D LUT (which is also lossy).

A few years ago I wrote a custom program for color processing using a 3D cube lattice (XYZ RGB) which was also viewable with 3D glasses to help with editing. The GUI allowed moving the vertices with the mouse while the image was updated interactively. It also showed slices of the cube as 2D swatches which would be stepped through. Seeing the 3D cube and 2D swatches helped prevent mistakes which would mess up general image support. That is, while the 3D LUT and test image might look fine, if the 3D LUT was tweaked in ways that crushed colors together, other images would have problems (which I'm seeing with some of these 3D LUTS in Resolve). The 2D swatches made this clear, and after a while it became clear what was possible in the general case with a 3D LUT. It was also clear than when the 3D cube was deformed in certain ways, it would not work well for general images ('spiked' vertices and highly deformed boundary regions outside of the unit space). It's amazing that we can now use 3D LUTs with (hopefully) tricubic interpolation on GPUs in real-time (http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter20.html. At least I hope that's what they are using (I did trilinear for interactive work and tricubic (Catmull Rom) for output on the CPU)).

cpc- I think you may be right. Rec 709 definitely looks the best and is the right starting point in Resolve vs. BMD Film. Perhaps I should ask on the ML forum to be sure. I agree that most of the LUTs don't work very well. A few are interesting and provide ideas, though. I experimented creating 3D LUTs ("from current grade") in Resolve as well as using the trim_lut0.dpx from Resolve to create 3D LUTs in Photoshop to be used in Resolve (it works as expected- I've used a similar method for iOS GPU 3D LUTs (https://itunes.apple.com/us/app/twrrl/id655900365?mt=8)).

I'm reading "Color Correction Handbook" to get more ideas.

Samuel- ACR+AE is faster/easier to get realistic/accurate looks. Resolve is easier to get non-realistic looks (especially for someone just learning it ;)); a double-edged sword.
 
Last edited:
John, you may want to check this thread: http://www.magiclantern.fm/forum/index.php?topic=10119.0

5d3 RAW is really (near) linear and in native camera space, which is larger than sRGB/rec709. You can use ColorMatrix1 and ColorMatrix2 to calculate the respective primaries in XYZ space, this will give you an idea what is covered in the space (refer to the DNG spec for the exact calculaton). Note that this is dependent on illuminants interpolation (the color space is not fixed and depends on the selected white balance). You can pick only one of the illuminants (i.e. D65) to simplify the calculation though, if you are doing it for illustrative purposes.

One difference between ACR and Resolve is that ACR works in linear ProPhotoRGB internally (then appies a transform for display), while Resolve is color space independent. The idea is that you are working within the limits of your monitoring device. Effectively, the color space is moulded through the grade. You do get a transform on debayer though, when you import raw. If you choose rec709 the data gets mapped into the rec709/sRGB primaries and you also get to choose a gamma curve independently. As Resolve is working in 32 bits floating point internally you aren't really losing precision if you choose a log-ish initial space. And I find it is quite easy to reasonably match a BMDfilm initial image to a rec709 initial image.
 
cpc- thanks for the link. It's interesting to see 3x3 affine matrices is all that's need for these transforms (as opposed to something (potentially) non-linear such as a 3D LUT). At this stage in the game I don't want to write any custom code or work with complicated workflows (though I do want to understand what is going on)... I think I've got a handle on how to get Resolve to look 'correct' for Rec 709 (vs. BMD Film) color space. I agree that with 32-bit float processing, not much will be lost on multiple transforms, however 3D LUTs can map many colors to one (or closely similar colors) and reduce micro contrast and detail from an image. 3D LUTs can also screw up colors in unexpected ways (see below).

Here's my 3:00am, tired+need-to-remove contacts test images:

Resolve, BMD Film + Vision Color to Log + Log to Vision Color Rec 709 + gamma boost in node to more closely match image below:
vc709_2.1.1.jpg

Resolve Rec 709 (no LUTs, no grading)
Jr709_1.1.1.jpg

The Vision Color version is interesting, but not accurate. Note the overall magenta cast and how blue goes to pink in the bokeh (light on speaker). Both images decoded with same settings from RAW except color space and gamma (BMD Film for both color space and gamma, and Rec 709 for both color space and gamma). The Vision Color folks sounded like they used calibration instruments... not sure what is going on except Rec 709 color space + gamma looks correct vs. BMD Film + <3D LUTs tested so far>.
 
These folks state they can convert 5D3 RAW (linear) to true log (similar to ARRI LogC): http://www.cinelogdcp.com/. They stated they used a studio, calibration gear, etc.

They also state that ACR's debayer is better than Resolve's. After A/B'ing many clips, I'm not so sure debayer is where ACR's magic is happening. ACR's processing tends to be clearer, cleaner, and just better looking. In essence, perhaps a better tone mapper for HDR material (> 8 bit). Not that Resolve can't create great images- it's just a lot more work. For example, after a grade is looking pretty good, adjusting the RGB luma curve causes extreme color shifts (challenging low light tungsten footage). My guess is that something is fundamentally screwy with color, and that the grade just happens to look good for the current luma curve. Any deviation and it falls apart, like the color matrix is rotated or something similar.

The Cinelogdcp product works with ACR: that's what we're trying to get away from to improve processing time...

I did a test with Photoshop CC: we can import a ProRes clip rendered with Resolve (in (near) real-time (20fps on my laptop)) into Photoshop, convert the clip to a Smart Object, set to 16-bit color, then apply Adobe Camera Raw as a filter. The final result can be rendered to QuickTime, but strangely ProRes didn't show up (I used JPEG2000 high quality (wavelet); file approximately doubled from ProRes HQ input file size)). The shadow-boosted, highlight recovered, color adjusted, denoised, and sharpened footage compared pretty well to footage processed with ACR+AE (JPEG2000 quicktime won't play in real-time in Premiere). So it's possible to get access to ACR magic as a final step if desired, even if processed somewhere else first.

Minimally, creating proxies with Resolve is looking like the fastest way to get a rough cut, then go back and use the dreaded ACR+AE molassesifier for final cut, only processing needed files. It's not that Resolve is bad, it's just that ACR looks better (from what I have been able to do so far, learning Resolve as I go). If anyone has ideas how to get Resolve looking as good as ACR, would love to hear about it.
 
FWIW, unganging the curves control and only adjusting the brightness curve will not affect hues and saturation. Adjusting all curves (YRGB) modifies color.

One thing about ACR (and LR) is that colors are tweaked to match Adobe's own profile (Adobe standard), or the emulated camera manufacturer profiles if you have opted to use them. Hence all the camera specific .dcp files that come with ACR/LR. All the Canon profiles are also significantly different than rec709. Faithful is the closest but still significantly off. So you are always getting customized color.
It is possible that the Embeded profile, which appears as an option when ACR doesn't recognize the camera used is based on dng metadata only (an thus closest to standard). I haven't really looked into that though.
 
The curves were unganged when adjusting luma... colors went crazy, especially in the highlights. After reading your ML forum post about matrices and color processing, especially between ACR and Resolve, as well as other ML posts, it looks like perhaps not all the right info is being stored in the DNGs (and/or info present is not correct). Getting 5D3 RAW processed with correct colors (as much as is possible) would be very helpful.
 
Earlier raw2dng builds were not writing most tags. Last time I converted raw files was in December and metadata was incomplete. I got the impression they were going to fix this. No idea if it is fixed already.
In any case, it is an easy fix with exiftool. I converted a .cr2 still image to .dng with DNGConverter. Then batch-copied all the needed tags from that source dng to my raw2dng created dngs with exiftool. If you are going to use ACR you may want to also copy the huesat table tags as ACR reads and applies them, they are rather big though and will increase filesize. As I use Resolve, I only copied the matrices and the calibration constants for both the illuminants.

Correct colors is a bit relative. While the conversion math itself is trivial, the resulting color space is approximate (for one thing, XYZ is not truly linear, which immediately introduces errors with simple matrix transforms). And there are so many parameters involved in the various processing stages (starting with color filter variations and ADC non-linearities) that the only practical way to get relatively standard colors is to create a calibration LUT for the specific camera using a color chart under various illuminants (similarly to how ACR dcp color profiles are created).

You may try the ACES workflow in Resolve (it is still WIP though). It gives a punchy (and standardized) starting point. I don't particularly like its pinkish skin and cyanish blues, but that's easily correctable with a slight hue rotation. And I hear the latest ACES spec addresses the reds.

Your curves issue sounds like a bug to me. I don't recall seeing problems.
 
Thanks for the info on the exif tool- for know I'm working on just getting a complete workflow. Once done, I can come back and fix footage as bugs are fixed.

Material shot outdoors looks really good- makes sense as the ML dngs appear to always have a daylight WB etc. Not looking for perfect color, just the proper implementation of all the correct color information (matrices, LUTs etc.)

Resolve should match timecode 0 for DNGs with timecode 0 of WAV files (doesn't appear to be any timecode in either file). Tried all options for conform by filename, pattern, etc., didn't work (always applies first WAV file to all clips. The workaround is to read the manual: manually link clips using the Dailies option for audio display. This requires clicking on the video clip then the correct audio clip, and either pressing the link button or the hotkey combo (Command+Option+l on OSX). This is more work which should be automated, but still faster than ACR+AE.

I used chmee's latest Windows CDNG converter in a VMWare Fusion VM (MBP running OSX), used Party Mode and 12-bit output: it worked in PPro CC. Didn't see a way to adjust color balance or other RAW options. Someday we'll have full MLV support in PPro (with debayer control, WB, highlight & shadow recovert, etc.), right? :thumbsup:

Did a shoot today and the quality is excellent- only way this workflow is worth it :)
 
Last edited:
You must log in or register to reply here.
Back
Top