Neufeldt

That's a potentially workable solution, but I can't see it being particularly batch processable? I guess it depends how many stills you're pulling that need matching color.

It really depends what program you're using, and what kind of grading you're doing. I'm going to assume that all monitors being considered have at least sRGB gamut. Davinci Resolve (as of version 16) has a number of places to put LUTs, which can be generated using DisplayCAL and an i1 Display Pro. One for the Edit page, one for the Color page, and one for all output (including exports). It does not have one for the fullscreen output as it is expected that you will just buy Decklink/Reference Monitor setups. If you are using a monitor that uses internal LUTs, then you do not need to worry about conflicts with system calibration nearly as much. Just calibrate the monitor, generate a LUT for Resolve in DisplayCAL (typically Rec709 2.4) and put it in the right (multiple) places in Resolve. If you need color accurate fullscreen output on a second monitor (without a decklink/reference monitor setup), you have two choices. First, calibrate the monitor then generate a LUT in DisplayCAL and apply it in Resolve as an Output LUT (affecting all footage on all monitors) and remember to remove it prior to exporting or capturing stills. The sketchiness of this (relying upon the user to prevent color problems upon export) is rather significant so I really can't recommend this. Second (assuming this is possible with your setup, and as it is with NEC Spectraview) just calibrate the fullscreen monitor to BT.1886 sRGB (BT.1886 sRGB is a display calibration for Rec. 709 2.4 content that compensates for any raised black point that a monitor has). The downside is that if you also do photo/print work the monitor will need to be switched back to an AdobeRGB or greater gamut calibration for that. I can confirm that ~AdobeRGB+DisplayCAL LUT is essentially indistinguishable from BT.1886-sRGB+noLUT on an NEC PA302W wide gamut 14-bit-internal-LUT monitor (as it should be). On a related note, if anyone needs accurate color for stills grabbed in Resolve, the general procedure is this: Grab Still in Resolve, Export Still. Open Still in Photoshop. Assign Rec709 2.4 colorspace (NOT Convert), then Convert to sRGB including Black Point Compensation and Save.

Is that temperature verified? What material/emissivity?

It's fine on many machines in Resolve, even somewhat GPU-independant (decoding can be done on GPU or on CPU).

I can say that with regards to H265 4:2:0 10-bit footage Davinci Resolve used to work and broke. With an Intel i7 5930K and an nVidia GTX 1070 decoding was flawless in Resolve Studio 12, 13, and 14. As of Resolve Studio 15, and continuing into 16 it's extremely low performance.

Funny timing as I just traded my GH5S for an S1H. I'm working with the S1H in pure VLog and it's way easier to get pleasant color than the GH5 was in VLogL (again, thanks Sage for saving the GH5 for me). I'm very curious as to how different an GHa-esque S1HVLog->ARRILogC LUT would be from the standard Color Space Transform of V-Gamut/V-Log->ARRIAlexa/ARRILogC. The CST is entirely usable though, so I'm less desperate than I was with the GH5 especially since highlight rolloff is so much nicer to begin with.

Interesting article, thanks! I can definitely say that I've had to manually shim, rebuild, or otherwise adjust a number of vintage lenses. This becomes problematic depending how many different bodies and adapters you want to use the lens on, though. If the adapter has optics (speedboosters), they often can be adjusted. Since I'm dealing with dramatically smaller volumes of gear than Lens Rentals, I'm doing all of this purely by hand and by eye, so I really don't know any of the measurements or which piece of gear is out of spec - I'm just making it all focus correctly (hard-stop manual focus lenses stop at infinity), starting with one setup that works as a reference and just matching everything to it.

A few things: ADC in this camera is linear, so no funny business with Log encoding or anything like that. 96db of dynamic range is an audio standard. The video/photo equivalent would be 48db (a stop is either 3db or 6db, power or amplitude). IIRC N-bit ADCs have DR = 6.021N + 1.763dB (audio), or 3.021N + 1.007dB, so a 12-bit ADC = 74dB/37dB or 12.333 stops of dynamic range. The sensor is 12-bit readout of ~6K photosites in a Bayer array.. When this is tested at 4K we have significantly more than 12 bits of readout per measured pixel. 8-bit 4k IS 10-bit 1080p, etc.

"How do you define dynamic range?" is the question that underlies and undermines most of these discussions. We could measure it as the difference between maximum signal and the point at which signal:noise reaches 1:1 (how DXOMark measures RAW still dynamic range). We could decide that 1:1 is too noisy, and that "usable" dynamic range starts at 8:1 meaning 3 fewer stops of dynamic range. We could measure from any signal at all, adding one or more stops of dynamic range relative to the 1:1 reading. We could weight RGB in various ways, perhaps considering the beginning of dynamic range to be when any one channel starts to have signal and then terminating only when all three channnels are saturated (this gives the highest possible rating). The ARRI linked pdf only tested out to 11.75 stops and didn't find dynamic range limitations, if I'm reading it correctly. It didn't test for the limits.

Sorry, careless writing on my part. Bayer-4k straight to 4k instead of >4k downscaled.

I should certainly hope it does. Shooting sub-4k and upscaling as opposed to shooting above-4k and downscaling definitely calls for one.

That London footage is incredible.

Just want to say the LUTs are great. It's interesting how different GHa is from the GHaLogC-ARRIAlexaLogCRec709 pairing. Thoughts on a more neutral LUT with basically just the highlight rolloff (no longer having oversaturated and color shifted highlight transition is wonderful), or should I just use the Leeming LUT? One note for anyone else using Resolve on a non-cinema wide-gamut hardware-LUT display (not specific to this conversion at all, just in general for color grading): Accurate color absolutely requires the usage of a flat system ICC profile, a monitor-loaded LUT, and a 3D LUT in Resolve (3D Color Viewer LUT) as Resolve does not appear to be ICC aware in any way, shape, or form. This isn't particularly noticeable with SOOC footage, but Log footage run through a LUT (let alone complete color grading) is pretty painful otherwise.