HalfDomain implementation on hardware


(Greg Cotten) #1

Hi all,

Half domain implementation is a pretty straightforward process on the CPU (and the GPU, if you “know what you’re doing”), but I’m curious if any hardware manufacturers that want to natively support CLF are going to be able to support the half domain attribute for 1D LUTs. This might be a question for @bram to answer and anyone else with hardware that is looking to implement CLF!


(Nick Shaw) #2

Is anybody making a hardware product where that would be relevant? As I said on the call, hardware LUT boxes are inherently limited by the fact that their input is integer data over SDI/HDMI. So is there a situation where they would need to process a float source?


(Bram Desmet) #3

Echoing Nick I’m curious what the motivation would be? We’ve just never entertained the idea, but can certainly spend some time looking into this question if there is a general consensus that this is important. My understanding of current hardware available is that a good deal of LUT based hardware only supports 3D LUTs, of those that do support both 3D and 1D LUTs many offer just 10bit entry / 10bit value support for the 1D LUT. BoxIO, and maybe a handful of others, do support 12bit entry / 12bit values and our, perhaps mistaken, assumption was that would be sufficient since as Nick says we wouldn’t expect to be dealing with any signal paths with more than 12bit.

I should also mention that part of our concern regarding implementation is that we want to do as much as possible in realtime and often across multiple channels. For live grading scenarios, where we most often find something like BoxIO used, that can mean up to 4 channels of video each supporting 1D and 3D LUT updates at about 24 times per second through a single device to offer a smooth live grading experience. Supporting complex, multi-element processes isn’t really a problem if we take the realtime requirement away, but we just don’t see that being the normal use case for the hardware LUT box. We can segment functionality into things supported in realtime vs. things supported with some process delay, but we find that complicates things for the software partner integrators so I’d need to be able to make a good case for the added complexity.


(Greg Cotten) #4

Not suggesting there is a relevance! However if they make a tool to upload a CLF (where their backend converts from CLF to a 3D LUT or whatever), they’ll need to support all the features of CLF. Or if their hardware accepts the CLF directly (don’t know why) it will have to do the parsing on hardware.


(Greg Cotten) #5

It might be more important to have a broader discussion. I’ve made a thread for discussing CLF on hardware.