Hi all,
Just wanted to start this thread to figure out if any hardware manufacturers are seeking to directly support CLF. That means a CLF file gets uploaded to the hardware, secret sauce ensues, and some sort of approximation of the CLF gets applied to a live image.
IF anyone is actually wanting to do this, what parts of the spec are problematic to support if any?
A hardware device taking an integer SDI/HDMI input can by definition only support a subset of CLF. For instance, any LMT designed to operate on linear float ACES2065-1 data cannot be used directly in a LUT box, as linear float data cannot be sent over SDI. It would be necessary to log encode the SDI data, and the LMT would need to be modified so that it had an appropriate conversion from log added at the start, and back at the end.
But is this likely ever to happen?
The normal situation in a LUT box is more likely to be that the LMT is concatenated with an Input Transform for e.g. LogC/AWG, and an Output Transform for e.g. Rec. 709. Then it can produce a video signal for on set monitoring which embodies the look of that LMT. But I would say it is not true to say the new LUT is the LMT. It is a new transform which applies the LMT.
So I would say that CLF can store a LUT formatted for the capabilities of a particular LUT box, e.g. 1D + 3D + 1D. But no LUT box can “implement CLF” fully. Nor does it need to.
@nick, this is why I want to hear from hardware manufacturers. I believe everyone (I hope!) understands that you can’t send float data over SDI and that on-set viewing is all camera log based.
I have heard many times people asking for us to consider hardware manufacturers in our discussions but am trying to figure out what that exactly means or how it affects the tweaking of the spec.
For example, should we just assume all hardware manufacturers are going to have constraints so we shouldn’t necessarily consider them as viable candidates for fully implementing the spec? Meaning their hardware will always provide a rough approximation of the intent of a CLF unless it is laid out in a very specific way? In this case is it important that we take into consideration the removal of integers in the spec?
@bram, your thoughts on this?
I know I wrote, in another thread, that manufacturers will have to support the CLF standard or not. However, I would encourage them to give a warning after import notifying the user that the CLF LUT doesn’t match the hardware implementation and processing will be needed which could degrade the performance of the LUT.
Would it be unreasonable to have a Hardware CLF specification setting parameters for minimum 1D LUT size, minimum 3D LUT size, and interpolation type? This could be a simpler subset of CLF and remove some potential ambiguity in hardware implementations?
With CLF being so broad and containing parameters outside the scope of modifying SDI signals I’m not sure how useful ubiquitous warnings will be. If there is an understood and more narrowly defined hardware CLF spec this wouldn’t be necessary and we could have a simple, but common, hardware implementation among “compliant” or at least CLF friendly devices.